Subject: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Oct 2009 16:40:59 +0300

I was reading the USGv6 profile, and it complained that RFC4307 and
RFC4835 do not agree on status of NULL encryption. RFC4307 says MAY,
and RFC4835 says MUST.

As far as I have understood the RFC4835 defines algorithm requirements
for Child SAs (ESP and AH), and RFC4307 defines algorithm requirements
for IKEv2 SAs, i.e. when IKEv2 protects its own traffic.

However while the roadmap document agrees on that ("[RFC4307]
specifies the encryption and integrity-protection algorithms used by
IKEv2 to protect its own traffic") it also final sentence which makes
this not so clear: "It also specifies the encryption and
integrity-protection algorithms that IKEv2 negotiates for use within
IPsec."

I.e. that last sentence would indicate that RFC4307 would also define
encryption and integrity-protection algorithms for Child SAs. On the
other hand it does not list IPsec-v2 nor IPsec-v3 on the requirements
level so that would indicate it does not apply to IPsec, only to IKE.

In the abstract RFC4307 does not clearly say whether it only covers
IKEv2 traffic or if it also covers Child SA (IPsec, ESP/AH) traffic
negotiated with IKEv2. But later in the section 3.1.1 it clearly says
that "The IKEv2 Encryption Payload requires..." which indicates it
only covers IKEv2 SA traffic not anything else.

If this is true, then the requirement level for ENCR_NULL is clearly
wrong, as RFC4306 says that ENCR_NULL MUST NOT be used when protecting
IKEv2 SA traffic (section 5. Security Considerations).

So I would suggest we remove the misleading last sentence from the
draft-ietf-ipsecme-roadmap-04.txt section 5.1.2, and make an errata
for RFC4307 saying that ENCR_NULL is "MUST NOT" instead of "MAY".

Also the USGv6 document might also distinguish the fact that RFC4835
and RFC4307 cover different protocols, thus they does not need to
agree on the requirement levels, and NULL encryption cannot really be
required for IKEv2 as it would go against MUST NOT in RFC4306.
-- 
[email-masked]

---

From: "Frankel, Sheila E." <[email-masked]>
Date: Wed, 21 Oct 2009 09:24:55 -0400

I interpreted RFC 4307 slightly differently than Tero does, and I stand by the wording of both the USGv6 Profile and the IPsec Roadmap. Although RFC 4307's domain is limited to IKEv2, it clearly specifies both those algorithms used within IKEv2 and also those algorithms that IKEv2 negotiates for use by IPsec. That is why there are 2 separate lists of algorithms: Section 3.1.1 (Encrypted Payload Algorithms) specifies those algorithms that are used BY IKEv2 in its Encrypted Payload. Sections 3.1.3 (IKEv2 Transform Type 1 Algorithms) and 3.1.5 (IKEv2 Transform Type 3 Algorithms) lists those algorithms that IKEv2 should be able to negotiate for use within IPsec/child SAs. One detail that supports this interpretation is the inclusion of NULL encryption in section 3.1.3 - clearly, this is not appropriate in the IKE Encrypted Payload. If the applicability of Sections 3.1.3 and 3.1.5 is limited to IKEv2 SAs, then there is no need for the more constrained list in Section 3.1.1, which clearly applies only to IKEv2's payloads.

Sheila
________________________________________
From: Tero Kivinen [[email-masked]]
Sent: Tuesday, October 20, 2009 9:40 AM
To: [email-masked]
Cc: Frankel, Sheila E.; [email-masked]
Subject: RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Oct 2009 12:50:05 -0700

Looking through the archives for the IPsec WG (the predecessor to this one), Tero's interpretation is probably closer to what happened than Sheila's. It is unfortunately that both Sheila and Tero use the word "clearly" when talking about RFC 4307; the archive would strongly indicate that it is inappropriate to use that word when discussion RFC 4307.

We need to remember that the flight of documents coming out of the original WG included both RFC 4305 and RFC 4307. There was some sloppy cross-over of requirements due to a poor split late in the process. However, the WG seems to have wanted to have two different sets of requirements, one for IKEv2 crypto, and one for AH/ESP crypto. This is what makes me think that Tero's interpretation is closer to what happened, regardless of what words were (possibly inappropriately) left in RFC 4307 at the point that the WG became exhausted.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Frankel, Sheila E." <[email-masked]>
Date: Wed, 21 Oct 2009 16:08:10 -0400

If that's the case, we'll remove the offending statements in the roadmap.

Just 2 more questions: even if this was a sloppy document, why is there a separate section for IKE Encrypted Payload algorithms, that contains a subset of the Transform Type 1 (encryption) algorithms? Also, is sloppiness enough to account for both NULL encryption and AES-CTR being specified for IKEv2 - and noone from the WG noticing either?

Sheila
________________________________________
From: Paul Hoffman [[email-masked]]
Sent: Wednesday, October 21, 2009 3:50 PM
To: Frankel, Sheila E.; Tero Kivinen; [email-masked]
Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Oct 2009 13:27:35 -0700

>If that's the case, we'll remove the offending statements in the roadmap.

Assuming others remember it as I do (well, after looking at the archive), that would be great.

>Just 2 more questions: even if this was a sloppy document, why is there a separate section for IKE Encrypted Payload algorithms, that contains a subset of the Transform Type 1 (encryption) algorithms?

Because the split happened late in the process when many of us were quite burned out; we didn't review carefully.

> Also, is sloppiness enough to account for both NULL encryption and AES-CTR being specified for IKEv2 - and noone from the WG noticing either?

I think so, unfortunately.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 22 Oct 2009 11:38:54 +0300

Frankel, Sheila E. writes:
> I interpreted RFC 4307 slightly differently than Tero does, and I
> stand by the wording of both the USGv6 Profile and the IPsec
> Roadmap. Although RFC 4307's domain is limited to IKEv2, it clearly
> specifies both those algorithms used within IKEv2 and also those
> algorithms that IKEv2 negotiates for use by IPsec. That is why there
> are 2 separate lists of algorithms: Section 3.1.1 (Encrypted Payload
> Algorithms) specifies those algorithms that are used BY IKEv2 in its
> Encrypted Payload. Sections 3.1.3 (IKEv2 Transform Type 1
> Algorithms) and 3.1.5 (IKEv2 Transform Type 3 Algorithms) lists
> those algorithms that IKEv2 should be able to negotiate for use
> within IPsec/child SAs. One detail that supports this interpretation
> is the inclusion of NULL encryption in section 3.1.3 - clearly, this
> is not appropriate in the IKE Encrypted Payload. If the
> applicability of Sections 3.1.3 and 3.1.5 is limited to IKEv2 SAs,
> then there is no need for the more constrained list in Section
> 3.1.1, which clearly applies only to IKEv2's payloads. 

Hmm... Yes, it could be interpreted so also, but what is the
relationship between RFC4307 and RFC4305/4835 then. Would
RFC4305/RFC4835 then cover only manual keying and IKEv1? I always
assumed that RFC4307 talks about IKEv2 SAs and RFC4305/4835 talks
about ESP and AH (i.e. IPsec SAs aka Child SAs).

One reason I think this is the correct interpretation is that RFC4307
section 3.1.4 lists Transform Type 2 Algorithms (Pseudor-random
functions, PRFs), and those are applicable ONLY to IKEv2. IPsec
SAs/Child SAs/ESP/AH cannot have PRFs.

Also section 3.1.5 does not give any status for NONE authentication
(as it cannot be used for IKEv2 SAs), but for example RFC4305/RFC4835
both give requirement for it (MUST / MAY).
-- 
[email-masked]

---

From: <[email-masked]>
Date: Fri, 30 Oct 2009 09:54:01 +0100

Tero:

I think you're correct that RFC 4307 has a bug: ENCR_NULL
should be MUST NOT, instead of MAY (note that ENCR_NULL
in 4305/4835 is MUST). Go ahead and submit an errata
about this!

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Tero Kivinen
> Sent: 22 October, 2009 11:39
> To: Frankel, Sheila E.
> Cc: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki)
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec