> > 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
