[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RE: Position statement on IKE development
Unfortunately the notion that IPsec should simply \"bind
a key to an IP address\" was rejected repeatedly throughout
the history of the IPsec WG. There are alternative
protocols that have been built that demonstrate that one
can provide a useful and appropriate encryption service
in the IP layer and that such a system can be keyed and
managed in a simple scalable way.
Trying to key and manage all kinds of relationships many
of which are conceptually challenging when viewed from
the IP layer, is felt by many to be at the core of IPsec\'s
complexity.
As far as testing is concerned, it would be interesting
to see an IPsec protected network set up as a challenge
to the general networking public with a sizable cash
price offered for the first 10 breakins.
Mitch Nelson
\"Hallam-Baker, Phillip\" <pbaker@verisign.com> wrote:
> A couple of points:
1) You state that Bruce and co had failled to understand the network
context. This is one of my concerns as people present IKE as a general
purpose solution to all key agreement problems - including the key agreement
for XML based Web services I have been working on.
The argument keeps being thrown up \'use what exists and is tested\', yet the
protocol is of necessity tied to its context. It is not possible to pick up
ISAKMP/IKE and apply it to another appliction, I have tried. Yet others are
going to insist upon doing so.
I believe that the current multilayered, \'everything is negotiable\'
negotiating mechanism is a liability even for its stated goal. It encourages
people to try to use ISAKMP for purposes which it just does not support.
2) The current problems with NAT occur because IPSEC is being used in a
network context it was never designed for. The IPSEC authentication
mechanisms are designed to bind a key to an IP address. In the case of a
user behind a NAT box that fails for obvious reasons.
The question to be asked then is does this shift in the networking context
affect the underlying security assumptions?
The meta-question is, do we have a framework that allows questions such as
these to be addressed?
This is the problem that really bit the 802.11b team, their scheme is broken
for two reasons, first the person who analysed the security appears to have
assumed a block cipher would be used and not a stream cipher, second the
design goals are fundamentally incomplete. The problem is not PRIVACY, but
authenticating the user to stop the sacked employee in the car park surfing
the ex-employer\'s intranet. Also any conception of privacy that includes
Louis Freeh having to be able to read all my packets if he is granted access
to the same network as me is somewhat strange to say the least... It may be
a feature of ethernet, in a wireless network with an encryption layer it is
a bug.
3) At this point we do not have a engineering approach to security protocol
analysis. The nearest I have seen to an analytical approach is the work Phil
Rogaway and Mihi Belhare have been doing on algorithms.
Putting out a tender for security protocol analysis would be pointless if
all we got as a result was a further set of experts reviewing the specs in
the same ad hoc \'can we see holes\' fashion.
In the early days of bridge building the \'build it, see if it will fall
down\' algorithm was employed. Today most people (makers of wobbly bridges in
London appart) believe in the \'use design principles that prevent failure\'
approach. Unfortunately we don\'t have the design principles (yet).
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Steven M. Bellovin [mailto:smb@research.att.com]
> Sent: Saturday, August 04, 2001 7:00 PM
> To: Alex Alten
> Cc: Henry Spencer; Marcus Leech; msec@securemulticast.org;
> ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
> Subject: Re: Position statement on IKE development
>
>
> In message , Alex Alten writes:
>
>
> >>
> >>Agreed. And large parts of the Schneier/Ferguson analysis of the
> >>packet-level parts are just plain wrong.
> >>
> >
> >
> >Steve, with all due respect, you, Jeff and Marcus stated the
> following.
> >
> >\"In the several years since the standardization of the IPSEC
> protocols
> >(ESP, AH, and ISAKMP/IKE), there have come to light several security
> >problems with the protocols, most notably the key-agreement protocol,
> >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
> >Simpson, have shown that the security problems in IKE stem directly
> >from its complexity.\"
> >
> >If IKE is no longer considered viable because of it\'s
> complexity, then
> >I am concerned that the other protocols of IPsec are also at
> risk. This
> >is not my concern alone, others have expressed it to me as well.
> >
> >At this point, to restore confidence in the security of the design I
> >would hope that the IETF will retain the services of a quality
> >cryptanalysis consulting firm and publish the results. To
> do otherwise
> >will be to risk the discrediting of the entire IPsec standard.
>
> Frankly, a lot of very competent folks did look at the cryptography.
> WIth all due modesty, I published two papers on the subject
> myself, and
> I wasn\'t the only one. In fact, that\'s one of the reasons why IPsec
> took so long -- the result of those analyses is why RFCs 1825-29 were
> replaced by 2401 et al. -- because we found and fixed a fair
> number of
> problems. The flaws in the Schneier/Ferguson analysis are
> because they don\'t understand the networking context. I sent Bruce a
> long, detailed note about that before he ever published the analysis.
>
> You say \"retain the services of a quality cryptanalysis
> consulting firm\".
> Apart from the point that there aren\'t that many -- and I and others
> know most of the likely players in the field -- the question
> is whether
> or not they understand the networking context. I have no particular
> reason to think that the results would be any better than
> what we have
> now.
>
> Is IPsec perfect? No, of course not. I\'d like to get rid of AH, for
> example, not because it doesn\'t work -- it does -- but
> because it adds
> complexity to implementations without (to me) doing anything useful.
> There are a few other minor things I\'d have done differently. But I
> have a great deal of confidence in the correctness of the
> packet-level
> transforms.
>
> --Steve Bellovin, http://www.research.att.com/~smb
>
>