[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Summary of responses: Network World article on IPSec
As promised, here is the summary of responses I received regarding
the 8/24/98 article by Ellen Messmer in Network World titled "The
Remaking of IPSec". I have abbreviated a few technical details that
went beyond the scope, and omitted a few ad hominem comments. One
responder asked not to be quoted, so that response is listed as
"anonymous".
Thank you all for your help.
-Anne Anderson
[Bob Moskowitz (ANX, ICSA), co-chair of IPSec WG]:
I spent an hour with Ms. Messmer to help her 'get it right' and was
seriously mis-quoted. So badly in fact, that I doubt I will ever
speak to her again and perhaps her magazine (dispite what my company
PR person says I should do).
[Scott Kelly (RedCreek)]:
I'm sure Bob Moskowitz will respond to you, but since Ellen
interviewed me as well (and ignored what I said), I'll toss in my 2
cents worth. Let me preface this by saying that my impression was
that Ellen's mind was made up as to the answers to the questions she
asked me before she ever asked them, and her article reflects her
mindset at that time. I'll also add that I was sitting near Bob at
the PKIX meeting when he came upon the article, and he immediately
made a phone call to disclaim the article.
That said, I'll address your questions. Note that this is my
personal take, but I think you'll find strong agreement with other
responses you receive.
>An 8/24/98 article by Ellen Messmer in Network World titled "The
>remaking of IPSec" claims that IPSec and IKE are not ready for prime
>time, and that productization needs to wait for IPSecond. This is
>not the impression I have gotten from talking to vendors and from
>following the ipsec mailing list.
[Steven Bellovin (AT&T), co-chair of IPSec WG]:
She's wrong, in my opinion.
[Bob Moskowitz]:
Total mis-representation on her part. I spent a lot of time
hammering the point that IPsec baseline was done and a lot will be
done with that, even hot-to-host. But that, yes, with any new
protocol there was more work to iron out and some minor, non-trivial
errata in IKE (nothing that would stop its use).
[Michael Richardson, Sandelman]:
Not only are there vendors that have been shipping for some *YEARS*,
but there are numerous vendors that are ready now and have been
shipping alphas and betas for some months.
Dan McDonald told me that IPsec is ready to ship with Solaris 2.7
and select partners can get it for 2.6...
[anonymous]:
Has Ms. Messmer quoted any Microsoft people? It would be in
Microsoft's interest to delay consumers from making choices until
they are in the market with NT 5.0.
[Derrell Piper (Network Alchemy)]:
In my opinion, the article was editorially irresponsible. Either
the author set out to write a negative article or else the author
never bothered to check her facts with anyone who's actually fielded
an implementation of IKE/IPSEC.
>Can anyone fill me in on details of some of the following claims
>from the article? Please reply directly to me (aha@East.sun.com),
>and I will summarize the responses to the list.
>-------------------------------------------------------------------
>1. "The harder IPSec change will be standardizing on an IPSec remote
> client. The goal of the IETF meeting is to define a client that
> can support IP address changes automatically."
> [Anne] To what extent is this a barrier to deployment of the
> existing IPSec? Only in NAT environments?
[Steven Bellovin]:
It's important, but not critical, and can be handled by routine
upgrades of products in the field. It's a DHCP-like issue -- do you
have to assign static IP addresses to (say) telecommuters, or can
they be assigned them dynamically.
[Bob Moskowitz]:
There are a number of 'features' that can be added to IKE (not
IPsec) that will significantly strengthen its value for the remote
client:
Support of other authentication methods like Radius and
challenge-response tokens (many companies wish to leverage off of
existing identity infrastructure instead of first NEEDING to deploy
X.509).
Bootstrap or config, as Steve indicates. There is already an
Internet Draft out on this which is say, 80% of what is needed and
at least 3 companies have it in their product, it is so important to
their customers. Standardizing this will not be particularly hard,
depending on how much consensusing is done with the DIAMETER workers
that are not as far along as us.
Mobile IPsec (not quite mobile IP with security done right, but
maybe all that is needed). This may well also address most if not
all NAT items.
[Michael Richardson]:
Yes, we need to standardize this. It doesn't mean that you can't
deploy product, only that the product won't be able to talk to
multiple corporate firewalls at the same time and the client
configuration may be more complicated at present. The result is that
deploying 10000 clients in less than a year may be a
challenge. Deploying 1000 won't be a problem.
[Derrell Piper]:
You're right, it's not. NAT is a known issue. For more information
on NAT, see Steve Bellovin's many lucid posting on this issue in
this archive. It's on the agenda for IPsecond.
[Scott Kelly]:
The remote client requires a different approach to policy
description, in that the client's IP address is volatile and
unpredictable in many cases. Currently under review are extensions
to the authentication process which permit other identification
mechanisms to be used in place of IP address. These include radius,
certificates, and many other legacy authentication/authorization
systems.
This is not a barrier to deployment of ipsec, as my company has sold
several large installations which include mobile clients at this
time. It is a natural evolutionary process which may introduce
interoperability issues periodically, pending completion of the
design. It is a natural follow-on for the working group.
[Pyda Srisuresh]
If you make the assumption that Internet owes its current popularity to
wide deployment of remote access, it is perhaps not unreasonable for
the editor to state that Statdardizing on IPsec for remote accesss
clients (in IPsecond) is a big step forward. Below are a couple of
issues that need to be looked into in IPsecond.
A. Use of existing Auth. data bases. IKE needs to support existing
authentication mechanisms for remote clients. Also, IKE needs to
support asymmetrical authentications for edge devices and
remote users.
B. Ability to support clients (IDs) that change IP addresses.
A remote access client may have the same ID, but may assume
a different IP address each time the client connects to the
network. So, it is important to remove ties between client's
ID and the IP address it may assume. (So far as I know, this
is an issue only with [PSK + main mode])
>-------------------------------------------------------------------
>2. "Another difficult item on this week's agenda will be redefining
> the core IKE protocol. Security experts recently uncovered a
> flaw related to the improper exposure of information."
>
> [Anne] Is this referring the discussion about exposure of
> identities during IKE negotiation in Pre-Shared-Key-Auth Main
> Mode? Is this really a barrier to deployment?
[Bob Moskowitz]:
No, but fixing it will result in a major revision change in IKE.
Thus the next rev of IKE will be 2.0, not 1.1.
[David Mason]:
She might be referring, not to the improper exposure but, to the
fact that the commit bit in the IKE header is not "protected" - it
can be changed en route undetected which causes serious problems for
the IKE negotiation.
[Michael Richardson]:
No. There are always improvements that can be made. That doesn't
make the existing protocol insecure.
[Derrell Piper]:
Yes, that would be a difficult issue, had it been true.
No one I spoke with seemed to know which "flaw" we're talking about.
The general consensus was that the author incorrectly linked the
PKCS encoding problem (i.e. the recent "SSL/RSA" bug) with IPSEC.
As written however, that statement is completely unjustifiable and
irresponsible.
[Scott Kelly]:
I think this refers to the fact that much of the IKE header is
unprotected by the hash, i.e. unauthenticated, meaning that a highly
skilled attacker with the ability to insert himself between you and
the gateway during your IKE negotiation could modify IKE payloads,
resulting in various denial-of-service attacks. Repairing this will
introduce interoperability issues temporarily, but these should be
minor and easily remedied.
[Pyda Srisuresh]
I am not sure what this is about. I dont believe, it has to do with
PSK and main mode. [PSK and main mode] exposes the IP address of the
ID (that is one-to-one tied to); not necessarily the ID itself. Even if
it did, I dont see that as an issue with exposure of session info.
There could be improper exposure (or unauthorised encryption) of
information when policies on either end do not exactly match. But, I
dont know if this is what the author is talking about. Addition of
policy type payload and removing overloaded semantics of ID payload
in Quick mode could possibly be conceived as redefining core protococol.
Currently, there isnt a policy type payload defined in IKE. ID payload
in quick mode is overloaded to imply policy info. Even that couldnt
pass for a policy because at best it describe a portion of policy that
pertains to source side or destination side. Policy has to be a
combination of both source and destination set of selectors. I believe,
IPsecond is expected to address this issue.
>-------------------------------------------------------------------
>3. "And IKE, as it now exists, handles time-expiration of session
> keys in a way that could cause one gateway not to understand
> another."
>
> [Anne] Is this referring to the use of kbytes-based lifetime
> payloads versus seconds-based lifetime payloads? To what extent
> is this a barrier to deployment? Does it just cause a delay, or
> is it a Big Problem?
[Steven Bellovin]:
IKE will definitely need another round. And there's another issue
-- as best I can tell, certificates don't interoperate between
platforms. But both that and your point 3 won't affect people who
use single-vendor solutions for now.
[Bob Moskowitz]:
No this islean up SAs when
network-login is terminated. A new metric like "network-connected-time"
would be useful for remote access users.
Also, interoperability issues with regard to session rekeying upon
lifetime expiry should be addressed independent of remote access clients.
--
Anne Anderson Email: aha@east.sun.com
Sun Microsystems Laboratories or: aha@acm.org
2 Elizabeth Drive, UCHL03-205 Tel: (978) 442-0928
Chelmsford, MA 01824 USA Fax: (978) 250-5067
Follow-Ups: