Skip to content

Sub SA KDF negotiation and key derivation updated #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
antonyantony merged 1 commit into from
Feb 12, 2025
Merged

Sub SA KDF negotiation and key derivation updated #6

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
150 changes: 107 additions & 43 deletions eesp-ikev2.org
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -338,63 +338,91 @@ each Sub SA independently. This ensures that traffic is correctly
routed and prevents ambiguity in handling packets associated with
different Sub SAs when a NAT is present.

** Key derivation for Sub SA
** Key Derivation for Sub SAs

# [[RFC7296]] section 2.17 specifies Child SA key generation.
When an EESP SA is using Sub SAs, each Sub SA (including the one
with Session ID 0) uses separate keys. This allows each Sub SA to use
its own independent Sequence Number and IV space.

When the EESP SA is negotiated with a Sub SA Keys (SUB_SA_ID), each
Sub SA derives its own unique keys. This allows each Sub SA
its own independent Sequence Number space, and independent IV space.
In order to derive these keys, a Sub SA Key Derivation Function
(SSKDF) is negotiated as part of the proposal of the EESP SA using
Transform Type <TBD2>. This SSKDF is independent of the PRF
negotiated for IKEv2.

The requirements:
- Independent keys for each Sub SA
- Ability to derive Sub SA keys on the fly with least amount of memory usage
- Minimal memory requirements
- Keyderviation support multiple SAs, such as EESP, AH
- Use the same Crypto primitive as used for encryption e.g. AES-*
If no Sub SAs are to be used for an EESP SA, Transform Type <TBD2>
SHOULD be omitted in the proposal, but it MAY be NONE. If it's
omitted or NONE is selected by the responder, Sub SAs MUST NOT be
created by either peer and the key derivation for the in- and
outbound EESP SAs of the Child SA are done as described in section
2.17 of [[RFC7296]].

*** Hierarchical key derivation
Hierarchical key derivation use Sub SA ID, which is carried in EESP
Seesion ID or in EESP Flow ID(TLV), as an input to the key dervivation.
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
Copy link
Collaborator

@antonyantony antonyantony Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

@tobiasbrunner tobiasbrunner Feb 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

@tobiasbrunner tobiasbrunner Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the "one" there is a bit confusing, could be replaced with an "a".

Copy link
Collaborator

@antonyantony antonyantony Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

@tobiasbrunner tobiasbrunner Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Collaborator

@smyslov smyslov Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :-)

Copy link
Collaborator Author

@tobiasbrunner tobiasbrunner Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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."

Copy link
Collaborator

@antonyantony antonyantony Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Associations Is it ESP and AH SAs or a Pair of ESP SAs? or something else?

Copy link
Collaborator Author

@tobiasbrunner tobiasbrunner Feb 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

@antonyantony antonyantony Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

negotiated SSKDF. The root key for the EESP SA carrying data from
the initiator to the responder is taken before that for the SA going
from the responder to the initiator.

Section 2.17 [[RFC7296]] specifies a KEYMAT derivation. The KEYMAT is split into
Using the EESP SA's root key, SK_sub, the KEYMAT for each Sub SA is
derived as follows:

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)
Copy link
Collaborator

@antonyantony antonyantony Feb 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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))

Copy link
Collaborator Author

@tobiasbrunner tobiasbrunner Feb 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


SK_S_xx = prf+(prf+(SK_xx,Sub SA ID))
Where L is the total length of the key material KEYMAT_sub and the
salt value is comprised of the full SPI and the full Session ID of
the Sub SA.

for e.g. SK_S_ei = prf+(prf+(SK_ei, Sub SA ID))
If multiple keys are required for a Sub SA, the encryption key MUST
be taken from the first bits of KEYMAT_sub, the integrity key MUST be
taken from the remaining bits.

The Sub SA keys can be derived in ESP sub system or in IKE sub system when pre installing
all SAs and keys.
Keys for Sub SAs may be derived immediately or on demand when the
first packet is processed. Memory constrained implementations may
even decide to derive the Sub SA keys on the fly for each received
packet as only SK_sub has to be stored to derive the keys of all
Sub SAs.

One advantage of Hierarchical KDF is the Sub SA keys MAY BE
generated on the fly, for every packet, when available fast memory
is limited, for example [[PSP]]. This is usually the case when key
derivation is implemented in hardware. When implimenting in hardware
choose a hardware friendly prf+.
Because individual Sub SAs can't be rekeyed, the complete EESP Child
SA MUST be rekeyed when either a cryptographic limit or a time-based
limit is reached for any individual Sub SA.

** Rekey Key Derivation.
During the EESP SA rekey, a new KEYMAT is derived using the new Ni
and Nr values. If a Key Exchange (KE) method was used in the rekying,
CREATE_CHILD_SA exchange, the new key MAY also include g^ir as part of
the derivation process.
*** Sub SA Key Derivation Function Transform

Even though each Sub SA can be independently rekeyed, for
simplicity, all Sub SAs MUST be rekeyed together
when either a cryptographic limit or a time-based limit is
reached.
The new Sub SA Key Derivation Function (SSKDF) transform is used to
negotiate a key derivation function for Sub SAs as described in the
previous section.

The time-based limit, also described in Section 2.8 of
[RFC7296], ensures periodic key replacement to minimize the risks
associated with long-term key exposure, even if the cryptographic
limit has not been reached.
This document creates a new IKEv2 IANA registry for key derivation
functions that can be negotiated with this transform type. The
initially defined Transform IDs are listed in the table below.

When rekeying is triggered for any of the Sub SA by whichever
limit—cryptographic or time- based—is reached first, subseqenty all
Sub SAs must rekeyed.
#+caption: Sub SA Key Derivation Functions
| Value | Algorithm |
|---------+---------------------+
| 0 | NONE |
| 1 | SSKDF_HKDF_SHA2_256 |
| 2 | SSKDF_HKDF_SHA2_384 |
| 3 | SSKDF_HKDF_SHA2_512 |
| 4 | SSKDF_AES256_CMAC |

These algorithms are defined as follows:

- SSKDF_HKDF_SHA2_256, SSKDF_HKDF_SHA2_384 and SSKDF_HKDF_SHA2_512
use HKDF-Expand defined in [[RFC5869]] with the indicated hash
functions, that is, SHA-256, SHA-384 or SHA-512, respectively, with
corresponding key sizes of 32, 48 and 64 octets. SSKDF is then
defined as:

SSKDF(K, S, L) = HKDF-Expand(K, S, L)

- SSKDF_AES256_CMAC is currently undefined

Other key derivation functions may be added after the publication of
this document. Readers should refer to [[IKEv2-IANA]] for the latest
values.

The type of the Sub SA Key Derivation Function transform is <TBA2>.

** Multiple Sender Group SA Key Derivation

Expand Down Expand Up @@ -458,11 +486,21 @@ This document defines new Protocol ID in the
|-------------+----------+-----------------+
| [TBD1] | EESPv0 | [this document] |

*** IKEv2 Transform Type Values

#+caption: "Transform Type Values" Registry
| Type | Description | Reference |
|--------+----------------------------------------+-----------------+
| <TBD2> | Sub SA Key Derivation Function (SSKDF) | [this document] |

This new Transform Type is only valid for EESP. Valid Transform IDs
are defined in a new registry listed in [[tbl-sskdfids]].

*** IKEv2 Notify Message Status Types registry.

| Value | Notify Message Status Type | Reference |
|-------+----------------------------+-----------------+
| TBD8 | USE_EESP_CRYPTOFFSET | [this document] |
| TBD3 | USE_EESP_CRYPTOFFSET | [this document] |

*** Extending ESP with EESP
Several tables in [[IKEv2-IANA]] that specify ESP as protocol
Expand All @@ -482,6 +520,31 @@ This document defines a new value in the IKEv2 "Transform Type 5 - Sequence
| [TBD9] | 64-bit Sequential Numbers | [this document] |
| [TBD10] | None | [this document] |

** New IKEv2 Registries

*** Transform Type <TBD2> - Sub SA Key Derivation Function IDs

# what KDFs should we actually define here? more/less?
# SSKDF_AES256_CMAC is currently unspecified

This documents creates the new IKEv2 registry "Transform Type <TBD2> -
Sub SA Key Derivation Function IDs". The initial values of this
registry are:

#+caption: "Transform Type <TBD2>" Registry
#+name: tbl-sskdfids
| Number | Name | Reference |
|---------+-------------------------------+-----------------+
| 0 | NONE | [this document] |
| 1 | SSKDF_HKDF_SHA2_256 | [this document] |
| 2 | SSKDF_HKDF_SHA2_384 | [this document] |
| 3 | SSKDF_HKDF_SHA2_512 | [this document] |
| 4 | SSKDF_AES256_CMAC | [TBD] |
| 5-1023 | Unassigned | [this document] |
| 1024-65535| Private use | [this document] |

Changes and additions to the unassigned range of this registry are
by the Expert Review Policy [[RFC8126]].

* Implementation Status

Expand Down Expand Up @@ -559,6 +622,7 @@ TBD
** RFC8750
** RFC4555
** RFC4106
** RFC5869

** I-D.mrossberg-ipsecme-multiple-sequence-counters
** I-D.ponchon-ipsecme-anti-replay-subspaces
Expand Down