Subject: [IPsec] Issue #139: Keying material taken in the order for RoHC

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Jan 2010 18:26:48 -0800

One of the differences between RFC 4306 and the IKEv2bis draft is in
 Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the
 IKEv2bis draft indicates the following:

 In Section 2.17, removed "If multiple IPsec protocols are negotiated,
 keying material is taken in the order in which the protocol headers
 will appear in the encapsulated packet" because multiple IPsec
 protocols cannot be negotiated at one time.

 Is it possible to leave the quoted text in the spec? I agree that multiple
 IPsec protocols cannot be negotiated at one time; however, the text is
 useful for ROHCoIPsec implementers, where multiple keys may need to be
 generated for a ROHC-enabled Child SA.

 For example, if a ROHC-enabled Child-SA with ROHC_INTEG [draft-ietf-rohc-
 ikev2-extensions-hcoipsec-09] is instantiated, first the IPsec
 encryption/authentication keying material will be taken, then an
 additional key will be taken for the algorithm used to verify the proper
 decompression of packet headers.

 Also:

 The original text in RFC 4306 was slightly confusing, but I think we
 should leave room for ROHCoIPsec here. Perhaps adding something like
 this after the bulleted list?

    If the Child SA negotiation includes some future IPsec protocol(s)
    in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then
    (1) all keys for SAs carrying data from the initiator to the
    responder are taken before SAs going in the reverse direction, and
    (2) keying material for the IPsec protocols are taken in the order
    in which the protocol headers will appear in the encapsulated
    packet.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Jan 2010 10:18:14 +0200

I think extensions such as RoHC that change (or extend) the way keying material is generated, should and do specify how it is done. Leaving that text there becomes a  recommendation for future draft writers, which I think is superfluous.

I think we should leave the text as it is.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Jan 2010 11:55:47 +0300

Hi Yoav,

> I think extensions such as RoHC that change (or extend) the way keying
material is generated, should and do specify how it is done.

I don't think so. If multiple protocols are involves, the way how (in which
order)
each of them obtains its key from IKE keying material is in general out of
scope of
individual protocol specifications. Look, for example, at ESP, where
one generic rule exists, regardless of algorithms involved: first we take
keying bits for encryption (or combined) algorithm and then for
authentication algorithm.

Proposed text establishes similar generic rule for protocols.

I support adding proposed text to help interoperability.

Regards,
Valery Smyslov.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 21 Jan 2010 13:40:13 +0200

Yoav Nir writes:
> I think extensions such as RoHC that change (or extend) the way
> keying material is generated, should and do specify how it is done.
> Leaving that text there becomes a  recommendation for future draft
> writers, which I think is superfluous. 

RoHC has text which explains how the keying material is generated, but
the problem comes when someone combines RoHC and some other extension
which also requires keying material. If we have generic rules in the
IKEv2bis (as we did have in RFC4306) then those two extensions can be
combined together by using those generic rules.

Currently RoHC says:

      1.  The keys (one for each direction) for this Integrity Algorithm
          are derived from the IKEv2 KEYMAT (see [IKEV2], Section 2.17).
          For the purposes of this key derivation, ROHC is considered to
          be an IPsec protocol.  When a ROHC-enabled CHILD_SA is
          rekeyed, the key associated with this integrity algorithm is
          rekeyed as well.

and that reference in RFC4306 section 2.17 said:

   Keying material MUST be taken from the expanded KEYMAT in the
   following order:

      All keys for SAs carrying data from the initiator to the responder
      are taken before SAs going in the reverse direction.

      If multiple IPsec protocols are negotiated, keying material is
      taken in the order in which the protocol headers will appear in
      the encapsulated packet.

      If a single protocol has both encryption and authentication keys,
      the encryption key is taken from the first octets of KEYMAT and
      the authentication key is taken from the next octets.

   Each cryptographic algorithm takes a fixed number of bits of keying
   material specified as part of the algorithm.

Now when we removed that text from 2.17 that will force RoHC document
to either still refer to RFC4306 or cut & paste that text from RFC4306
section 2.17 to its document. 

I think this generic rule was good in the RFC4306, as it makes it
definite how keying material is derived even when there are multiple
extensions present. Removing that in the IKEv2bis does not gain us
anything, but will remove text that is then needed to be copied to
each extension and which needs to be made sure that stays same in each
extension.

> >    in which the protocol headers will appear in the encapsulated

This leaves out the third bullet, i.e. "3) if single protocol has both
encryption and authentication keys, the encryption key is taken first
and the authentication key after the encryption key."
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Jan 2010 19:48:24 +0300

> each extension and which needs to be made sure that stays same in each

I agree.

> and the authentication key after the encryption key."

This bullet is probably superfluous and incomplete.

First, RFC4301 already has the same requirement (section 4.5.2):

   To ensure that the IPsec implementations at each end of
   the SA use the same bits for the same keys, and irrespective of which
   part of the system divides the string of bits into individual keys,
   the encryption keys MUST be taken from the first (left-most,
   high-order) bits and the integrity keys MUST be taken from the
   remaining bits.  The number of bits for each key is defined in the
   relevant cryptographic algorithm specification RFC.  In the case of
   multiple encryption keys or multiple integrity keys, the
   specification for the cryptographic algorithm must specify the order
   in which they are to be selected from a single string of bits
   provided to the cryptographic algorithm.

And second, it defines only the order of encryption and authentication keys.
If some some bits need to be derived for some other purposes (like nonces
in GCM and CCM, etc.), this paragraph doesn't help at all.

So, I think it is better to rely on RFC4301 here and leave 3rd bullet out.

Regards,
Valery Smyslov.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 21 Jan 2010 22:47:14 +0200

> So, I think it is better to rely on RFC4301 here and leave 3rd bullet out.

That is fine by me. I didn't remember that RFC4301 already has text
like that.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 21 Jan 2010 16:25:12 -0500

> > If some bits need to be derived for some other purposes (like nonces

That also works for the GCM and CCM examples because their necessary details
are already specified in the GCM and CCM RFCs.  GCM and CCM actually take salt
values for nonces (as opposed to the nonces themselves from the generated keying
material.  The RFCs for these two transforms are carefully written to specify
that one larger chunk of keying material is taken and then divided into salt
and key (see RFC 4106, Section 8.1 and RFC 4309, Section 7.1).

What this means is that from the point of view of how the generated keying
material is consumed, a GCM or CCM salt is logically part of a larger
encryption key.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 22 Jan 2010 09:45:01 +0300

> material is consumed, a GCM or CCM salt is logically part of a larger

Yes, I know it. Probably my example was a bit misleading. I meant that if
some
future protocol consumes key bits for purposes other than encryption or
authentication
(for example, some compression algorithm that needs to be initialized with
unpredictable
data), the 3rd bullet from RFC4306 will not work.

And, I think, it is better to rely on text from RFC4301 from architectural
point of view:
IKE defines rules for deriving keys for child SAs from keying material
(treating each child
SA key as one entity), and protocol specifications define rules for deriving
individual
keys from that child SA key (currently RFC4301 defines such rule for ESP and
AH).

Regards,
Valery Smyslov.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Jan 2010 10:39:07 -0800

I have closed the issue, but wanted to post my new text because it rearranges some of Valery's proposed text. Please reply on this thread if you think I have muffed it.

   A single CHILD_SA negotiation may result in multiple security
   associations.  ESP and AH SAs exist in pairs (one in each direction),
   so two SAs are created in a single Child SA negotiation for them.
   Furthermore, Child SA negotiation may include some future IPsec
   protocol(s) in addition to, or instead of.  ESP or AH (for example,
   ROHC_INTEG).  In any case, keying material for each child SA MUST be
   taken from the expanded KEYMAT using the following rules:

   o  All keys for SAs carrying data from the initiator to the responder
      are taken before SAs going from the responder to the initiator.

   o  If an IPsec protocol requires multiple keys, the order in which
      they are taken from KEYMAT needs to be described in protocol
      specification.  For ESP  and AH, [IPSECARCH] defines the order,
      namely: the encryption key (if any) MUST be taken from the first
      bits and the integrity key (if any) MUST be taken from the
      remaining bits.

   o  If multiple IPsec protocols are negotiated, keying material is
      taken in the order in which the protocol headers will appear in
      the encapsulated packet.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 26 Jan 2010 22:48:05 +0300

Paul Hoffman writes:

>I have closed the issue, but wanted to post my new text because it 
>rearranges some of Valery's proposed text. Please reply on this thread if 
>you think I have muffed it.
>

Erroneous period after "instead of".

>      they are taken from KEYMAT needs to be described in protocol

I'm afraid that KEYMAT here might be confused with KEYMAT as
the source for all keys (output of prf+). They are not the same. Here we
already have already taken all the necessary key bits for particular child 
SA
from KEYMAT (output of prf+), and we are talking how individual keys
should be extracted from them if this SA's protocol requires several keys
(e.g. for encryption and for authentication). I would prefer using term
"SA's keying material" to avoid confusion.

>   o  If multiple IPsec protocols are negotiated, keying material is

Probably it's worth adding "for each child SA" after "keying material"
for clarification.

>      taken in the order in which the protocol headers will appear in

I would still prefer swapping the last two bullets, as it will be more 
logical order:
first 2 bullets describe how to extract SA's keyng material from KEYMAT
and 3rd - how to extract individual keys from SA's keying material.
But I won't insist on that.

Regards,
Valery Smyslov.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Jan 2010 18:41:10 -0800

All good points, Valery. Here's another attempt; please check carefully.

   protocol(s) in addition to, or instead of, ESP or AH (for example,

   o  If multiple IPsec protocols are negotiated, keying material for
      each Child SA is taken in the order in which the protocol headers
      will appear in the encapsulated packet.

   o  If an IPsec protocol requires multiple keys, the order in which
      they are taken from the SA's keying material needs to be described
      in protocol specification.  For ESP  and AH, [IPSECARCH] defines
      the order, namely: the encryption key (if any) MUST be taken from
      the first bits and the integrity key (if any) MUST be taken from
      the remaining bits.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 27 Jan 2010 09:40:49 +0300

>       the first bits and the integrity key (if any) MUST be taken from

Looks fine to me.

Regards,
Valery Smyslov.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 27 Jan 2010 11:21:13 +0200

> >       the first bits and the integrity key (if any) MUST be taken from

Looks good for me too.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Wed, 27 Jan 2010 13:44:57 +0100

+1.

Best regards,
Pasi
(not wearing any hats)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Tero Kivinen
> Sent: 27 January, 2010 11:21
> To: Valery Smyslov
> Cc: [email-masked]; [email-masked]; Paul Hoffman
> Subject: Re: [IPsec] Issue #139: Keying material taken in the order for
> RoHC
> 
> Valery Smyslov writes:
> > Paul Hoffman writes: