Subject: Re: Position statement on IKE development

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 03 Aug 2001 14:57:44 -0400

> As a newcomer to IPSec field (but not to the IETF) one of the things that
> continues the amaze me is the deliberate effort that has been made to create
> a wall between IKE and IPSEC. 

Well, this is a good thing -- it means that if you get IKE wrong, it
can be replaced without having to toss the rest of the architecture.

The solaris implementation is structured specifically to allow for
this; we're extending PF_KEY and adding a PF_POLICY to allow for a
strong separation of concerns between packet protection policy, packet
protection mechanisms, and key management.

This is one of the reasons why we (me and my fellow implementors here)
don't want any ipsra authentication/cert provisioning protocols
running on port 500..

> Therefore, I would suggest that any effort in replacing IKE also consider
> replacing/rewriting portions of IPSEC DOI ...

Last I heard, the son-of-ike plan was to merge the DOI into the key
mgmt document.

I think we also need a better-defined interface between 2401 and the
KM protocol...

					- Bill

---

From: Henry Spencer <[email-masked]>
Date: Fri, 3 Aug 2001 15:29:09 -0400 (EDT)

> Last I heard, the son-of-ike plan was to merge the DOI into the key

Realistically, there's no meaningful distinction between IKE and the DOI.
In fact, the separation between the two documents is a real nuisance when
one is looking for obscure details.  They need to be considered as a unit.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Sun, 5 Aug 2001 04:49:19 -0700 (PDT)

Dan Harkins writes:
 >   I discussed this in Minneapolis. The plan is to combine ISAKMP, IKE,
 > and the IPsec DOI into a single draft describing a key management
 > protocol for IPsec. 
 > 
 >   The intent, as well-meaning as it was, was to have a generic language 
 > (ISAKMP) in which to describe a key management protocol and there could
 > be many key management protocols with IKE as just one of them. IKE, then,
 > was supposed to be a generic key exchange protocol which could create 
 > "SAs" for multiple services, of which IPsec (specified in the DOI) was 
 > just one. But IKE is the only thing that used ISAKMP and the other two
 > DOI documents-- OSPF and RIP-- died a quiet death.

   Not entirely correct. KINK is using ISAKMP payloads
   (sa, id, nonce, ke, notify, delete, ie quick mode).
   IMO, the logical split here is between authentication
   and IPsec SA establishment. The former is *always*
   a far harder problem than the latter.

	 Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 5 Aug 2001 04:39:54 -0700 (PDT)

Speaking as an implementor of KINK, it would be nice
if there were a split of anything to make a clean
split between main mode and quick mode. As far as I
can tell, quick mode is far less broken and far more
reusable by any number of key distribution protocols
than main mode.

		Mike

---

From: Dan Harkins <[email-masked]>
Date: Mon, 06 Aug 2001 00:26:36 -0700

I stand corrected... well sort of.

  KINK doesn't really re-use quick mode since certain things were
dropped like PFS and the whole commit bit stuff. So it's really
quick-mode-lite. And it doesn't use UDP port 500 so it's not really
ISAKMP after all. And I don't even think it uses the ISAKMP header.
It also defines as many (if not more) new payloads as it uses 
from ISAKMP.

  So all in all, KINK is not really doing quick mode nor is it 
using ISAKMP.

  Why don't you just define your protocol in full? I don't believe you'll
be sued for cutting-and-pasting payloads from RFC2408.

  Dan.

On Sun, 05 Aug 2001 04:49:19 PDT you wrote

---

From: Michael Thomas <[email-masked]>
Date: Mon, 6 Aug 2001 04:07:42 -0700 (PDT)

>   So all in all, KINK is not really doing quick mode nor is it 

   Actually, PFS was added back in. I guess it depends
   on what is meant by "using" and "really". It's I'd
   say about 90% code preserving which was really the
   main desire.

 > be sued for cutting-and-pasting payloads from RFC2408.

   It was a possibility, but the consensus was to just
   reference quick mode in 2409. I think it will be
   interesting to see if the profile we did is sufficiently
   clear. If not, cut and paste may be the reasonable
   course of action.

	     Mike