RFC 5295
Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)
RFC 5295: Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) 🎀
Okay bestie, this one is from the Network Working Group, and it's giving "the EMSK finally gets a job" 💅 It's a Standards Track document from August 2008, written by J. Salowey (Cisco Systems), L. Dondeti, V. Narayanan (Qualcomm, Inc), and M. Nakhjiri (Motorola). It updates RFC 5247 🦋 and doesn't obsolete anything.
Status of This Memo 📜
This is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨
Abstract 🌸
So EAP (the Extensible Authentication Protocol) defined EMSK generation but kinda just reserved it for "unspecified future uses" 😭 This memo says nope, the EMSK is now for one job only: deriving root keys 🔥 Root keys are master keys that can be used for multiple purposes, and each purpose is identified by a usage definition. The doc also lays out a way to stop root keys from clashing by deriving them so they're guaranteed cryptographic separation 🧚 And finally, it defines one specific root key usage: Domain-Specific Root Keys, which are root keys made available to and used within specific key management domains 👑
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicable Usages of Keys Derived from the EMSK . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Separation and Coordinated Key Derivation . . . 6
3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 7
3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 9
3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 10
4. Domain-Specific Root Key Derivation . . . . . . . . . . . . . 11
4.1. Applicability of Multi-Domain Usages . . . . . . . . . . . 12
5. Requirements for Usage Definitions . . . . . . . . . . . . . . 13
5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 13
6. Requirements for EAP System . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Key Strength . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Cryptographic Separation of Keys . . . . . . . . . . . . . 15
7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 15
7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 16
7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 16
7.6. Entropy Consideration . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. PRF Numbers . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 191. Introduction 🦋
This doc is about keys made by authenticated key exchange mechanisms defined in the EAP framework [RFC3748] 💖 EAP defines two kinds of keying material: a Master Session Key (MSK) and an Extended Master Session Key (EMSK). The EAP spec basically assumes the MSK will be used for a single purpose on a single device, and it reserves the EMSK for future use 👀 This document defines the EMSK to be used solely for deriving root keys, using the key derivation specified here. Root keys are meant for specific purposes called usages, and a special usage class is the Domain-Specific Root Keys, which are made available to and used within specific key management domains ✨ The doc also gives guidelines for writing usage definitions for the different uses of EAP key material, and for managing the root keys 🫶 In this document, "application" and "usage" (or "usage definition") both mean a specific use case of the EAP keying material.
Different uses for keys derived from the EMSK have been proposed 🌈 Some examples are hand-off across access points in various mobile technologies, mobile IP authentication, and higher-layer application authentication 🧚 For a particular usage of EAP key material to use this specification, it has to specify a so-called usage definition 📝 This document does not define how the derived Usage-Specific Root Keys (USRK) are used. You'll find the applicable usages in the next section 👑 What it does do is define a framework for deriving USRKs for different purposes, so different usages can be developed independently of one another. The goal is that the security properties of one usage have minimal or no effect on the security properties of other usages 🔥
This document does define a special class of USRK, called a Domain-Specific Root Key (DSRK), for use in deriving keys specific to a key management domain 💅 Each DSRK is a root key used to derive Domain-Specific Usage-Specific Root Keys (DSUSRKs). The DSUSRKs are USRKs specific to a particular key management domain 🍓
To keep root keys for specific purposes separate from one another, two requirements are defined in the following sections 🎀 One is coordinated key derivation, and the other is cryptographic separation 💜
1.1. Applicable Usages of Keys Derived from the EMSK 🌸
The EMSK is typically established as part of network access authentication and authorization 🌐 Keys derived from the EMSK are expected to be used in protocols related to network access, such as handover optimizations, and the scope of these protocols is usually restricted to the endpoints of the lower layers over which EAP packets are sent 🦋
Okay, this part is important, so listen up 🙈 It is inappropriate for the security of higher-layer applications to solely rely on keys derived from network access authentication. Even when these keys are used together with another, independent security mechanism, their use needs to be carefully evaluated against the benefits of the optimization and the need to support multiple solutions 🧐 Performance optimizations may not warrant the close tie-in that may be required between the layers in order to use EAP-based keys. Those optimizations may be offset by the complexities of managing the validity and usage of key materials 😭 Keys generated from subsequent EAP authentications may also be beyond the knowledge and control of applications 💀
From an architectural point of view, applications should not make assumptions about the lower-layer technology (such as network access authentication) used on any particular hop along the path between the application endpoints 🧚
From a practical point of view, making such assumptions would complicate using those applications over lower layers that do not use EAP, and it would make it harder for applications and network access technologies to evolve independently of each other 🫶
Parties using keys derived from the EMSK also need trust relationships with the EAP endpoints, plus mechanisms for securely communicating the keys ✨
For most applications, it is not appropriate to assume that all current and future access networks are trusted to secure the application function. Instead, applications should implement the required security mechanisms in an access-independent manner 🔥
Implementation considerations may also complicate communicating keys to an application from the lower layer. For instance, in many configurations, application protocol endpoints may be different from the EAP endpoints 🍓
Given all this, it is NOT RECOMMENDED to use keys derived from the EMSK as an exclusive security mechanism, when their usage is not inherently, and by permanent nature, tied to the lower layer where network access authentication was performed. 🚫💅
Keys derived from EAP are pair-wise by nature, so they're not directly suitable for multicast or other group usages, like the ones involved in some routing protocols 🌈 It is possible to use keys derived from EAP in protocols that distribute group keys to group participants 🦋
The definition of these group key distribution protocols is beyond the scope of this document and would require additional specification 📝
1.2. Terminology 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀
The following terms are taken from [RFC3748]: EAP Server, peer, authenticator, Master Session Key (MSK), Extended Master Session Key (EMSK), and Cryptographic Separation 🧚
Usage Definition 🌸 An application of cryptographic key material to provide one or more security functions, such as authentication, authorization, encryption, or integrity protection, for related applications or services. This document provides guidelines and recommendations for what should be included in usage definitions. It does not place any constraints on the types of use cases or services that create usage definitions 📝
Usage-Specific Root Key (USRK) 🦋 Keying material derived from the EMSK for a particular usage definition. It is used to derive child keys in a way defined by its usage definition 🔑
Key Management Domain 👑 A key management domain is specified by the scope of a given root key. The scope is the collection of systems authorized to access key material derived from that key. Systems within a key management domain may be authorized to (1) derive key materials, (2) use key materials, or (3) distribute key materials to other systems in the same domain. A derived key's scope is constrained to a subset of the scope of the key it's derived from. In this document, "domain" refers to a key management domain unless otherwise qualified 🌐
Domain Specific Root Key (DSRK) 💜 Keying material derived from the EMSK that is restricted to use in a specific key management domain. It is used to derive child keys for a particular usage definition. The child keys derived from a DSRK are referred to as Domain-Specific Usage-Specific Root Keys (DSUSRKs). A DSUSRK is similar to the USRK, except that its scope is restricted to the same domain as the parent DSRK it's derived from 🍓
2. Cryptographic Separation and Coordinated Key Derivation 💅✨
okay bestie, the EMSK gets used to derive keys for multiple use cases 🦋, so the derived keys are required to be cryptographically separate 🔐. Here's the vibe: if you've got one derived key, it has to be computationally infeasible to get any of the other derived keys 💀. Deriving the EMSK from any combo of derived keys also has to be computationally infeasible, no cap. In practice, getting the EMSK from a derived key, or getting one child key from another, needs about as much computation as reversing a cryptographic hash function 🙈.
Cryptographic separation for keys derived from the same key can be done lots of ways. Two obvious methods are:
- Use a Pseudo-Random Function (PRF) on the EMSK and generate a key stream. Keys of various lengths may be provided as required from the key stream for various uses.
- Derive keys from EMSK by providing different inputs to the PRF.
However, it's desirable that deriving one child key from the EMSK is independent of deriving another child key 🧚. Independent derivation lets child keys get derived in any order, totally independent of the other keys. So it's desirable to use option 2 from above. With the second option, the additional input to the PRF has to be different for each child key derivation 🎀. That additional input has to be coordinated properly, so we get cryptographic separation and nobody reuses key material between usages.
If cryptographic separation isn't maintained, then the security of one usage depends on the security of all the other usages that use keys derived from the EMSK 😭. If a system doesn't have this property, a usage's security depends on every other usage deriving keys from the same EMSK, which is just not it. To stop security problems in one usage from messing with another usage, the following cryptographic separation is required:
- 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.
- 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.
- 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.
This document gives guidelines for a key derivation mechanism that can be used with existing and new EAP methods to provide cryptographic separation between usages of EMSK 🌸. This means new usages can be developed without cumbersome coordination between different usage definitions. Iconic 👑.
3. EMSK Key Root Derivation Framework 🌈
The EMSK key derivation framework gives a coordinated way to generate multiple root keys from an EMSK ✨. Further keys can then be derived from the root key for various purposes, including encryption, integrity protection, entity authentication by way of proof of possession, and subsequent key derivation 🔥. A root key is derived from the EMSK for a specific set of uses, set forth in a usage definition described in Section 5.
The basic EMSK root key hierarchy looks like this:
EMSK
/ \
USRK1 USRK2This document defines how to derive Usage-Specific Root Keys (USRKs) from the EMSK, and it also defines a specific USRK called a Domain-Specific Root Key (DSRK) 💖. DSRKs are root keys restricted to use in a particular key management domain. From the DSRK, Usage-Specific Root Keys for a particular application may be derived (DSUSRKs). The DSUSRKs are equivalent to USRKs that are restricted to use in a particular domain. The details of lower levels of the key hierarchy are outside the scope of this document 🫶. The key hierarchy looks like this:
EMSK
/ \
USRK DSRK
/ \
DSUSRK1 DSUSRK23.1. USRK Derivation 🦋
The EMSK Root Key Derivation Function (KDF) derives a USRK from the EMSK, a key label, optional data, and an output length 🧁. The KDF is expected to give the same output for the same input. The basic key derivation function looks like this:
USRK = KDF(EMSK, key label | "\0" | optional data | length)
where:
| denotes concatenation
"\0" is a NULL octet (0x00 in hex)
length is a 2-octet unsigned integer in network byte orderThe key labels are printable ASCII strings, unique for each usage definition, and they're a maximum of 255 octets 🎀. In general, they look like label-string@specorg, where specorg is the organization that controls the specification of the usage definition of the Root Key. The key label is meant to give global uniqueness. The rules for allocating these labels are in Section 8.
The NULL octet after the key label is there to avoid collisions if one key label is a prefix of another label (for example, foobar and foobarExtendedV2) 🙈. This is treated as a simpler solution than requiring a key label assignment policy that stops prefixes from happening at all.
For the optional data, the KDF MUST be capable of processing at least 2048 opaque octets. The optional data must be constant during the execution of the KDF. Usage definitions MAY use the EAP Session-ID [RFC5247] when specifying the optional data parameter that goes into the KDF function 💜. When they do, the big win is that the data going into the key derivation is unique to the session that generated the keys, which is so cute.
The KDF must be able to process input keys of up to 256 bytes. It may do this by providing a mechanism for "hashing" long keys down to a suitable size that the underlying derivation algorithm can consume 🍓.
The length is a 2-octet unsigned integer, in network byte order, of the output key length in octets. An implementation of the KDF MUST be capable of producing at least 2048 octets of output. However, it is RECOMMENDED that Root Keys be at least 64 octets long 🌈.
A usage definition that requires derivation of a Root Key MUST specify all the inputs (other than the EMSK) to the key derivation function 📝.
USRKs MUST be at least 64 octets in length 💅.
3.1.1. On the KDFs 🧚♀️
This specification allows for the use of different KDFs. However, to have a coordinated key derivation function, the same KDF function MUST be used for all key derivations for a given EMSK. If no KDF is specified, then the default KDF specified in Section 3.1.2 MUST be used. A system may provide the capability to negotiate additional KDFs. KDFs are assigned numbers through IANA, following the policy set in Section 8. The rules for negotiating a KDF are:
- If no other KDF is specified, the KDF specified in this document MUST be used. This is the "default" KDF.
- The initial authenticated key exchange MAY specify a favored KDF. For example, an EAP method may define a preferred KDF to use in its specification. If the initial authenticated key exchange specifies a KDF, then this MUST override the default KDF.
Note that usage definitions MUST NOT concern themselves with the details of the KDF construction or the KDF selection. They only need to worry about the inputs specified in Section 3 ✨.
3.1.2. Default KDF 🫧
The default KDF for deriving root keys from an EMSK is taken from the PRF+ key expansion specified in [RFC4306], based on HMAC-SHA-256 [SHA256]. The PRF+ construction was chosen because of its simplicity and efficiency compared to other mechanisms, such as those used in [RFC4346]. The motivation for the design of PRF+ is described in [SIGMA]. The definition of PRF+ from [RFC4306] looks like this:
PRF+ (K,S) = T1 | T2 | T3 | T4 | ...
where:
T1 = PRF (K, S | 0x01)
T2 = PRF (K, T1 | S | 0x02)
T3 = PRF (K, T2 | S | 0x03)
T4 = PRF (K, T3 | S | 0x04)This continues as needed to compute the required length of key material. The key, K, is the EMSK, and S is the concatenation of the key label, the NULL octet, optional data, and length, as defined in Section 3.1. For this specification, the PRF is taken as HMAC-SHA-256 [SHA256]. Since PRF+ is only defined for 255 iterations, it may produce up to 8160 octets of key material 🎉.
3.2. EMSK and USRK Name Derivation 🏷️
The EAP keying framework [RFC5247] specifies that the EMSK MUST be named using the EAP Session-ID and a binary or textual indication. Following that requirement, the EMSK name SHALL be derived like this:
EMSKname = KDF ( EAP Session-ID, "EMSK" | "\0" | length )
where:
| denotes concatenation
"EMSK" consists of the 4 ASCII values for the letters
"\0" = is a NULL octet (0x00 in hex)
length is the 2-octet unsigned integer 8 in network byte orderIt is RECOMMENDED that all keys derived from the EMSK are referred to by the EMSKname and the context of the descendant key usage. This is the default behavior. Any exceptions SHALL be signaled by individual usages 🦄.
USRKs MAY be named explicitly, with a name derivation specified as follows:
USRKName =
KDF(EAP Session-ID, key label|"\0"|optional data|length)
where:
key label and optional data MUST be the same as those used
in the corresponding USRK derivation
length is the 2-octet unsigned integer 8 in network byte orderUSRKName derivation and usage apply when there's ambiguity in referencing the keys using the EMSKname and the associated context of the USRK usage. The usage SHALL signal such an exception in key naming, so both parties know which key name is being used 🫶.
4. Domain-Specific Root Key Derivation ✨
okay bestie, so a Domain-Specific Root Key (DSRK) is a special kind of USRK that gets derived from the EMSK for a specific set of usages inside one particular key management domain 🏰. Usages then derive their service-specific keys from that DSRK. The DSRK can be handed off to a key management domain so keys can be derived right there in that domain 🫶. DSRK-based usages follow a key hierarchy that looks like this:
EMSK
/ \
/ \
/ \
/ \
DSRK1 DSRK2
/ \ / \
/ \ / \
DSUSRK11 DSUSRK12 DSUSRK21 DSUSRK22the DSRK is a USRK with a key label of "dsrk@ietf.org", and it has optional data that carries a domain label 🎀. The optional data MUST contain an ASCII string that names the key management domain the root key is being derived for. The DSRK MUST be at least 64 octets long 💅.
Domain-Specific Usage-Specific Root Keys (DSUSRKs) get derived from the DSRK 🦋. The KDF is expected to give the same output for the same input, which is the whole point of a KDF ✨. The basic key derivation function looks like this:
DSUSRK = KDF(DSRK, key label | "\0" | optional data | length)the key labels are printable ASCII strings, unique for each usage definition within a DSRK usage, and they can be up to 255 octets 🌸. Generally they look like label-string@specorg, where specorg is the organization that controls the specification of the DSRK usage definition. The key label exists to give global uniqueness. The rules for allocating these labels are in Section 8. For the optional data, the KDF MUST be capable of processing at least 2048 opaque octets 🧚. The optional data must be constant while the KDF is running. The length is a 2-octet unsigned integer in network byte order, and it holds the output key length in octets. An implementation of the KDF MUST be capable of producing at least 2048 octets of output. That said, it is RECOMMENDED that DSUSRKs be at least 64 octets long 🔥.
Usages that use the DSRK have to define how the peer learns which domain label to use in a given derivation 👑. A multi-domain usage has to define how both DSRKs and specific DSUSRKs get transported to different key management domains. Also, usages may define other ways to constrain specific keys to particular key management domains 🌈.
To make it easy to refer to keys derived from DSRKs by name, EMSKname SHOULD be sent along with the DSRK 🍓. The exception is when a DSRKname is the one that's expected to be used. In that case the usage SHALL signal the exception in key naming, so both parties know which key name is in play 🙈.
DSUSRKs MAY be named explicitly, using this name derivation:
DSUSRKName =
KDF(EMSKName,key label | "\0" | optional data | length)where length is the 2-octet unsigned integer 8 in network byte order ✨.
4.1. Applicability of Multi-Domain Usages
the DSUSRKs generated by a domain can be used to authorize entities in that domain to perform specific functions 🦋. When only one specific domain should be authorized to perform a function, the usage SHOULD NOT be defined as multi-domain 💅.
In some cases, only certain domains are authorized for a particular multi-domain usage. In that situation, domains without full authorization should not receive the DSRK, and they should only receive DSUSRKs for the usages they're authorized for 🫶. If a peer can figure out which domains are authorized for a particular usage without relying on restricting access to the DSRK to specific domains, then this recommendation may be relaxed ✨.
5. Requirements for Usage Definitions
so, for a usage definition to meet the guidelines for USRK usage, it must meet the following recommendations 📋:
- The usage must define if it is a domain-enabled usage.
- The usage definition MUST NOT use the EMSK in any other way except to derive Root Keys using the key derivation specified in Section 3 of this document. They MUST NOT use the EMSK directly 🚫.
- The usage definition SHOULD NOT require caching of the EMSK. It is RECOMMENDED that the Root Key derived specifically for the usage definition (rather than the EMSK) should be used to derive child keys for specific cryptographic operations 🔑.
- Usage definitions MUST define distinct key labels and optional data used in the key derivation described in Section 3. Usage definitions are encouraged to use the key name described in Section 3.2 and include additional data in the optional data to provide additional entropy 🌸.
- Usage definitions MUST define the length of their Root Keys. It is RECOMMENDED that the Root Keys be at least as long as the EMSK (at least 64 octets) 💖.
- Usage definitions MUST define how they use their Root Keys. This includes aspects of key management covered in the next section on Root Key management guidelines 🧚.
5.1. Root Key Management Guidelines
this section makes recommendations for different parts of Root Key management, like lifetime, child key derivation, caching, and transport 🎀.
It is RECOMMENDED that the Root Key is only used for deriving child keys. A usage definition must specify how and when child keys get derived. It is RECOMMENDED that usages following similar considerations for key derivation are as outlined in this document for the Root Key derivation, with respect to cryptographic separation and key reuse. On top of that, usages should take into consideration how many keys will be derived from the Root Key, and make sure enough entropy is introduced in the derivation to support that. It is desirable that the entropy is provided by the two parties that derive the child key 🌈.
Root Keys' lifetimes should not be more than that of the EMSK. So when the EMSK expires, the Root Keys derived from it should be removed from use ⏳. If a new EMSK is derived from a subsequent EAP transaction, then a usage implementation should begin using the new Root Keys derived from the new EMSK as soon as possible. Whether or not child keys tied to a Root Key get replaced depends on the requirements of the usage definition. It's conceivable that some usage definitions force the child key to be replaced, while others let child keys keep being used based on the policy of the entities that use them 🦋.
Recall that the EMSK never leaves the EAP peer and server 🏠. That also holds true for some Root Keys. However, some Root Keys may be provided to other entities for child key derivation and delivery. Each usage definition specification will specify delivery caching and/or delivery procedures. Note that the whole point of the key derivation in Section 3 is to make sure Root Keys are cryptographically separate from each other and from the EMSK. In other words, given a Root Key, it is computationally infeasible to derive the EMSK, any other Root Keys, or child keys associated with other Root Keys 🔐. Besides the Root Key, several other parameters may need to be sent too.
Root Key names may be derived using the EAP Session-ID, so the key name may need to be sent along with the key 🏷️. When Root Keys get delivered to another entity, the EMSKname and the lifetime associated with the specific Root Keys MUST also be transported to that entity 🚚. Recommendations for transporting keys are discussed in the Security Considerations (Section 7.4).
Usage definitions may also define how keys are bound to particular entities. This can be done by including usage parameters and identities in the child key derivation. Some of this data is described as "channel bindings" in [RFC3748] 💜.
6. Requirements for EAP System
a system that wants to use EAP root keys derived from the EMSK has to think through a few things first. Here's the list 📝:
- The EMSK MUST NOT be used for any other purpose than the key derivation described in this document.
- The EMSK MUST be secret and not known to someone observing the authentication mechanism protocol exchange 🤫.
- The EMSK MUST be maintained within a protected location inside the entity where it is generated. Only root keys derived according to this specification may be exported from this boundary 🏰.
- The EMSK MUST be unique for each EAP session
- The EAP method MUST provide an identifier for the EAP transaction that generated the key.
- The system MUST define which usage definitions are used and how they are invoked.
- The system may define ways to select an alternate PRF for key derivation as defined in Section 3.1.
The system MAY use the MSK transmitted to the Network Access Server (NAS) in any way it chooses, in accordance with [RFC3748], [RFC5247], and other relevant specifications. This is required for backward compatibility 🕰️. New usage definitions following this specification MUST NOT use the MSK. If more than one usage uses the MSK, then cryptographic separation is not achieved. Implementations MUST prevent such combinations 🚨.
7. Security Considerations ⚠️
7.1. Key Strength
okay this one's serious 😭. The effective key strength of the derived keys will never be greater than the strength of the EMSK (or of a master key internal to an EAP mechanism) 💀.
7.2. Cryptographic Separation of Keys
the whole intent of the KDF is to derive keys that are cryptographically separate. That means if one of the Usage-Specific Root Keys (USRKs) gets compromised, it should not compromise the security of other USRKs or the EMSK 🛡️. It is believed that the chosen KDF provides the desired separation ✨.
7.3. Implementation
an implementation of an EAP framework should keep the EMSK internally, as close to where it is derived as possible, and only provide an interface for obtaining Root Keys. It may also choose to restrict which callers have access to which keys 🔒. A usage definition MUST NOT assume that any entity outside the EAP server or EAP peer has access to the EMSK. In particular, it MUST NOT assume that a lower layer has access to the EMSK 🙅♀️.
7.4. Key Distribution
sometimes it'll be necessary or convenient to distribute USRKs from where they were generated 📦. Since these are secret keys, they MUST be transported with their integrity and confidentiality maintained. They MUST be transmitted between authenticated and authorized parties 🔐. It's also important that the context of the key usage gets transmitted along with the key. That includes information to identify the key and constraints on its usage, such as lifetime 🏷️.
This document does not define a mechanism for key transport. It's up to usage definitions and the systems that use them to define how keys are distributed 🚚. Usage definition designers may enforce constraints on key usage by various parties by deriving a key hierarchy and by providing entities only with the keys in the hierarchy that they need 🌸.
7.5. Key Lifetime ⏳
okay so how long a key lives depends on how it was generated AND how it gets used 💅. The Root Key is the usage definition's responsibility, so the usage definition is the one that decides how long it stays valid 🎀. If the authenticated key exchange gives you key lifetime or key strength info, you SHOULD use it to set the lifetime 🫶. It's also recommended to coordinate key lifetimes across the whole system if you can ✨. Heads up: if you make a key lifetime shorter than a system lifetime, keys can go invalid with no nice way to refresh them 😭. And if you make it longer, the key can get used past its recommended lifetime, which lowers security 💀.
7.6. Entropy Consideration 🎲
Only a few root keys are expected to come out of the EMSK 🌸. Here's the tea: the EMSK-to-Root-Key step doesn't need any extra randomness beyond the root key labels 🤷. So if you're gonna pump out lots of keys from one Root Key, the Root-Key-to-child-key step is where you bring in fresh random numbers for each key 🎰. It's important, bestie 💜.
8. IANA Considerations 📋
When this doc uses the keywords "Private Use", "Specification Required", and "IETF Consensus" to describe namespace allocation, they mean what [RFC5226] says they mean 📚.
8.1. Key Labels 🏷️
This spec opens up a brand-new namespace for "USRK Key Labels" 🆕.
Key labels MUST be printable US-ASCII strings. They MUST NOT contain the at-sign @ except as noted below, the comma ,, whitespace, control characters (ASCII codes 32 or less), or the ASCII code 127 (DEL) 🙅. Labels are case-sensitive, and they MUST NOT be longer than 64 characters 📏.
Labels can be assigned based on Specification Required policy [RFC5226]. In addition, the labels experimental1 and experimental2 are reserved for experimental use. The following considerations apply to their use:
Production networks don't necessarily support experimental code points, so check how widely they're supported before you deploy an experiment across bigger domains like the public Internet 🧪. Playing with experimental code points could disrupt the stable operation of EAP devices, so keep that in mind when you plan an experiment 😬.
Network admins should make sure each code point is used consistently so experiments don't step on each other 🤝. Pay extra attention to security vulnerabilities and to each domain's freedom to run its own experiments 👀. Cross-domain usage is NOT RECOMMENDED 🚫.
Same deal with private1 and private2, which are reserved for Private Use inside an organization 🔒. Again, cross-domain usage of these labels is NOT RECOMMENDED.
Labels that start with some string, then an @, then a valid, fully qualified Internet domain name [RFC1034] 🌐, can be requested by whoever controls that domain name 👑. These get allocated under Expert Review with Specification Required. On top of the Specification Required review (see Section 4.1 of [RFC5226]), the expert has to check that the proposed usage conforms to this spec, including whether it fits the applicability statement in Section 1.1 🧐. It is RECOMMENDED that the specification include the following info:
- A description of the usage 📝
- The key label to be used 🏷️
- Length of the Root Key 📏
- If optional data is used, what it is and how it is maintained
- How child keys will be derived from the Root Key and how they will be used
- How lifetime of the Root Key and its child keys will be managed
- Where the Root Keys or child keys will be used and how they are communicated if necessary
The following labels are reserved by this document: EMSK and dsrk@ietf.org 🔐.
8.2. PRF Numbers 🔢
This spec introduces a new number space for "EMSK PRF numbers" ✨. The numbers are in the range 0 to 255. Numbers from 0 to 220 are assigned through the policy IETF Consensus, and numbers in the range 221 to 255 are left for Private Use. The initial registry contains the following values:
0 RESERVED
1 HMAC-SHA-256 PRF+ (Default)9. Acknowledgements 💌
This doc builds on earlier teamwork with Pasi Eronen 🤝. It reflects conversations with Bernard Aboba, Jari Arkko, Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba, and members of the EAP and HOKEY working groups 🫶.
Huge thanks to Dan Harkins for the idea of using a single root key name to refer to all keys 👑.
10. References 📚
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[SHA256] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, With Change Notice 1 dated February 2004, August 2002.
10.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", LNCS 2729, Springer, 2003, <http://www.informatik.uni-trier.de/~ley/db/conf/crypto/crypto2003.html>.
Authors' Addresses 🖋️
Joseph Salowey
Cisco Systems
EMail: jsalowey@cisco.com
Lakshminath Dondeti
Qualcomm, Inc
EMail: ldondeti@qualcomm.com
Vidya Narayanan
Qualcomm, Inc
EMail: vidyan@qualcomm.com
Madjid Nakhjiri
Motorola
EMail: madjid.nakhjiri@motorola.comFull Copyright Statement ©
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧾
The IETF doesn't take a side on whether any Intellectual Property Rights or other rights claimed to pertain to the implementation or use of the technology in this document are valid, how far they reach, or whether any license under them might be available ⚖️. It also doesn't claim to have made any independent effort to identify such rights 🔍. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📖.
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses to be made available, and the results of attempts to get a general license or permission for implementers or users of this spec can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️.
The IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard 💌. Send that info to the IETF at ietf-ipr@ietf.org 🦋.
📦 where this page comes from
- ietf: rfc5295 2008-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms