Diameter Support for EAP Re-authentication Protocol

+ +

+ + RFC 4072 specifies a Diameter + application that carries EAP packets between a Diameter client + and the Diameter Server/EAP server. RFC 5296 defines the EAP Re-authentication + Protocol to allow faster re-authentication of a previously + authenticated peer. + + + + In ERP, a peer is authenticated by the network thanks to + keying material obtained during a previous EAP exchange. This + keying material is derived from the Extended Master Session + Key (EMSK) as defined in the RFC 5295 . To accomplish + the EAP reauthentication functionality, ERP defines two new + EAP codes - EAP-Initiate and EAP Finish. This document + specifies the reuse of Diameter EAP Application to carry these + new EAP messages. + + ERP is executed between the peer and a server located either in + the peer's home domain or in the local domain visited by the + peer. In the latter case, a Domain Specific Root Key (DSRK) is + derived from the EMSK, as defined in the RFC 5295 , and is provided + by the Home EAP server to the local domain server. For that + purpose, this document specifies the transport of the DSRK + using the Diameter EAP Application. + +

+ +

+ + + This document defines only additional optional AVPs for usage + with the Diameter EAP application. This document does not + define a new Diameter application and therefore a new + Application ID is not required, as described in the Diameter + Base protocol . + + + In this document, when EAP re-authentication is performed in + the domain visited by the peer, it is assumed that the local ER + server is co-located with a Diameter agent in the visited + domain present in the path of the full EAP exchange. (Editor's + Note: it is not clear at the time of writing wether this + document must require this local AAA server to be on the path.) + + +

+ +

+ + The Diameter EAP Application is used to transport ERP + messages between the NAS (authenticator) and an + authentication server (ER server). + + + In ERP, the peer sends an EAP-Initiate/Re-auth message to + the ER server via the authenticator. Alternatively, the NAS + may send an EAP-Initiate/Re-auth-Start message to the peer + to trigger the start of ERP. In this case, the peer responds with an + EAP-Initiate/Re-auth message to the NAS. + + The general guidelines for encapsulating EAP messages in + Diameter from RFC 4072 apply to + the new EAP codes defined for ERP as well. The + EAP-Initiate/Re-auth message is encapsulated in an + EAP-Payload AVP of a Diameter EAP Request (DER) message by the + NAS and sent to the Diameter server. The NAS MUST copy the + contents of the value field of the 'KeyName-NAI' TLV or + the 'peer-id' TLV (when the former is not present) of the EAP + Initiate/Re-auth message into a User-Name AVP of the + Diameter EAP-Request. + + + + + + The ER server processes the EAP-Initiate/Re-auth message in + accordance with and responds with + an EAP-Finish/Re-auth message. The Diameter server MUST + encapsulate the EAP-Finish/Re-auth message within an + EAP-Payload AVP of a Diameter EAP Answer message. In an + EAP re-authentication successful case, an + EAP-Master-Session-Key AVP is included in the Diameter EAP + Answer (DEA) message that contains the Re-authentication + Master Session Key (rMSK). The Diameter Result-Code SHOULD + be a success Result-Code. In an EAP re-authentication + failure case, the Diameter Result-Code AVP of the a + Diameter EAP Answer (DEA) message SHOULD be a failure + Result-Code and no EAP-Master-Session-Key AVP is present. + (Editor's Note: it is FFS if a SHOULD is sufficient) (2nd + Editor's Note: add a figure ?) + +

+ +

+ + A local ER server, collocated with a Diameter proxy in the + domain visited by the peer, may request a DSRK from the home EAP/ERP + server, either in the initial EAP exchange (implicit + bootstrapping) or in an ERP bootstrapping exchange + (explicit bootstrapping). This is done by including the + EAP-DSRK-Request AVP in the Diameter EAP Request (DER) message. + The EAP-DSRK-Request AVP contains the domain or server + identity required to derive the DSRK. + + + + In successful case, the DSRK is carried by the EAP-DSRK AVP + in the Diameter EAP Answer (DEA) message. Along with the + EAP-DSRK AVP, an EAP-DSRK-Name AVP MUST be used to send the + DSRK's keyname and an EAP-DSRK-Lifetime AVP MUST be used to + send the DSRK's lifetime. (Editor's Note: add a figure ?). + + +

+ +

+ + This document re-uses the EAP application commands and does not define new command + codes. + + + +

+ + +

+ + This section defines new AVPs for the ERP support within + Diameter EAP Application. + + +

+ + The EAP-DSRK Request AVP (AVP Code TBD) is of type + DiameterIdentity. This AVP fulfills two purposes: first, it + indicates that a ERP server is located in the local domain + that is willing to play the role of an ERP server for a + particular session. Second, it conveys information about + the domain name to the + Diameter/EAP/ERP server. (Editor's Note: it is FFS if + DiameterIdentity is the correct type). + +

+ +

+ + The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. This + AVP contains keying material to be used by the visited + domain (i.e. the DSRK). Exactly how this keying material is + derived is beyond the scope of this document. + +

+ +

+ + The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. + This AVP contains the EMSKname which identifies the keying + material. How this name is derived is beyond the scope + of this document and defined in . + +

+ +

+ + The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type + Unsigned64 and contains the DSRK lifetime in + seconds. (Editor's Note: it is FFS if Unsigned32 is not + sufficient). (Editor's Note: it is FFS default value) + +

+ +

+ + + +

+ + The following table lists the AVPs that may optionally be present in the DER and DEA + commands . + + +

+ + + + + When the EAP-DSRK AVP is present in the DEA then the + EAP-DSRK-Name and the EAP-DSRK-Lifetime MUST also be + present. + +

+ +

+ + The following table describes the Diameter AVPs, their AVP Code + values, types, possible flag values, and whether the AVP MAY be + encrypted. The Diameter base specifies + the AVP Flag rules for AVPs in Section 4.5. + + +

+ + + +

+ + The security considerations specified in RFC 4072 , and RFC 3588 + are applicable to this document. + + EAP channel bindings may be necessary to ensure that the + Diameter client and the server are in sync regarding the key + Requesting Entity's Identity. Specifically, the Requesting + Entity advertises its identity through the EAP lower layer, and + the user or the EAP peer communicates that identity to the EAP + server (and the EAP server communicates that identity to the + Diameter server) via the EAP method for user/peer to server + verification of the Requesting Entity's Identity. + +

+ + + +

+ + This document requires IANA registration of the following new AVPs to the AVP + registry established by RFC 3588 : + EAP-DSRK-Request + EAP-DSRK + EAP-DSRK-Name + EAP-DSRK-Lifetime + + + +

+ +

+ + Vidya Narayanan reviewed a rough draft version and found some + errors. Many thanks for her input. + +