Unsubscribe ----- Original Message ----- From: ipsec-boun...@ietf.org <ipsec-boun...@ietf.org> To: Valery Smyslov <sva...@gmail.com> Cc: IPsecme WG <ipsec@ietf.org>; Yoav Nir <y...@checkpoint.com>; Paul Hoffman <paul.hoff...@vpnc.org> 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