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
