Diameter Attribute-Value Pairs for Cryptographic Key Transport
Extracted elements (16)
The existing Diameter EAP application (RFC 4072) allows at most one instance of EAP-Master-Session-Key or EAP-Key-Name AVPs per message, which is insufficient for newer EAP methods and ERP (RFC 6696) that require transport of multiple derived keys. This document introduces a Grouped Key AVP to enable multiple cryptographic keys in a single Diameter message.
The Key AVP and its sub-AVPs are defined for use in the Diameter EAP application (RFC 4072) as well as other Diameter applications, enabling broad reuse beyond the EAP context.
Applications using the Key-Lifetime value SHOULD consider the beginning of the lifetime to be the point in time when the message containing the keying material is received.
Client implementations SHOULD check to ensure that the Key-Lifetime value is reasonable; for example, the lifetime of a key should not generally be longer than the session lifetime.
If a Key AVP contains a Keying-Material AVP that is not already protected, then the Diameter messages containing that Key AVP MUST only be sent protected via mutually authenticated TLS or IPsec.
Once values have been assigned to the Key-Type AVP registry, they MUST NOT be deleted, replaced, or modified.
The Key AVP (AVP Code 581) is of type Grouped and contains the type and keying material and, optionally, an indication of the usable lifetime of the key, the name of the key, and a Security Parameter Index (SPI). It allows transport of multiple cryptographic keys in a single Diameter message.
The Key-Lifetime AVP (AVP Code 584) is of type Unsigned32 and represents the period of time (in seconds) for which the contents of the Keying-Material AVP is valid.
The Key-Name AVP (AVP Code 586) is of type OctetString and contains an opaque key identifier. Exactly how this name is generated and used depends on the key type and usage in question.
The Key-SPI AVP (AVP Code 585) is of type Unsigned32 and contains an SPI value that can be used with other parameters for identifying associated keying material.
The Key-Type AVP (AVP Code 582) is of type Enumerated and identifies the type of the key being sent. Defined values are: DSRK (0) for Domain-Specific Root Key, rRK (1) for re-authentication Root Key, and rMSK (2) for re-authentication Master Session Key.
The Keying-Material AVP (AVP Code 583) is of type OctetString. The exact usage of this keying material depends upon several factors including the type of the key and the link layer in use.
IANA assigned AVP codes for six new AVPs: Key (581), Key-Type (582), Keying-Material (583), Key-Lifetime (584), Key-SPI (585), and Key-Name (586), using the policy specified in RFC 6733 Section 11.1.1.
IANA created a new registry for values assigned to the Key-Type AVP, populated with DSRK (0), rRK (1), and rMSK (2). New values may be assigned using the 'Specification Required' policy (RFC 5226).
Transporting keys is a security-sensitive action. Some forms of keying material are already protected and can be sent safely over the open Internet, but unprotected keying material must only be sent via mutually authenticated TLS or IPsec. The security considerations of the Diameter base protocol (RFC 6733) and RFC 4072 Section 8.4 also apply.
The Key AVP is encoded with AVP Header code 581, containing a mandatory Key-Type sub-AVP and Keying-Material sub-AVP, with optional Key-Lifetime, Key-Name, and Key-SPI sub-AVPs, followed by zero or more additional AVPs.