Subject: Reminder: automated key management is often required for new protocols

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Aug 2007 12:38:10 -0400 (EDT)

I wanted to send out a brief reminder to working group chairs about
RFC 4107.  This BCP, published in June of 2005, gives guidance on when
our protocols need to have an automated key management mechanism.

By this point, you should expect to need to follow RFc 4107 for any
new protocols and should not be surprised when you are required to
update protocols to comply with RFC 4107 in order to significantly
increase their applicability.

In many cases, this means you will need to have an automated mechanism
for doing key management for security mechanisms your protocol.  This
does not mean you need to support PKIs or even public-key operations.

If you have not already taken a look at RFc 4107 in the context of
your working group, please do so.  If you have any questions Tim and I
would be happy to answer them.

I'm writing because it looks like I will file a number of discuss
positions this week asking for significant additional security work to
be done on protocols before they can be published.  I'd like to avoid
such late surprises for future work.

Sam Hartman
Security Area Director

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 21 Aug 2007 18:16:16 +0100

Good pointer, thanks Sam.

Can you remind us all what the latest recommendation for an IPR-free 
automated key management protocol is.

Thanks,
Adrian
----- Original Message ----- 
From: "Sam Hartman" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 21, 2007 5:38 PM
Subject: Reminder: automated key management is often required for 
newprotocols

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Aug 2007 13:20:32 -0400

>>>>> "Adrian" == Adrian Farrel <[email-masked]> writes:

    Adrian> Good pointer, thanks Sam.  Can you remind us all what the
    Adrian> latest recommendation for an IPR-free automated key
    Adrian> management protocol is.

I'd probably use DTLS or Kerberos.  You can use IKE V1 (although not
V2) but it's kind of complicated to use.
You can also use S/MIME.

Alternatively you can get security services from something that
includes its own security protocol such as IPsec, SASL, TLS etc.

In some environments, GSAKMP, or MIKEY may be appropriate.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 21 Aug 2007 10:35:23 -0700

Sam Hartman wrote:
> I'd probably use DTLS or Kerberos.  

Is this with a Security AD hat on?

> You can use IKE V1 (although not

I would strongly advice against using IKEv1. Most vendors are moving 
towards using IKEv2. There might not be updates available anymore for 
IKEv1 stacks.

Vijay

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Aug 2007 13:39:36 -0400

>>>>> "Vijay" == Vijay Devarapalli <[email-masked]> writes:

    >>  I'd probably use DTLS or Kerberos.

    Vijay> Is this with a Security AD hat on?
No.

    >> You can use IKE V1 (although not V2) but it's kind of
    >> complicated to use.

    Vijay> I would strongly advice against using IKEv1. Most vendors
    Vijay> are moving towards using IKEv2. There might not be updates
    Vijay> available anymore for IKEv1 stacks.

O, if you're using IKE V1 outside of the context of IPsec, you're
going to kind of be on your own anyway.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 21 Aug 2007 10:46:42 -0700

>     Vijay> Is this with a Security AD hat on?

I don't want to speak for Adrian, but I am guessing he was looking for a 
recommendation from the Security ADs.

> going to kind of be on your own anyway.

I am not sure I understood, but many stack vendors are moving away from 
IKEv1. That would create problems for someone, who is building a Mobile 
IPv6 home agent (for example), to acquire a IKEv1 stack and integrate it 
with the Mobile IPv6 code. The IKEv1 stack would probably be out of date.

Vijay

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Aug 2007 13:51:49 -0400

Vijay> Sam Hartman wrote:
    >>>>>>> "Vijay" == Vijay Devarapalli
    >>>>>>> <[email-masked]> writes:
    >>
    >> No.

    Vijay> I don't want to speak for Adrian, but I am guessing he was
    Vijay> looking for a recommendation from the Security ADs.

Right.  As security AD I can discuss what options are available and
what people've had success with.  I can't give recommendations.

    >> >> You can use IKE V1 (although not V2) but it's kind of >>
    >> complicated to use.
    >> 
    >>  O, if you're using IKE V1 outside of the context of IPsec,
    >> you're going to kind of be on your own anyway.

    Vijay> I am not sure I understood, but many stack vendors are
    Vijay> moving away from IKEv1. That would create problems for
    Vijay> someone, who is building a Mobile IPv6 home agent (for
    Vijay> example), to acquire a IKEv1 stack and integrate it with
    Vijay> the Mobile IPv6 code. The IKEv1 stack would probably be out
    Vijay> of date.

In the case of MIP6 IKE V1 is used to set up IPsec associations.
There, I agree IKE V2 is a better fit.  In theory at least IKE V1 can
be used to key other things that have nothing to do with IPsec.  Russ
Housley wrote a spec using IKE to key layer 2 security associations
for a wireless product.  IKE V2 is limited to IPsec.

Most IKE V1 stacks are rather IPsec specific.  If you were using IKE
V1 for some purpose other than IPsec keying you'd end up writing your
own stack anyway.  I personally would not choose that route unless I
had very specific requirements that IKE V1 worked well for.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 21 Aug 2007 18:51:37 +0100

Hi,

> recommendation from the Security ADs.

Might be helpful, although in the case I am looking at now my protocol 
operates over TCP so I suspect TLS is a no-brainer.

> with the Mobile IPv6 code. The IKEv1 stack would probably be out of date.

Hmmm.
RFC 4306 appears, at first glance, to be crawling with IPR claims.
I'd be worried if we recommended that all protocols had to use something 
with IPR claims, so that seems to be ruled out except on a case by case 
basis on the agreement of individual WGs.

A

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Aug 2007 11:18:29 -0700

>RFC 4306 appears, at first glance, to be crawling with IPR claims.

"Crawling" is an overstatement. There are two ones that relate to the 
protocol itself, and and then a handful that relate to the use of ECC 
in IKEv2. Arguably, *all* of those would relate to IKEv1 as well, 
even if the IPR owners have not made IPR statements about them. The 
patents and applications are to some extent as relevant to the part 
of IKEv1 that were carried over into IKEv2. Some can, if you squint, 
be used against other security protocols as well.

>I'd be worried if we recommended that all protocols had to use 
>something with IPR claims, so that seems to be ruled out except on a 
>case by case basis on the agreement of individual WGs.

This is one problem with the IETF IPR methodology (and not one that 
can be fixed). We encourage anyone with any IPR claim to bring it out 
in the light, but then we consider the target of those claims somehow 
tainted. We cannot determine why IPR holder A chose to file against 
protocol N but not M even if N and M have similar properties. There 
could be numerous reasons.

Having said all that, I agree with Sam that IKE v1 or v2 are probably 
mostly valuable only if you are doing IPsec; there are other simpler 
key management technologies more appropriate for other environments.

--Paul Hoffman, Director
--VPN Consortium