Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)
Extracted elements (27)
Independent derivation of keys from the EMSK (using different PRF inputs per child key) was chosen over a keystream approach so that child keys can be derived in any order without depending on other keys. This allows new usages to be developed without cumbersome coordination between usage definitions.
PRF+ from IKEv2 (RFC 4306) based on HMAC-SHA-256 was chosen as the default KDF for its simplicity and efficiency compared to mechanisms used in TLS (RFC 4346). The motivation for PRF+ design is described in the SIGMA paper by Krawczyk.
The NULL octet separator between the key label and optional data was chosen to prevent collisions when one key label is a prefix of another (e.g., "foobar" vs "foobarExtendedV2"), as a simpler alternative to a label assignment policy prohibiting prefixes.
It is NOT RECOMMENDED to use keys derived from the EMSK as an exclusive security mechanism when their usage is not inherently tied to the lower layer where network access authentication was performed, as this creates problematic dependencies across architectural layers.
Keys derived from EAP are pair-wise by nature and are not directly suitable for multicast or group usages. They may be used in protocols that distribute group keys, but definition of such group key distribution protocols is outside the scope of this document.
Derivation of DSRKs and USRKs MUST be specified such that no domain can obtain a USRK by providing a domain name identical to a Usage Key Label, preventing cross-namespace collisions.
Derivation of USRKs MUST be coordinated so that two separate cryptographic usages do not derive the same key. Derivation of DSRKs MUST be coordinated so that two separate key management domains do not derive the same key.
It MUST be computationally infeasible to compute the EMSK from any root key derived from it. Any root key MUST be cryptographically separate from any other root key derived from the same EMSK or DSRK.
New usage definitions MUST NOT use the MSK. If more than one usage uses the MSK, cryptographic separation is not achieved, and implementations MUST prevent such combinations.
The EMSK MUST NOT be used for any other purpose than the key derivation described in this document. It MUST be secret, maintained within a protected location, and MUST be unique for each EAP session.
The EMSK name SHALL be derived as: EMSKname = KDF(EAP Session-ID, "EMSK" | "\0" | length) where length is the 2-octet unsigned integer 8 in network byte order. It is RECOMMENDED that all keys derived from the EMSK be referred to by the EMSKname and usage context.
The same KDF MUST be used for all key derivations for a given EMSK. If no KDF is specified, the default KDF (PRF+ based on HMAC-SHA-256) MUST be used. If the initial authenticated key exchange specifies a KDF, it MUST override the default.
Usage definitions MUST define distinct key labels and optional data, MUST define the length of their Root Keys (RECOMMENDED at least 64 octets), and MUST define how Root Keys are used including all aspects of key management.
Usage definitions MUST NOT use the EMSK in any way other than to derive Root Keys via the specified derivation. They MUST NOT use the EMSK directly, and SHOULD NOT require caching of the EMSK.
USRKs MUST be at least 64 octets in length. The KDF MUST be capable of producing at least 2048 octets of output, though it is RECOMMENDED that Root Keys be at least 64 octets long.
When Root Keys are delivered to another entity, the EMSKname and the lifetime associated with the specific root keys MUST also be transported to that entity.
A Domain-Specific Root Key (DSRK) is a USRK with key label "[email protected]" and optional data containing the ASCII string representing the target key management domain. The DSRK MUST be at least 64 octets long and is used to derive DSUSRKs.
DSUSRKs are derived from a DSRK using: DSUSRK = KDF(DSRK, key label | "\0" | optional data | length). The key hierarchy is EMSK → DSRK → DSUSRK, where DSUSRKs are scoped to the same key management domain as the parent DSRK.
The default KDF is PRF+ from IKEv2 (RFC 4306) instantiated with HMAC-SHA-256. PRF+(K,S) = T1|T2|T3|... where T1=PRF(K,S|0x01), T2=PRF(K,T1|S|0x02), etc., producing up to 8160 octets (255 iterations). K is the EMSK; S is the concatenation of key label, NULL octet, optional data, and length.
The USRK derivation function takes the form: USRK = KDF(EMSK, key label | "\0" | optional data | length), where the key label is a printable ASCII string of up to 255 octets, the NULL octet prevents prefix collisions, and length is a 2-octet unsigned integer in network byte order.
IANA created a "USRK Key Labels" registry. Labels must be printable US-ASCII, case-sensitive, no more than 64 characters, assigned via Specification Required policy. Labels of the form label-string@domain require Expert Review with Specification Required. Reserved labels: "EMSK", "[email protected]", "experimental1", "experimental2", "private1", "private2".
IANA created an "EMSK PRF numbers" registry for values 0-255. Numbers 0-220 assigned via IETF Consensus; 221-255 reserved for Private Use. Initial values: 0=RESERVED, 1=HMAC-SHA-256 PRF+ (Default).
Key lifetime should not exceed that of the EMSK. If key lifetime or key strength information is available from the authenticated key exchange, it SHOULD be used in determining the lifetime of derived keys.
Root-Key-to-child-key derivation must introduce fresh random numbers for each derived key when many keys are derived from a Root Key, since no additional randomness is required in the EMSK-to-Root-Key step beyond the key labels.
The effective key strength of derived keys will never exceed the strength of the EMSK. Compromise of one USRK should not compromise other USRKs or the EMSK; the chosen KDF is believed to provide this cryptographic separation.
USRKs MUST be transported with integrity and confidentiality maintained, between authenticated and authorized parties only. The context of key usage including identifier and lifetime constraints MUST be transmitted along with the key.
The KDF input concatenates: key label (up to 255 printable ASCII octets), a NULL octet (0x00), optional data (up to 2048 octets), and a 2-octet unsigned integer length field in network byte order encoding the output key length in octets.