Subject: Re: Position statement on IKE development

From: Henry Spencer <[email-masked]>
Date: Fri, 3 Aug 2001 10:21:49 -0400 (EDT)

On Thu, 2 Aug 2001, Alex Alten wrote:
> ...Their suggestion to use a process like NIST's for selecting
> the AES standard is an excellent one. It's a pity they did not suggest
> it a decade ago. However it should be considered seriously not only
> for the replacement of IKE, but possibly also for the modification or
> simplification of the entire IPsec protocol suite...

I think this is throwing the baby out with the bathwater.

While the packet-level parts (ESP etc.) do have some flaws, most of those
can be fixed simply by taking a big black pen and crossing out superfluous
parts of the existing specs (e.g., all of RFC 2402).  While there is room
for some debate about exactly which parts should be crossed out (e.g.,
there are people who still think AH is useful), I think there would be
little or no support for redesigning the surviving parts.  So a design
competition does not seem very useful in this area.  Moreover, *this* is
the area where there is massive investment in silicon, solder traces, etc. 
Just deleting features does not, by and large, invalidate that investment.

IKE is the disaster area.  The rest of IPsec could use some judicious
featurectomies, but is not badly broken.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Henry Spencer <[email-masked]>
Date: Fri, 3 Aug 2001 15:41:57 -0400 (EDT)

On Fri, 3 Aug 2001, Alex Alten wrote:
> BTW Henry,
> The issue is not that parts of IPsec are superfluous.  
> The question is if IKE is broken then is IPsec also broken?  

That depends somewhat on exactly what you mean by "IPsec", which is why I
specifically referred to "the packet-level parts".  I don't think there is
much wrong with the packet-level stuff except for a few too many useless
options and alternatives.  The key-management ugliness doesn't seem to me
to have spilled over into the packet level (at least partly because the
packet-level work was nearly finished before key management came to the 
fore). 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 03 Aug 2001 17:45:05 -0400

> Let's hold an international design competition to select a key 
> management protocol for IPSec in a manner similar to how NIST did
> the AES selection (although I hope it takes less than 5 years).
> Once we get to a final 5, then let's cryptanalyze them and select
> the best one.  In this manner hopefully we can avoid a 2nd debacle.

the worst of IKE's problems are not in the cryptography.

Besides the general complexity of encoding, there's also the matter of
robustness in the face of retransmissions, as well as loss of peer
state.  Not to mention flash crowds and flooding attacks..

---

From: [email-masked]
Date: Sat, 04 Aug 2001 10:03:20 +0900

(stripped off some of the explicit cc:s)

	just checking: does "ongoing work on Son of IKE" mean this draft,
	or something else?
	draft-ietf-ipsec-improveike-00.txt

itojun

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 6 Aug 2001 08:32:59 -0700

Derek,

	My point is not that PFS is bad, but that the imposition of a
particular set of design priorities led to the very important properties of
usability and deployability to be left out.

	The problem is as you say the means by which the keys are ultimately
authenticated. It is not the cryptography. This is a complex task which is
expensive to manage if the semantics of the trust network are complex and
management takes place in devices at the periphery of the network.

	One solution is the SSL solution where the trust semantics are made
very simple. Unfortunately people don't seem to like that solution, even
though it is the only large scale open PKI that we have people using every
day for real business.

	If people want to have a complex set of trust semantics than the
only way to deploy the system is to provide a mechanism that allows the
trust path processing to be delegated to a trust service - see XKMS
[www.xmltrustcenter.org].

	I would also like to be able to delegate the process of key
agreement. This is because key agreement is an expensive operation that
expensive database engines and routers have no business doing and because
high end crypto hardware is expensive.

	That said there are a set of simplifications to IKE that could be
achieved immediately:

1)	Just decide what type of public key encryption you are going to use,
encryption or signature. There is certainly an ongoing need for algorithm
replacement, but allowing each party to chose from encryption/signature
simply quadruples the work with zero added security.

	At this point we have two public key signature algorithms in general
use and one encryption. So I would pick the signature, all things being
equal.

2)	Separate the credential download. In most cases Alice has Bob's
certificate cached from a previous interaction. If Alice is trying to talk
to Bob and does not have a credential then she should either (1) make a
credential request of Bob or (2) receive the credential in an error message
from Bob.

3)	Get rid of the negotiation assumption generally. At this point we
have 1 working digest function, 2 acceptable symmetric ciphers, 1 key
agreement and 2 public key algorithms. Alice should start with the
assumption that Bob is going to accept what she sends (after all she
probably has the information cached). If that is a false assumption then Bob
can send her an error message saying (I don't do X). 
  
4)	If you want to have the documents reviewed by the cryptography field
generally PRESENT THEM TYPESET. This is the 3rd millenium, we don't use
teletypes any more. Trying to read a crypto protocol with subscripts is bad
enough. Reading K_X, K_AB_X etc is a turn off for anyone. I don't know of a
single cryptographer who can't afford a bit mapped screen.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: Friday, August 03, 2001 5:18 PM
> To: Hallam-Baker, Phillip
> Cc: 'Marcus Leech'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Position statement on IKE development
> 
> 
> I think certificate management (and distribution) within IKE is the
> biggest problem of all.  I want to talk to the host/printer/network
> device at address 1.2.3.4.  How do I get it's public key, and why do I
> want to trust it?
> 
> PFS is _EASY_ compared to that.  An ephemeral DH exchange solves PFS.
> But how do I authenticate?  Better, how do I authenticate on a GLOBAL
> scale?  Now _THAT_ is the hard problem (IMHO).
> 
> -derek
> 
> "Hallam-Baker, Phillip" <[email-masked]> writes:
> 
> > I have a different set of concerns, IPSEC is not being used 
> in cases where
> > it should have been the answer.
> > 
> > In particular the IEEE 802.11b WEP fiasco could have been 
> averted if the
> > designers had not been discouraged by the complexity of IPSEC.
> > 
> > Another issue is why can't I buy a printer that is IPSEC enabled?
> > 
> > I believe that the biggest problem with IPSEC is that the 
> search for a
> > certain view of perfect security has lead to a standard 
> that many have
> > bypassed altogether as too demanding.
> > 
> > Perfect Forward Secrecy is great, but I would rather have a 
> secure means of
> > connecting to my printer than the possibility of a 
> perfectly secure means in
> > ten years time.
> > 
> > End to end security is a good thing, but in many 
> applications the overhead
> > of negotiating trust relationships end to end is just too 
> high. How am I
> > expected to configure the end to end security on an 
> embedded device with no
> > console. Oh I use a web browser to connect to it, yes very 
> end to end.
> > 
> > 		Phill
> > 
> > 
> > 
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > [email-masked]
> > 781 245 6996 x227
> > 
> > 
> > > -----Original Message-----
> > > From: Marcus Leech [mailto:[email-masked]]
> > > Sent: Thursday, August 02, 2001 9:34 PM
> > > To: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Position statement on IKE development
> > > 
> > > 
> > > 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.
> > > 
> > 
> > 
> > ------_=_NextPart_000_01C11C5C.14D9EDC0
> > Content-Type: application/octet-stream;
> > 	name="Phillip Hallam-Baker (E-mail).vcf"
> > Content-Disposition: attachment;
> > 	filename="Phillip Hallam-Baker (E-mail).vcf"
> > 
> > BEGIN:VCARD
> > VERSION:2.1
> > N:Hallam-Baker;Phillip
> > FN:Phillip Hallam-Baker (E-mail)
> > ORG:VeriSign
> > TITLE:Principal Consultant
> > TEL;WORK;VOICE:(781) 245-6996 x227
> > EMAIL;PREF;INTERNET:[email-masked]
> > REV:20010214T163732Z
> > END:VCARD
> > 
> > ------_=_NextPart_000_01C11C5C.14D9EDC0--
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        [email-masked]                        PGP key available
>  
 <<Phillip Hallam-Baker (E-mail).vcf>>

---

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

> 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]
> 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
> >(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
> 
>