RE: Merging IKEv2 and JFKr?

[Michael Thomas <mat@cisco.com>]

So I wasn't at the last meeting, but it's seemed
fairly obvious to me that there's been consensus
around IKEv2 (fwiw, I've never been anti-IKEv2).
What is to be gained by trying to merge these two
other than a sort of Medieval peace by marrying
different bloodlines? JFK's big appeal, IMO, was
its simplicity. The WG has clearly decided that
wasn't compelling enough argument.

		  Mike

Andrew Krywaniuk writes:
 > Some replies to the entire discussion of last week (not just Jan's message):
 > 
 > I acknowledge the need for some compromise. But I do agree with Charlie's
 > earlier observation that any IKEv2-JFKr will probably be inferior (IMHO) to
 > the original IKEv2 draft. It was too long in coming, but the IKEv2 draft
 > really did represent the logical clarification and evolution of IKE. It is
 > neither unrealistic (what I like to call "simplicity by omission"), nor
 > politically motivated, nor unnecessarily innovative. So as far as I'm
 > concerned, any merging of the drafts is going to be more of a "minimize the
 > damage" type of operation than a "best of both worlds" scenario.
 > 
 > Like Jan said, extensibility is the number 1 concern about any such
 > Frankenstein/chimera. From our earlier survey, I concluded that there is a
 > rough consensus (at least among implementers) that extensibility is a good
 > thing. In my experience, extensibility doesn't just pay off in the long run;
 > to some extent it pays off now. We don't all live in a fantasy world where
 > we can wait until a draft reaches Internet Standard status before we start
 > shipping. Many of us find ourselves constantly chasing a moving target.
 > Obviously you can't anticipate everything, but failure to account for future
 > development results in some really ugly kludges... the Internet is full of
 > them.
 > 
 > BTW, whatever became of the SOI discussion summary that Barbara promised to
 > post a couple of months ago? It was supposed to summarize the popular
 > opinion on each issue, confirm the requirements, and influence the design
 > direction.
 > 
 > In regard to a few other issues that have been brought up recently:
 > 
 > Speaking as someone who successfully implemented the revised hash, I don't
 > particularly want to go back to the old way of doing it. There are many ways
 > to handle incoming IKE messages, but for those of us who do most of our IKE
 > processing on pre-parsed packets it is much easier to sign/hash an arbitrary
 > blob of data than to assemble the buffer piecemeal.
 > 
 > The half-encrypted message idea doesn't particularly appeal to me, but I
 > won't claim that we can't handle it. The protocol doesn't rely on encryption
 > for security, so there's no real danger of this modification introducing
 > security holes.
 > 
 > I'm really not a big fan of the "repeat payloads from message 1 in message
 > 3" idea. People complained about IKE being too complicated because you need
 > code to parse every payload twice (once for main mode and once for
 > aggressive), but this strategy has leads to the same result (plus
 > fragmentation, bandwidth wastage, etc).
 > 
 > I also endorse the "URL to a cert" suggestion.
 > 
 > I will deal with the 4 vs 6/4 issue in a separate message, since Radia
 > branched off a new thread.
 > 
 > Andrew
 > -------------------------------------------
 > There are no rules, only regulations. Luckily,
 > history has shown that with time, hard work,
 > and lots of love, anyone can be a technocrat.
 > 
 > 
 > 
 > > -----Original Message-----
 > > From: owner-ipsec@lists.tislabs.com
 > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber
 > > Sent: Monday, September 16, 2002 8:27 PM
 > > To: ipsec@lists.tislabs.com
 > > Subject: Merging IKEv2 and JFKr?
 > >
 > >
 > > 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
 > >
 > >
 >