Hello Barbara, Ted et al,
At the conclusion of the last meeting, there was some talk to merge the two next version of IKE drafts, though I don't know how seriously this was pursued. Paul Hoffman's Features document was, I believe, a valid attempt of doing something to combine the 2 groups. Paul took the lead and asked each team of authors to take certain sections to help him come up with the draft we have today. In the spirit of cooperation to advance the next version of the IKE protocol, I will solicit the opinions of my security colleagues in regards to the questions in Ted's e-mail sent earlier last week. The efforts made by Paul Hoffman and Cheryl Madson to frame the issue are commendable and it must be frustrating that the response has been minimal, at least to this point in time. It would have been time well spent if prior to the first version of IKE, this sort of requirement analysis and features review had been conducted before the protocol was written and then ultimately accepted and now implemented around the globe. But that is history.
Given the fact that we are discussing the approval for the next generation of an existing protocol, can we agree that the implementers and users of IKE know what scenario best suits their needs. If that be so, one could suppose that the usage scenarios, whatever they may be for different user organizations, are known and in play. I would then propose that these users are seeking a better, more efficient IKE protocol that allows them some amount of compatibility with their initial investment as well as code reuse. Protocol functionality and interoperability, in my humble opinion, trump features tied to specific scenarios. We are therefore tasked as a WG, with delivering the next version of a protocol, not the next scenario of how that protocol might or might not be used. Which brings us all back to where we were in December in Salt Lake City - we have two concepts written for the next version of IKE. The basic merits of each should be the focus of a review with final acceptance being the goal.
Previously, I have argued in favor of the draft known as IKEv2 because of its completeness and very thorough attention to details. It is thorough enough as written (December 2001 version) that my company is well on the way to having it implemented in one of our best known products. That being said, there are good merits with the Just Fast Keys (JFK) draft and the subsequent revisions. Today, in June 2002, there really isn't a big difference in complexity between JFK and IKEv2. The IKEv2 spec is longer, but mostly because the authors included a lot of tutorial material (e.g., cookies), perhaps unnecessarily. If you read the draft, the design itself is not significantly more complex. The main additional functionality is retaining the 2nd phase, which is useful for creating multiple SAs, and for having a cryptographically protected informational channel. IKEv2 also includes explicit support for rekeying, which also seems to have a significant constituency.
If support of these features make IKEv2 more complex, it might be reasonable to consider two protocols; a simpler one for where these features are not required, and the more complete protocol where they are required. In reality there isn't a great deal more complexity with either draft. However, the world is certainly simpler if we go with a single well-designed protocol that provides the functionality that users need.
Again, I would like to refocus our attention to approving one of the two next generation drafts as written. It is my strong conviction that there will not be a clearly articulated "features wish list" from the current exercise of consultation. There may be marginal direction one way or the other, but no over riding direction. A quick look at the comments coming from the list in the last few days is an indication of non-focused consensus. I would encourage the membership and it's leaders to call for definitive approval of one of the two drafts as currently written while we are in Yokohama. We can research this protocol into perpetual churn. Rather, we must be bold enough to make a decision, live with the consequences and move on knowing that not all parties will be 100% pleased by any decision. The authors of both drafts have invested lots of their time as well as incorporated a year's worth of comments and suggestions from the membership. It is now incumbent upon the membership to step up to the plate and decide.
Best regards,
Dennis Beard