Re: Last ditch proposal for crypto suites

[Jan Vilhuber <vilhuber@cisco.com>]

I'll toss in my 2c (plus some ;):

Let's pick one way. PLEASE don't do both, just to appease one side or
the other.

I am marginally more in favor of a-la-carte and Paul's proposal of
defining combinations at the UI level (which also translates into the
'testing' level).

But I don't feel that strongly and if consensus is suites, I'll
definitely live (and, as someone else pointed out, we can use
vendor-id and private-range suite numbers to test out other private
vanity-suites ;).

But please not both. Let's pick one.

jan


On Wed, 28 Aug 2002 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
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

http://www.eff.org/cafe