Yoav Nir writes:
> Issue #139 - Keying material taken in the order for RoHC
> ========================================================
> One of the differences between RFC 4306 and the IKEv2bis draft is in
Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the
IKEv2bis draft indicates the following:
> In Section 2.17, removed "If multiple IPsec protocols are negotiated,
keying material is taken in the order in which the protocol headers will
appear in the encapsulated packet" because multiple IPsec protocols cannot
be negotiated at one time.
> Is it possible to leave the quoted text in the spec? I agree that multiple
IPsec protocols cannot be negotiated at one time; however, the text is
useful for ROHCoIPsec implementers, where multiple keys may need to be
generated for a ROHC-enabled Child SA.
> For example, if a ROHC-enabled Child-SA with ROHC_INTEG
[draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, first the
IPsec encryption/authentication keying material will be taken, then an
additional key will be taken for the algorithm used to verify the proper
decompression of packet headers.
>
> I said I preferred to leave the text as it is, and let RoHC specify their
modifications (which they did). Valery, Tero, and David chimed in, correctly
pointing out that if multiple extensions are negotiated (RoHC + GCM + some
future extension) it is up to the base document to specify the order between
them. I'm convinced. Paul also suggested some text (below) for a bulleted
list of two points. Tero suggested a third (encryption before
authentication), but Valery pointed out that this is already in 4301.
>
> 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.
>
> If anyone else has comments about this issue, please raise them NOW,
because we are going to close this in a few days.
Sorry for being tedious, but I don't understand whether proposed text is in
addition
to current one, or replaces it. Current text from draft-07 overlaps with
RFC4301,
which already prescribes the order for deriving encryption and
authentication keys
for single SA. I see no point to repeat this rule (at least in RFC2119
terms).
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.
========================================================
Regards,
Valery Smyslov.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
