Subject: [MSEC] Fwd: Position statement on IKE development

From: Thomas Hardjono <[email-masked]>
Date: Fri, 03 Aug 2001 08:48:52 -0400

Folks,

Please read.  There is a mention of MSEC and GDOI.

thomas
------

>MBOX-Line: From [email-masked] Fri Aug 03 03:06:30 2001
>X-Yahoo-Forwarded: from [email-masked] to [email-masked]
>X-Track: 11: 40
>Date: Thu, 02 Aug 2001 21:33:47 -0400
>From: "Marcus Leech" <[email-masked]>
>Organization: Nortel Networks: Information Systems
>X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686)
>X-Accept-Language: en
>To: [email-masked], [email-masked], [email-masked],
>    [email-masked]
>Subject: Position statement on IKE development
>X-Orig: <[email-masked]>
>Sender: [email-masked]
>List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
>List-ID: <ipsec-policy.vpnc.org>
>List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
>
>I'm sending the attached ASCII TEXT document on behalf of myself, Jeff
>Schiller, and
>   Steve Bellovin, to clarify our position with respect to IKE
>development. It is our hope
>   that it will clarify, to some extent, some fuzziness in this area that
>has evolved over
>   the last year or so.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.  It seems only a matter of time before more
>analyses show more serious security issues in the protocol design that
>stem directly from its complexity.  It seems also, only a matter of
>time, before serious *implementation* problems become apparent, again
>due to the complex nature of the protocol, and the complex
>implementation that must surely follow.
>
>Despite the obviously complex nature of IKE, several proposals have
>been put forward to extend ISAKMP/IKE in various ways, for various
>purposes.  Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and
>others do nothing to improve the complexity situation with regard to
>IKE as a whole.  While many of these proposals are, individually,
>based on sound engineering and reasonably prudent practice, when cast
>in the larger context of IKE, it seems clear that they can do nothing
>to improve the complexity picture.
>
>It is with that in mind that the Security Area directors in the IETF,
>with the consultation of appropriate people on the IESG and IAB, hereby
>place a temporary moratorium on the addition of new features to IKE.
>It is fairly clear that work on IKE should focus on fixing identified
>weaknesses in the protocol, rather than adding features that detract
>from the goal of simplicity and correctness.
>
>We are concerned that trying to reuse too much of the IKE
>code base in new protocols -- PIC and GDOI come to mind --
>will lead to more complex (and hence vulnerable) implementations.
>We suggest that implementors resist this temptation, with the
>obvious exception of common library functions that perform
>functions such as large modular exponentiations.  Attempts
>to share state or to optimize message exchanges are likely to
>lead to disaster.
>
>The Security Area Directors have asked the IPSEC working group to come
>up with a replacement for IKE. This work is underway and is known in
>the community as "Son of IKE".  This effort is at serious risk of
>suffering the "second system effect", where all the features that were
>left out of the first version, end up in the second.  For this to
>happen would be a spectacular disaster, and very much detract from the
>goal: to produce a more secure, simpler, and more robust version of IKE.
>
>Arriving at this point has been exceedingly difficult and harrowing.
>Understandably, egos have been bruised, and the "change not the IKE,
>for it is subtle and quick to anger" position has been taken as a
>personal afront by some members of the IPSEC community.  Nothing could
>be further from the intent of either of the Security Area directors.
>If IKE is vulnerable, we must all share a burden of responsibility for
>allowing it to get to the state it is in and we must all work together
>to correct the problems.
>
>The IPSEC community must act prudently in moving forward with a
>replacement for IKE.  The IPSEC auxillary groups (IPSRA, MSEC, IPSP)
>must act with good judgment (chairs and members alike) in designing
>protocols that don't interfere with the goal of security and
>simplifying our IPSEC key-agreement protocol.
>
>
>Marcus Leech   (IESG)
>Jeff Schiller  (IESG)
>Steve Bellovin (IAB)

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 6 Aug 2001 10:39:48 -0700

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.
[email-masked]
781 245 6996 x227

> -----Original Message-----
> From: Steven M. Bellovin [mailto:[email-masked]]
> Sent: Saturday, August 04, 2001 7:00 PM
> To: Alex Alten
> Cc: Henry Spencer; Marcus Leech; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Position statement on IKE development 
> 
> 
> In message <3.0.3.32.20010804144227.00ebdb30@mail>, 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
> >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
> 
>