Regarding pre-round trip for stateless cookie (Jan's issue)

[Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>]

Re:
	From: Jan Vilhuber <vilhuber@cisco.com>
	
	I'm wondering about the wisdom of merging IKEv2 with JFK'isms. Seeing
	that I haven't read the revised IKEv2+JFK proposal (because it's not
	out yet), this is mostly based on my thoughts of what *I* would do,
	were I to merge the two. I expect there's not that many ways to skin
	this cat.

First a nontechnical point...I've changed the subject line because I think
it's always better to focus on a particular technical detail rather than
which spec something might have come from. At this point there are not
n candidate proposals with n sets of authors, but instead a single
draft that all the authors of all the drafts, and actually, everyone
in the WG, is collaborating on. Everyone wants something that is correct,
reasonably simple, and reflects as close as can be measured, the feelings
of the WG.

Back to the technical issue Jan raised, which I'll call "4/6 vs 4", where
"4/6" means letting Bob, if he wants to do stateless cookies, request
an optional round trip before the 4-message exchange.
In the greater scheme of things, I don't think this issue matters all that much,
but I've changed my mind about this recently and it would be good if the
WG could weigh in, if people (especially implementers) have strong
opinions. The summary is that I originally believed
in "4", but now that I've helped work out the details of "4",
at this point I agree with you, Jan, that "4/6" seems simpler, but
I also don't think it's all that important and can live with either way.

I'd been arguing about this very point with my original coauthors
Dan Harkins and Charlie Kaufman since before our first draft. I wanted
4, they wanted 4/6.
They were not able to explain to me very eloquently at the time
why they wanted to
do 4/6. It seemed to me that the WG would think a 4 message exchange
would be preferable to a (4, sometimes 6) message exchange. At first Dan and 
Charlie
just told me that it would be "a pain in the neck". And when I pressed
for more details they used some of your arguments,
like "half the message encrypted,
half unencrypted", which didn't seem to me like it should be all that
much of a hassle. Then Charlie brought up the fragmentation attack,
and I was convinced that the 4/6 method was better, because it keeps
all messages small until the stateless cookie has been returned, so
that one could build an implementation that saved reassembly resources
for IP addresses that have returned stateless cookies.

It was probably me that suggested, though, in order to look more like
a "merged" proposal, that we make the modification to always be 4 messages.
It was only after we were working out the details that I understood what
Charlie and Dan meant by "pain in the neck". It's doable, but the protocol
is a lot more complicated.

I don't think it's necessary for any "political" reasons that we do anything
any particular way. I think at this point it's clear everyone is collaborating
on one proposal, and wants to do something correct, as simple as possible,
and reflective of the WG's wishes. If we're not choosing "proposal A from
this set of authors" vs "proposal B from this set of authors" and instead
focusing on a well-defined technical point, and the WG has sound arguments
for a particular opinion, we'll all support that way of doing things ("sound"
means that the result would be correct, not overly complex, etc.)

So let's focus on this one technical issue.

The 4/6 protocol can be summarized as follows:
  messages 1 and 2 are D-H exchange (and nonces, and crypto negotiation)
  messages 3 and 4 are encrypted and integrity protected with a function
    of the D-H key, and consist of the identities, and proofs of knowledge
    of the secret, using some function of messages 1 and 2. The simplest
    and easiest, implementation-wise, is to sign all of messages 1 and 2,
    exactly as transmitted. We modified that to "sign your own message
    concatenated with the other side's nonce", at Sara Bitan's suggestion,
    which seemed like it wouldn't be harder, and certainly all fields
    would be still protected in one or the other side's signature. We
    were trying to avoid the issue Jan brought up of wrangling over
    which fields should be covered, and what the canonical order would be,
    and having implementations have to move all the fields around to
    create the canonical hash.
  if Bob wants to use a stateless cookie before doing the handshake,
    he replies to a message 1 without a cookie by saying "try again,
    using this cookie"

The 4-always protocol is more conceptually complicated, since Bob, when
   he receives message 3, cannot be assumed to have any state. Since there
   are parts of messages 1 and 2 that need to be integrity protected (like
   the crypto negotiation), Alice has to repeat all of message 1, and
   Bob has to be able to reproduce, bit for bit, what he would have
   generated as message 2, so that he can sign that. There are the
   issues you brought up, Jan, about which fields need to be in the
   signature, which need to be
   repeated, etc. There are many strategies for how Bob might want
   to use the fields of cookie and nonce to encode state for himself.
   We don't want to constrain an implementation, and yet we need to
   define at least one way that works.

Radia