diff --git a/eesp-ikev2.org b/eesp-ikev2.org index 182688d..b062f67 100644 --- a/eesp-ikev2.org +++ b/eesp-ikev2.org @@ -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 . 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 +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 +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) -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 . ** Multiple Sender Group SA Key Derivation @@ -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 | +|--------+----------------------------------------+-----------------+ +| | 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 @@ -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 - 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 - +Sub SA Key Derivation Function IDs". The initial values of this +registry are: + +#+caption: "Transform Type " 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 @@ -559,6 +622,7 @@ TBD ** RFC8750 ** RFC4555 ** RFC4106 +** RFC5869 ** I-D.mrossberg-ipsecme-multiple-sequence-counters ** I-D.ponchon-ipsecme-anti-replay-subspaces