Distribution of EAP-Based Keys for Handover and Re-Authentication
Extracted elements (21)
In explicit ERP bootstrapping, the EAP peer initiates distribution by sending an EAP-Initiate message with the bootstrapping flag set, providing cryptographic verification of peer consent via the message's integrity checksum. This contrasts with implicit bootstrapping, where the peer has no visibility into or control over key distribution.
The KDE mechanism is necessary because the EMSK must not leave the EAP server (per RFC 5295), yet root keys derived from the EMSK are required by other network servers for services such as re-authentication. The EAP server derives the keys and exports them to a co-located AAA server that distributes them to requesting servers.
The KDE specification is intentionally a protocol template that does not define message formats, data encoding, or other implementation details. It must be instantiated for a specific AAA protocol (RADIUS or Diameter) before it can be implemented, allowing reuse across different AAA deployments.
For ERP explicit bootstrapping, the local ER server includes a KDE-Request in the AAA message carrying the peer's EAP-Initiate (bootstrapping flag on), and the home AAA server responds with a KDE-Response in the AAA message carrying EAP-Finish (bootstrapping flag set). A AAA User-Name attribute serves as the PID.
For ERP implicit bootstrapping, the local ER server (acting as KRS) includes a KDE-Request in the AAA packet encapsulating the first EAP-Response message, and the home AAA server (acting as KDS) includes the KDE-Response in the AAA message carrying EAP-Success. A AAA User-Name attribute serves as the PID.
A secure key wrap algorithm MUST be used by the AAA protocol to protect the root key (RK) carried in a KDE-Response.
Any KDE attribute exchanged in a KDE-Request or KDE-Response MUST be integrity-protected and replay-protected by the underlying AAA protocol.
If a trusted AAA infrastructure does not exist, end-to-end security between KRS and KDS MUST be ensured by other means at a different layer, with the same integrity, replay, and confidentiality requirements as for AAA protocols.
Other confidential information in KDE messages, such as peer identifiers when privacy is a requirement, SHOULD be encrypted by the underlying AAA protocol.
The key lifetime of each distributed root key MUST NOT be greater than that of its parent key in the EMSK key hierarchy.
The use of hop-by-hop security associations along the AAA path SHOULD be limited to environments where each intermediary is trusted not to abuse the distributed key material.
Scenarios 2 and 3 may be combined: the DSUSR-KH sends KDE-Request' to DSR-KH, which simultaneously forwards KDE-Request to the EAP/AAA server; responses flow back along the same path as KDE-Response and KDE-Response'. This collapses two serial round-trips into one.
The key context of each distributed key is determined by the sequence of key types (KTs) in the key hierarchy. The key scope is determined by the sequence of (PID, KT, KL)-tuples in the hierarchy plus the KRS identifier. The KDF binds both context and scope into the derived key.
The key delivery architecture distinguishes a Key Delivering Server (KDS), which holds the EMSK or DSRK and derives and distributes root keys, from a Key Requesting Server (KRS), which is authorized to request root keys and uses them to derive keying material for its services. The EAP/AAA server and DSR-KH can act as KDS; USR-KH, DSR-KH, and DSUSR-KH can act as KRS.
The Key Delivery Token (KDT) is a tuple (KT, KL, RK, KN_RK, LT_RK) sent by the KDS in a KDE-Response. It carries the root key (RK) to be distributed, its type (KT), label (KL), key name (KN_RK), and lifetime (LT_RK).
The Key Distribution Exchange (KDE) is an abstract protocol template for distributing EMSK-derived root keys (USRK, DSRK, DSUSRK) from a Key Delivering Server (KDS) to a Key Requesting Server (KRS) over a AAA protocol. It consists of one round-trip: a KDE-Request carrying a Key Request Token (KRT) and a KDE-Response carrying a Key Delivery Token (KDT). The template must be instantiated for a specific AAA protocol (e.g., RADIUS or Diameter) before it can be implemented.
The Key Request Token (KRT) is a tuple (PID, KT, KL) sent by the KRS in a KDE-Request. PID identifies the EAP peer, KT specifies the type of root key requested (DSRK, USRK, or DSUSRK), and KL is the key label as defined in RFC 5295.
Three KDE scenarios exist based on key type: (1) EAP/AAA server delivers USRK to USR-KH; (2) EAP/AAA server delivers DSRK to DSR-KH; (3) DSR-KH delivers DSUSRK to DSUSR-KH within a domain. Scenarios 2 and 3 can be combined into a single round-trip exchange.
AAA protocols carrying KDE messages must provide integrity protection, replay protection, and key wrap for the root key. Confidential fields such as peer identifiers should be encrypted. These requirements apply both to the direct AAA transport and to any end-to-end security layer used when the AAA path is not fully trusted.
Hop-by-hop AAA security means each intermediary (e.g., AAA proxy) on the path between KRS and KDS can access the distributed root key. In the absence of a fully trusted AAA infrastructure, end-to-end security mechanisms must be applied to protect key material between KRS and KDS.
In implicit ERP bootstrapping, the EAP peer is unaware that its root keys are being distributed; there is no cryptographic verification of peer consent. A KRS can obtain a root key even if the peer does not support ERP, potentially wasting resources when EAP-Initiate/Re-auth-Start messages are silently dropped by the peer.