Sub SA KDF negotiation and key derivation updated #6
Conversation
tobiasbrunner
force-pushed
the
kdf-updates
branch
from
c2970c0 to
25e7e09
Compare
|
|
||
| SK_ai, SK_ar, SK_ei, SK_er. Each of these keys MUST be used as master key to derive | ||
| further Sub SA specific key. | ||
| KEYMAT_sub = SSKDF(SK_sub, SPI | Session_ID, L) |
There was a problem hiding this comment.
SPI is probably not good choice, that is reusing SPI for more than one purpose. IETF do not re-use parameters for multiple purposes, unlike PSP.
May be a better choice would be a double call; to add entropy or follow something like AEAD SST draft-mattsson-cfrg-aes-gcm-sst
KEYMAT_sub = SSKDF(SK_sub, SSKDF(Session_ID, L))
There was a problem hiding this comment.
The EESP SPI is currently not used for the key derivation (the IKEv2 SPIs are used to derive SK_d and KEYMAT only uses that, the nonces and optionally a KE secret), or what purpose are you referring to? (If you mean in the header, then we couldn't use the Session ID either, no?) And why would double-calling the KDF "add" entropy (it's not a secret value either way, so it really does not add any entropy at all)? In the HKDF-Expand context, this field is called "info" and is defined as "optional context and application specific information", section 3.2 in RFC 5869 says: "Its main objective is to bind the derived key material to application- and context-specific information. For example, 'info' may contain a protocol number, algorithm identifiers, user identities, etc." and "There is one technical requirement from 'info': it should be independent of the input key material value IKM.", which it is, as neither the SPI nor the Session ID is used to derive SK_sub.
| If an SSKDF is selected as part of the proposal, instead of directly | ||
| taking keys for the Sub SAs from KEYMAT, as described in section 2.17 | ||
| of [[RFC7296]], only one "root" key is taken for each EESP SA of the | ||
| Child SA. Their length is determined by the key size of the |
There was a problem hiding this comment.
one root key for both directions?
What if the Encryption and Integrity are sperate kesys?
I think the IKE should derive using RFC 7296 2.17, i.e. SK_ei, SK_ai, SK_er, SK_ar . ESP sub system Sub should expand each of these when necessary for Sub SA.
There was a problem hiding this comment.
one root key for both directions?
No, two. Each Child SA creates two EESP SAs, so one root key is taken for each one (as the text says).
What if the Encryption and Integrity are sperate kesys?
These keys (from KEYMAT_sub) are the ones derived with SSKDF for each Sub SA using the root key of the corresponding EESP SA (SK_sub).
I think the IKE should derive using RFC 7296 2.17, i.e. SK_ei, SK_ai, SK_er, SK_ar
Note that SK_ei etc. are the IKE keys. The Child SA keys are not explicitly named. How they are derived (first encryption, if any, then integrity, if any) is specified in the bullet points in 2.17 and I specified that accordingly here in how to get them from KEYMAT_sub.
There was a problem hiding this comment.
Maybe the "one" there is a bit confusing, could be replaced with an "a".
There was a problem hiding this comment.
I think this gets more complicated. a "root" key is taken for each EESP SA. do you mean root key per direction?
RFC 7296 2.17 is confusing only defining keymat and specifying multiple SA. That keymat is used for both directions and possibly ESP and AH too. However, Sub SA KDF would only be aware of one direction KEYMAT. Also assuming we don't allow EESP + AH combinations?
There was a problem hiding this comment.
a "root" key is taken for each EESP SA. do you mean root key per direction?
Yes, in a regular Child SA there will be two EESP SAs (one in each direction), so there will be two root keys. I just kept it relatively generic, in case there ever is some extension that changes that and maybe only creates one or more than two. But if you think it's not necessary, we could probably explicitly state that there are two, one for each EESP SA/direction and maybe even name them SK_subi and SK_subr (but the question would then be what to use in the formula that uses SSKDF to derive KEYMAT_sub, maybe SK_subi|r? Although, | is usually used for concatenations).
That keymat is used for both directions and possibly ESP and AH too. However, Sub SA KDF would only be aware of one direction KEYMAT.
That's the same here. There is only one KEYMAT, which is used for both EESP SAs of the Child SA, but just to get their root keys, not individual encryption/integrity keys. And yes, the KEYMAT_sub for each Sub SA will then only be based on one of the two keys (the one of the corresponding EESP SA).
Also assuming we don't allow EESP + AH combinations?
That's not possible for ESP either (it's not possible to select more than one IPsec proposal/protocol per Child SA). I think the mention of "multiple IPsec protocols" in section 2.17 is a mistake, or just the authors being very generic (the RFC even mentions in section 1.7 that SA bundles are not supported anyore and if ESP and AH are combined they are to be negotiated as separate Child SAs).
There was a problem hiding this comment.
As someone who inspired the text in 2.17, I can confirm that the intention was to be generic. BTW, RFC 5857 does use this functionality - ROHC integrity keys are taken from KEYMAT in accordance with these rules. But I'm not sure anyone supports ROHC :-)
There was a problem hiding this comment.
Ah, thanks for that context. Hehe, they even work hard to make it fit: "For the purposes of this key derivation, ROHC is considered to be an IPsec protocol."
There was a problem hiding this comment.
As someone who inspired the text in 2.17,
@smyslov what does 2.17 refer as Multiple SAs?A single CREATE_CHILD_SA negotiation may result in multiple Security AssociationsIs it ESP and AH SAs or a Pair of ESP SAs? or something else?
There was a problem hiding this comment.
It clarifies directly in the next sentence: "ESP and AH SAs exist in pairs (one in each direction), so two SAs are created in a single Child SA negotiation for them."
Edit: It actually even mentions ROHC in the next part.
There was a problem hiding this comment.
a "root" key is taken for each EESP SA. do you mean root key per direction?Yes, in a regular Child SA there will be two EESP SAs (one in each direction), so there will be two root keys. I just kept it relatively generic, in case there ever is some extension that changes that and maybe only creates one or more than two. But if you think it's not necessary, we could probably explicitly state that there are two, one for each EESP SA/direction and maybe even name them SK_subi and SK_subr (but the question would then be what to use in the formula that uses SSKDF to derive KEYMAT_sub, maybe SK_subi|r? Although, | is usually used for concatenations).
That keymat is used for both directions and possibly ESP and AH too. However, Sub SA KDF would only be aware of one direction KEYMAT.
That's the same here. There is only one KEYMAT, which is used for both EESP SAs of the Child SA, but just to get their root keys, not individual encryption/integrity keys. And yes, the KEYMAT_sub for each Sub SA will then only be based on one of the two keys (the one of the corresponding EESP SA).
I propose we clarify a root key per direction with length of SSKDF. KEYMAT_sub_n would be only for nth sub SA. May be second part is over doing it. However, I think the direction part need clarification.
|
I will merge this tonight or tomorrow morning. We can polish it later too |
|
I merged. I think it would be good clarify the KEYMAT_sub is directional. |
No description provided.