Yoav Nir writes:
> I think extensions such as RoHC that change (or extend) the way
> keying material is generated, should and do specify how it is done.
> Leaving that text there becomes a recommendation for future draft
> writers, which I think is superfluous.
RoHC has text which explains how the keying material is generated, but
the problem comes when someone combines RoHC and some other extension
which also requires keying material. If we have generic rules in the
IKEv2bis (as we did have in RFC4306) then those two extensions can be
combined together by using those generic rules.
Currently RoHC says:
1. The keys (one for each direction) for this Integrity Algorithm
are derived from the IKEv2 KEYMAT (see [IKEV2], Section 2.17).
For the purposes of this key derivation, ROHC is considered to
be an IPsec protocol. When a ROHC-enabled CHILD_SA is
rekeyed, the key associated with this integrity algorithm is
rekeyed as well.
and that reference in RFC4306 section 2.17 said:
Keying material MUST be taken from the expanded KEYMAT in the
following order:
All keys for SAs carrying data from the initiator to the responder
are taken before SAs going in the reverse direction.
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 a single protocol has both encryption and authentication keys,
the encryption key is taken from the first octets of KEYMAT and
the authentication key is taken from the next octets.
Each cryptographic algorithm takes a fixed number of bits of keying
material specified as part of the algorithm.
Now when we removed that text from 2.17 that will force RoHC document
to either still refer to RFC4306 or cut & paste that text from RFC4306
section 2.17 to its document.
I think this generic rule was good in the RFC4306, as it makes it
definite how keying material is derived even when there are multiple
extensions present. Removing that in the IKEv2bis does not gain us
anything, but will remove text that is then needed to be copied to
each extension and which needs to be made sure that stays same in each
extension.
> > 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.
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."
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
