Last ditch proposal for crypto suites

[Charlie_Kaufman@notesdev.ibm.com]

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