RE: Last ditch proposal for crypto suites

["Dennis Beard" <beardd@nortelnetworks.com>]

RE: Last ditch proposal for crypto suites

Hello,

I agree with Charlie's proposal (below) as = written.  I think this is the simplest way to go and maintains the = essences of compactness of the SA pay load part of the protocol as = pointed out earlier by L. Dondeti.  Too many options makes the = protocol complicated and difficult to implement.  At most, the = suite should have no more than 2 algorithm capabilities that can = operate in symmetric or asymmetric conditions - light weight w/ minimum = footprint, and robust such as AES (Marc Desoriers).  Steve = Bellovin makes a good point about interoperability.  To the extent = that IKEv2 specifies a very tight set of suites and their attributes, = the more interoperability we will achieve because choice is finitely = contained.  We are the Standards organization so we should specify = and let the world follow.  This is what Charlie wrote:

"I propose that we define a new Protocol-ID that = means crypto suite, and that for that value the SPI Size and # of = Transforms are replaced with a two byte suite number. The suite number = would define the actual Protocol-ID, SPI Size, # of Transforms, and all = of the Transforms and their attributes. The entire proposal would be 8 = bytes for an IKE proposal, 12 bytes for an ESP or AH proposal = (including 4 byte SPI), and 14 bytes for an ESP w/IPcomp

proposal (including 4 byte ESP SPI and 2 byte IPcomp = SPI)."

No hybrid please - unless it's corn.

Cheers,

Dennis Beard

-----Original Message-----
From: Steven M. Bellovin [<3d.htm>mailto:smb@research.att.com] Sent: Thursday, August 29, 2002 11:44 AM
To: Charlie_Kaufman@notesdev.ibm.com
Cc: ipsec@lists.tislabs.com
Subject: Re: Last ditch proposal for crypto suites 
In message = <OF710D18BE.04BE38CA-ON85256C24.000F505D-85256C24.001239FC@iris.com>
, Charlie_Kaufman@notesdev.ibm.com writes:
>
>
>
>
>The discussion of crypto suites vs. ala carte = algorithm negotiation in
>IKEv2 was frustrating. I think most people like = suites better (in the
>possibly unrealistic belief that we can keep the = number of suites
>manageably small), but the advocates for ala = carte negotiation were
>more adament about its necessity.

You know my opinion -- scrap a la carte.  But = let me ask the question
differently:  Paul Hoffman, in your = interoperability tests do you see
many different combinations actually used?  Or = don't your tests go
there?

As for the specific suggestion -- I think I'd rather = keep a la carte,
rather than the hybrid suggestion.  I fear the = complexity, not just of
having both sets of code, but also of being able to = cope correctly with
an offer or a response that specified one a la carte = entry *and* one
suite.  I think the potential for bugs there is = high.  But if we want
to go there, we need to specify precisely how to = deal with the
situation.  In particular, we need to specify = the rules on how to
decide which to accept, and what to do if there is = an apparent conflict
in a response.

        =         --Steve = Bellovin, <3d.htm>http://www.research.att.com/~smb (me)
        =         <3d.htm>http://www.wilyhacker.com ("Firewalls" = book)