Re: Merging IKEv2 and JFKr?

[Charlie_Kaufman@notesdev.ibm.com]

Jan Vilhuber wrote:
> 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.
>
I apologize for the delay. I was hoping to get a new draft out by the
end of August, but a draft I sent to the smaller author community
generated such a volume of feedback that I'm still trying to reconcile
it all.

> Firstly, it doesn't seem needed. The difference is that JFK assumes it's
> ALWAYS under attack, versus IKEv2 that gives you a mechanism to verify
> the initiator's 'liveness' if you think you're under attack. So it's
> not like IKEv2 doesn't address DoS issues. It does.
>

There are other differences between JFK and IKEv2, and other issues
to resolve.

> Code messiness. You may poo-poo that concept, but we all understand
> IKE code and the coding-/design- philosophy behind it. You may not
> like it, but there's a certain amount of expertise out there. By
> adding JFK'isms into the mix, you're now mixing two very different
> philosophies into one protocol, which sounds like it's prone to be
> buggy, hard to analyze, etc etc. Instead of a protocol designed by a
> committee, we now have a protocol designed by TWO committees.
>
> Along the same lines (or maybe 'by example'), IKE has always been
> 'encrypted packet' or 'non encrypted packet'. Now we have a
> 'half-encrypted' packet. Sigh. If someone has a clean way of doing
> this (An 'encrypted payload' similar to Kink's KINK_ENCRYPT payload
> (section 5.1.8 of the kink draft, FWIW) maybe?), maybe this can be
> made to work, if absolutely necessary.
>

Yes, that's how I wrote it, as suggested by someone (I think Paul
Hoffman). It is not quite as clean, but it is nearly so.

> Extensibility: I keep thinking that prior to the SOI discussions, we
> had talked about simplifying IKEv1 hashing, so that ALL payloads are
> hashed and authenticated, no matter what they were. That has clear
> implications to extensibility, i.e. future payloads. I realize one of
> JFK's goals was 'non-extensibility', but I thought I saw rough
> consensus towards extensibility during the recent chinese-menu
> mails... Now by merging JFKr into IKEv2, we complicate the hashing
> mechanism again to the point where we have to think about which
> payloads can be part of the hash and which can't (also, which payloads
> must be repeated and which mustn't or don't need to).
>

I don't believe we've lost any extensibility with the JFK changes.
What's central to extensibility is saying in the spec what an
implementation should do with things it doesn't recognise, including
how to do the cryptographic protection. The spec still does that.
(Of course, whether extensibility actually works out depends on how
well we guess what extensions people will want.)

> Legacy Authentication: This is really a subset of "extensibility". I'm
> trying to fit some legacy authentication scheme into IKEv2, and I have
> some ideas. Trying to fit them into an IKEv2+JFK protocol (assuming
> what's in my mind is similar to what Charlie is working on) makes it
> that much harder.
>
Discussing such extensions on the list might help assure that they
will be possible. Paul told me a little about how legacy authentication
was squeezed into IKEv1 and indeed that JFK changes to IKEv2 make that
mechanism harder. But there are other encodings that might be just as
good.

> Packet sizes: By repeating msg1 in msg3, msg3 necessarily gets
> larger. William kept trying to get people to realize that we have a
> UDP fragmentation issue, when certs (or cert chains) are sent, so this
> seems like a move in the wrong direction. Paul Hoffman had some ideas
> of changing the ID payload so that it can include a URL, i.e. pointer
> to the cert instead of the cert itself, and that may help.
>
The JFK related changes do make it harder to defend against
carefully constructed UDP fragmentation attacks, though it was
never easy and it's still possible. (A group of us has
submitted a paper describing how). I'd like to add URLs as
an optional way to "encode" certificates, but we can't depend
on that to keep the messages to a single UDP fragment.

> Based on my gut feeling, I vote to leave IKEv2 as is, rather than
> grafting JFK'isms onto IKEv2. If it gave us something we can't live
> without, I wouldn't have that much of an issue with it, but I don't
> see a very good reason to do it (the cost outweighs the gain).
>
Why do I have visions of someone snatching my smaller but still
tasty looking bale of hay? I believe that the original IKEv2
proposal was better than the combined proposal, and that the
combined proposal is better than the JFK proposal. I'm sure most
if not all of the JFK people believe that JFK was better than
the combined proposal, but that the combined proposal is better
than the original IKEv2.

It's a compromise. Nobody thinks it's the best we can do. But
neither is there any proposal that everyone would agree is better
(or at least none we're likely to stumble upon before the next
ice age).

          --Charlie

Opinions expressed may not even by mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).