Subject: [IPsec] Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE

From: "Frankel, Sheila E." <[email-masked]>
Date: Thu, 3 Dec 2009 13:41:38 -0500

This is an initial attempt to resolve Issue #113. We would appreciate comments/suggestions/alternate approaches.

#113: Use of AES-XCBC in IKE

 Currently, the Req levels are SHOULD for IKEv1 (based on RFC4109) and optional for IKEv2. The Req levels for AES-XCBC-PRF are SHOULD (based on RFC4109) and SHOULD+ for IKEv2 (RFC4307)

 This leaves us with 2 questions:
 1) If there is no IANA value for AES-XCBC in IKEv1, how can RFC4109 recommend (SHOULD) its use?
 2) If AES-XCBC and AES-XCBC-PRF can be used in IKEv1, what should be proposed? What should you propose if you want AES-XCBC for both a PRF and an integrity-protection algorithm in IKEv1?

Proposed change to Roadmap doc:

Add text to Section 5.5 - Pseudo-Random Functions (PRFs):

For each IKEv2 SA, the peers negotiate both a PRF algorithm and an
integrity-protection algorithm; the former is used to generate keying
material and other values, and the latter is used to provide protection
to the IKE SA's traffic.

IKEv1's approach is more complicated.  IKEv1 [RFC2409] does not specify
any PRF algorithms. For each IKEv1 SA, the peers agree on an unkeyed
hash function (e.g., SHA-1). IKEv1 uses the HMAC version of this function
to generate keying material and to provide integrity protection for the
IKE SA.  If the peers want to use a PRF that is not an HMAC variant (e.g.,
AES-XCBC-PRF-128), they must negotiate both a PRF and a hash function.
If AES-XCBC-PRF-128 is the negotiated PRF, then IKEv1 would use
AES-XCBC-PRF-128 (not truncated) as a PRF and AES-XCBC-MAC-96 (truncated)
for integrity-protection.  The negotiated hash algorithm would be used
for example when generating the NAT-D [RFC3947] payloads.  If an IKEv1
proposal includes a PRF algorithm but not a hash, it must be rejected,
as specified in [RFC2409].

NOTE: This solution would require adding an IANA value to the iana-ipsec-registry for AES-XCBC-PRF-128

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Dec 2009 12:35:42 +0200

Frankel, Sheila E. writes:
> This is an initial attempt to resolve Issue #113. We would
> appreciate comments/suggestions/alternate approaches. 
> 
>  Currently, the Req levels are SHOULD for IKEv1 (based on RFC4109)
>  and optional for IKEv2. The Req levels for AES-XCBC-PRF are SHOULD
>  (based on RFC4109) and SHOULD+ for IKEv2 (RFC4307) 
> 
>  2) If AES-XCBC and AES-XCBC-PRF can be used in IKEv1, what should
>  be proposed? What should you propose if you want AES-XCBC for both
>  a PRF and an integrity-protection algorithm in IKEv1? 

I would say as we are talking here about the obsoleted IKEv1 protocol,
and these problems have already been solved in the IKEv2, there is no
need to do anything for IKEv1 registries.

As nobody has yet to noticed that there is no number of AES-XCBC PRF
for IKEv1, I assume nobody has implemented it. If it has not been
implemented, then I do not think vendors will add implementation of it
to the obsoleted IKEv1 protocol, thus there will never be
implementations for it.

Usually the hash/mac functions used to protect IKEv1 SA do not matter
that much to users, they only care what algorithms are used in the
IPsec SAs. Currently AES-XCBC-MAC-96 can be used in those contexts
fine both in IKEv1 and IKEv2, thus there is no problem there.

There is no need to get AES-XCBC PRF to work when protecting IKEv1
SAs.

> IKE SA.

Up to this it is fine. 

> If the peers want to use a PRF that is not an HMAC variant (e.g.,

But I would remove all of these, and simply say that:

  Currently there is no PRF functions defined for IKEv1, thus only
  PRFs which can be used are the HMAC versions of the unkeyed hash
  functions. AES-XCBC-PRF-128 could be defined also in IKEv1, but as
  there is no IANA number allocated for it, currently it cannot be
  used in IKEv1.

> as specified in [RFC2409].

This text above, is something that should be in the RFC specifying the
PRF, not in this document, as it mostly seems to be clarification to
the RFC2409. I do not think this document can add this kind of almost
normative text for any other documents.. 

> iana-ipsec-registry for AES-XCBC-PRF-128 

If nobody has cared about using AES-XCBC-PRF-128 in protecting the
IKEv1 SA for 6 (or 11) years, I do not think people will start using
it now, thus I suggest we just say it cannot be used.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Dec 2009 10:10:09 -0800

<no hat>

>need to do anything for IKEv1 registries.

Agree.

>There is no need to get AES-XCBC PRF to work when protecting IKEv1

Agree.

>  there is no IANA number allocated for it, currently it cannot be

Partially agree. I would remove the proposed sentence and add nothing. There is no reason to go into detail about what we don't intend to do.

>normative text for any other documents..

Very strongly agree. And the fact that it has not been asked for before now says that even thinking about it is unnecessary.

>it now, thus I suggest we just say it cannot be used.

A sentence that says "Therefore PRFs that are not HMACs cannot currently be used" sums up the current state of affairs succinctly

--Paul Hoffman, Director
--VPN Consortium