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
