RE: Last ditch proposal for crypto suites

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

There is another option, specify suites only for the IPSEC negotiation
mechanism and leave a-la-carte to out of band negotiation.

My experience with HTTP is that attempts to do in band negotiation over
unrestricted sets fails miserably in the non-security context. Trying to do
this and manage the threat of a downgrade attack is going to be worse.


Are there real end users who want a la carte? Obviously the hoardes of
itinerant cryptographers hawking their scheme of the week are going to be in
favor of a mechanism that supports their scheme, but end users?

My experience is that there is almost no variation in the cryptosuites in
actual use: 3DES, SHA-1, RSA, HMAC. Obviously we anticipate the emergence of
AES but I doubt that that will end up doing more than add an extra couple
of options.


One option and a pretty good one in my view is to say that if someone wants
to have unlimited flexibility then they can negotiate it through IKEv1. In
fact they can implement the full ISAKMP framework and negotiate the
mechanism by which the negotiate the negotiation of the mechanism for
negotiation of the algorithms to be selected for the cryptosuites to be used
in negotiation.

Let us never forget that the point of IKE2 is that we want to drain the damn
swamp.


Another option that would allow support for the itinerant cryptographic
community would be to push the definition of the cryptosuites into the PKI.
For example an OID in a certificate, descriptor record in the DNS, XKMS
property etc.


		Phill


> -----Original Message-----
> From: Charlie_Kaufman@notesdev.ibm.com
> [mailto:Charlie_Kaufman@notesdev.ibm.com]
> Sent: Wednesday, August 28, 2002 11:19 PM
> To: ipsec@lists.tislabs.com
> Subject: Last ditch proposal for crypto suites
> 
> 
> 
> 
> 
> 
> 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
>