Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
+1. Best regards, Pasi (not wearing any hats) > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of ext Tero Kivinen > Sent: 27 January, 2010 11:21 > To: Valery Smyslov > Cc: ipsec@ietf.org; black_da...@emc.com; Paul Hoffman > Subject: Re: [IPsec] Issue #139: Keying material taken in the order for > RoHC > > Valery Smyslov writes: > > Paul Hoffman writes: > > > All good points, Valery. Here's another attempt; please check > carefully. > > > > > >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 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. > > > > Looks fine to me. > > Looks good for me too. > -- > kivi...@iki.fi > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
Valery Smyslov writes: > Paul Hoffman writes: > > All good points, Valery. Here's another attempt; please check carefully. > > > >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 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. > > Looks fine to me. Looks good for me too. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
Paul Hoffman writes: > All good points, Valery. Here's another attempt; please check carefully. > >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 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. Looks fine to me. Regards, Valery Smyslov. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
All good points, Valery. Here's another attempt; please check carefully. 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 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
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. 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, Erroneous period after "instead of". 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 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. 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 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 the encapsulated packet. 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
> > So, I think it is better to rely on RFC4301 here and leave 3rd bullet out. > > 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. 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
> > > 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." > > > > 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 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. 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 black_da...@emc.com Mobile: +1 (978) 394-7754 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
Unsubscribe - Original Message - From: ipsec-boun...@ietf.org To: Valery Smyslov Cc: IPsecme WG ; Yoav Nir ; Paul Hoffman Sent: Thu Jan 21 15:47:14 2010 Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC Valery Smyslov writes: > > 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." > > 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. That is fine by me. I didn't remember that RFC4301 already has text like that. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
Valery Smyslov writes: > > 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." > > 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. That is fine by me. I didn't remember that RFC4301 already has text like that. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
Tero Kivinen writes: > 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. I agree. > > >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. > > 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." 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
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. > >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. 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." -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
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. > On Jan 19, 2010, at 4:26 AM, Paul Hoffman wrote: > > > 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 > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
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. On Jan 19, 2010, at 4:26 AM, Paul Hoffman wrote: > 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
