Re: Last ditch proposal for crypto suites

[Lakshminath Dondeti <ldondeti@nortelnetworks.com>]

Before discussing suites vs. ala carte, I see the word *optional* 
cropping again.  I believe it should be either-or, not both with one of 
them as optional.  Suites are already part of another popular protocol, 
so we don't all need to implement them in IKEv2, to make the comparison.

 From what I understand from the concrete proposal below, a compliant 
implementation MUST recognize suites as well as ala carte proposals. 
How does this make life any easier for anyone?

regards,
Lakshminath

PS:  Do I hear a request for recount on this issue :-) ?

Charlie_Kaufman@notesdev.ibm.com wrote:

> 
> 
> 
> 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. I read the conclusion as leave the negotiation
> as it is (ala carte). The specification for SA proposal payload in the
> IKEv2 document is 9 pages long, and they are frightening pages. It was a
> message from Angelos Keromytis saying that it gave him a headache that
> inspired me to make one more last ditch proposal.
> 
> There is a way to get the best of both worlds (and the worst of both
> worlds). The IKEv2 specification could specify how to negotiate suites and
> ala carte, where the suites are mandatory to implement and the ala carte
> negotiation is optional. If it turns out that the optimists are right and
> the number of suites actually implemented is small, the ala carte might not
> be implemented and could fade away. If the pessimists are right and ala
> carte was necessary, the ability to negotiate suites adds only minor
> complexity to the spec and to implementations.
> 
> It's the worst of both worlds because it would make the spec longer and
> more complex. There might be a way to move the optional ala carte
> negotiation to an Appendix or something so that at least some people would
> ignore it and think the spec less intimidating. Some implementers would not
> implement it and simplify their lives. The suites would be more likely to
> pass interoperability testing more easily, since there are fewer things to
> get wrong.
> 
> A concrete proposal:
> 
> The SA payload contains a series of proposals. Each proposal has a fixed
> header and a variable length list of transforms. The fixed harder is
> eight bytes long - four of those bytes are Proposal #, Protocol-ID, SPI
> Size, and # of Transforms. Protocol-IDs are defined for IKE, ESP, AH, and
> IPcomp. 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).
> 
> An implementation MUST recognise and be able to accept the mandatory
> suites, and must be able to skip over non-suite proposals if it chooses not
> to parse them. This would be relatively simple to code.
> 
> What do you think?
> 
>       --Charlie Kaufman
> 
> 
>