Valery Smyslov writes: > I would suugest replacing current text from draft-07: > ======================================================== > For ESP and AH, a single Child SA negotiation results in two security > associations (one in each direction). Keying material MUST be taken > from the expanded KEYMAT in the following order: > > o The encryption key (if any) for the SA carrying data from the > initiator to the responder. > > o The authentication key (if any) for the SA carrying data from the > initiator to the responder. > > o The encryption key (if any) for the SA carrying data from the > responder to the initiator. > > o The authentication key (if any) for the SA carrying data from the > responder to the initiator. > ======================================================== > > with the following: > ======================================================== > 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 (e.g., ROHC_INTEG). > In any case, keying material for each child SA MUST be taken from the > expanded KEYMAT in the following order: > > o All keys for SAs carrying data from the initiator to the responder > are taken before SAs going in the reverse direction. > > 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. > > If IPsec protocol requires multiple keys, the order in which they are > derived > from SA's keyng material MUST 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. > ========================================================
That change looks fine for me. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
