Subject: [IPsec] RFC 4869 questions

From: Scott C Moonen <[email-masked]>
Date: Wed, 13 May 2009 13:39:34 -0400

I'm reviewing RFC 4869 and it seems to under-specify the attributes that 
are needed to achieve real interoperability: it doesn't specify whether to 
do a phase 2 Diffie-Hellman exchange for perfect forward secrecy, nor does 
it specify IKEv1 lifetime and lifesize values.  So I am left having to 
guess at what are appropriate values to use for these attributes.  And 
once I do choose particular values for PFS and lifesize, is it still 
correct for me to use the RFC's suite names in reference to them?

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

---

From: Yoav Nir <[email-masked]>
Date: Wed, 13 May 2009 23:51:32 +0300

Scott C Moonen wrote:
> do a phase 2 Diffie-Hellman exchange for perfect forward secrecy, nor 
> does it specify IKEv1 lifetime and lifesize values.  So I am left having to 
> once I do choose particular values for PFS and lifesize, is it still correct 
> for me to use the RFC's suite names in reference to them?

Interesting. I hadn't noticed that.

I guess the best thing is to do as in RFC 4308:
"                                                                          ...The initiator of this
   exchange MAY include a new Diffie-Hellman key; if it is included, it
   MUST be of type..."

IOW it's up to the initiator whether or not to do PFS, and both configurations
are OK to use the suite name. 

As for lifetimes, at least our implementation has a separate configuration for it. 
Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to actually 
specify it in the RFC.

But you are right. Especially since this is a followup to RFC 4869, they should have 
included these parameters. 
Email secured by Check Point

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 May 2009 14:11:07 -0700

>are OK to use the suite name.

That was my intention in RFC 4308; I cannot speak for the authors of RFC 4869.

>Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to actually

Fully disagree. "Negotiated" in IKEv1 is the wrong word: the responder either accepts what the initiator says, or stops. Most IKEv1 systems require that lifetimes match exactly; that's why I had to include section 2.3 in RFC 4308. Having said that, it is fine for a profile not to list lifetimes explicitly; it just means that the two sides still have to agree to lifefimes out-of-band.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 May 2009 09:29:02 +0300

Paul Hoffman wrote: 
>
> >IOW it's up to the initiator whether or not to do PFS, and both 
> >configurations are OK to use the suite name.
> 

You can't speak for them, but Scott has to figure it out.

> >Lifetimes in IKEv1 are negotiated, so I don't believe it's 
> necessary to 
> >actually specify it in the RFC.
> 
> Fully disagree. "Negotiated" in IKEv1 is the wrong word: the 
> responder either accepts what the initiator says, or stops. 
> Most IKEv1 systems require that lifetimes match exactly; 
> that's why I had to include section 2.3 in RFC 4308. Having 
> said that, it is fine for a profile not to list lifetimes 
> explicitly; it just means that the two sides still have to 
> agree to lifefimes out-of-band.

Not necessary at all. The RESPONDER-LIFETIME notification described in section 4.6.3.1 or RFC 2407 allows for a negotiation of the SA lifetime. True, section 4.5.4 says you may also fail the negotiation or stop using the SA prematurely, but that would be the wrong implementation choice.

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 14 May 2009 08:31:47 -0400

>    exchange MAY include a new Diffie-Hellman key; if it is included, it

That makes sense philosophically, but I would like to get the RFC updated 
or clarified rather than assume that.

> Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to 
actually 

But that equivocates on the notion of what constitutes a "suite" when 
compared to RFC 4308, and it also doesn't make sense considering that 
lifetime and lifesize are represented alongside algorithm choice in the 
IKEv1 proposal.  So this creates problems for implementations like ours 
(unlike yours) that take the natural approach of including lifetime and 
lifesize in their notion of a reusable suite object.  We now must 
implement some sort of partially-defined suite object as a kind of 
abstract class that leaves the lifetime and lifesize undefined.  That's 
not an elegant approach to workaround what I am hoping is just an 
oversight in the RFC.

From:
Yoav Nir <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS, "[email-masked]" <[email-masked]>
Date:
05/13/2009 04:53 PM
Subject:
RE: [IPsec] RFC 4869 questions

> once I do choose particular values for PFS and lifesize, is it still 
correct 

configurations

As for lifetimes, at least our implementation has a separate configuration 
for it. 
Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to 
actually 
specify it in the RFC.

But you are right. Especially since this is a followup to RFC 4869, they 
should have 
included these parameters. 
Email secured by Check Point