Merging IKEv2 and JFKr?

[Jan Vilhuber <vilhuber@cisco.com>]

Or "How to dress up Frankenstein to look presentable".

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.

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.

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.

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).

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.

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.

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).

Flame away. "Me too's" or "Ditto's" highly encouraged.

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

http://www.eff.org/cafe