Diameter support for the EAP Re-authentication Protocol (ERP)

- - RFC 5296 defines the EAP Re-authentication - Protocol (ERP). It consists of the following steps: - - - - A root key for re-authentication is derived from - the Extended Master Session Key (EMSK) created during EAP - authentication . - This root key is transported from the EAP server to the ER server. - - - - A one-round-trip exchange between the peer and - the ER server, resulting in mutual authentication. To support the - EAP reauthentication functionality, ERP defines two new EAP codes - - EAP-Initiate and EAP-Finish. - - - This document defines how Diameter transports the ERP messages - during the re-authentication process. For this purpose, we define a new Application - Identifier for ERP, and re-use the Diameter EAP commands (DER/DEA). - - This document also discusses the distribution of the root key - during bootstrapping, in conjunction with either the initial EAP authentication - (implicit bootstrapping) or the first ERP exchange (explicit - bootstrapping). Security considerations for this key distribution are - detailed in RFC 5295. - -

- -

- - This document uses terminology defined in RFC 3748, - RFC 5295, - RFC 5296, - and RFC 4072. - - "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK - derived from an EMSK, depending on the location of the ER server in home - or foreign domain. - - We use the notation "ERP/DER" in this document to refer to a - Diameter-EAP-Request command with its Application Id set to Diameter ERP - application. Similarly, we use the "ERP/DEA", "EAP/DER", and - "EAP/DEA". - -

- - 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 . - -

- -

- - This document assumes the existence of at most one logical ER server entity in a domain. If - several physical servers are deployed for robustness, a replication - mechanism must be deployed to synchronize the ERP states - (root keysFFS: authorization attributes) between these servers. This - replication mechanism is out of the scope of this document. If multiple - ER servers are deployed in the domain, we assume that they can be used - interchangeably. - -

- -

- - The following figure shows the components involved in ERP, and their - interactions. - -

|Authenticator|<=======>| ER server | <---> | EAP | - +-------------+ +-----------+ | server | - +--------+ -(*) Diameter EAP application, explicit bootstrapping scenario only. -]]> - - The ER server is located either in the home domain (same as EAP - server) or in the visited domain (same as authenticator, when it differs - from the home domain). - - - - Can the ER server be located in a third domain (ex: broker's) according to ERP mechanism? - - - - When the peer initiates an ERP exchange, the authenticator creates a - Diameter-EAP-Request message, as described in Diameter EAP application - . The Application Id of the message is set - to that of the Diameter ERP application (code: TBD) in the - message. - The generation of the ERP/DER message is - detailed in section . - - If there is an ER server in the same domain as the authenticator - (local domain), Diameter routing MUST - - - - Should this say "SHOULD: instead of "MUST"? - - - be - configured so that this ERP/DER message reachs this server, even if the - Destination-Realm is not the local domain. - - If there is no local ER server, the message is routed according to - its Destination-Realm AVP content, extracted from the realm component of - the keyName-NAI attribute. As specified in - RFC 5296, this realm is the home domain of the peer in - case of a bootstrapping exchange (the 'B' flag is set in the ERP message) or the - domain of the bootstrapped ER server otherwise. - - - - This actually might allow the ER server to be in a third party realm. - - - - If no ER server is available in the home domain either, the ERP/DER - message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER is - generated and returned to - the authenticator. The authenticator may cache this information (with - limited duration) to avoid further attempts for ERP with this realm. It - may also fallback to full EAP authentication to authenticate the - peer. - - When an ER server receives the ERP/DER message, it searches its local - database for a root key - - - - and authorization state? - - - matching - the keyName part of the User-Name AVP. If such key is found, the ER - server processes the ERP message as described in - RFC 5296 then creates the ERP/DEA answer as described in - . The rMSK is included in this - answer. - - Finally, the authenticator extracts the rMSK from the ERP/DEA as - described in RFC 5296, and forwards the content of - the EAP-Payload AVP, the EAP-Finish/Re-Auth message, to the peer. - - If the EAP-Initiate/Re-Auth message has its 'B' flag set - (Bootstrapping exchange), the ER server should not possess the root key - in its local database - - - - This may not be true in future RFC5296bis? - - - In this case, the ER server acts as a proxy, and forwards the - message to the home EAP server after changing its Application Id to - Diameter EAP and adding an AVP to request the root key. See section - for more detail on this - process. - -

- -

- - The bootstrapping process involves the home EAP server and the ER - server, but also impacts the peer and the authenticator. In ERP, the - peer must derive the same keying material as the ER server. To achieve - this, it must learn the domain name of the ER server. How this - information is acquired is outside the scope of this specification, but - it may involves that the authenticator is configured to advertize this - domain name, especially in the case of re-authentication after a - handover. - - The bootstrapping of an ER server with a given root key happens - either during the initial EAP authentication of the peer when the EMSK - -- from which the root key is derived -- is created, during the first - re-authentication, or sometime between those events. We only consider - the first two possibilities in this specification, in the following - subsections. - -

- - Bootstrapping the ER server during the initial EAP authentication - (also known as implicit bootstrapping) offers the advantage that the - server is immediatly available for re-authentication of the peer, thus - minimizing re-authentication delay. On the other hand, it is - possible that only a small number of peers will use re-authentication - in the visited domain. Deriving and caching key material for all the - peers (for example, for the peers that do not support ERP) is a waste - of resources and SHOULD be avoided. - - To achieve implicit bootstrapping, the ER server must act as a - Diameter EAP Proxy as defined in the Diameter Base Protocol , and routing must be configured so that - Diameter messages of a full EAP authentication are routed through this - proxy. The figure bellow illustrates this mechanism. -

- Diameter EAP/DER - (EAP-Response) - -------------------------> - Diameter EAP/DER - (EAP-Response) - (ERP-RK-Request) - - <==================================================> - Multi-round Diameter EAP exchanges, unmodified - - <------------------------- - Diameter EAP/DEA - (EAP-Success) - (MSK) - (Key AVP (rRK)) - <------------------------- - Diameter EAP/DEA - (EAP-Success) - (MSK) - [ERP-Realm] -]]> - The ER server proxies the first DER of the full EAP authentication - and adds the ERP-RK-Request AVP inside, if this AVP is not already in - the message (which might happen if there are ER servers in the visited - and the home domains), then forwards the request. - - If the EAP server does not support the ERP extensions, it will simply - ignore this grouped AVP and continue as specified in RFC 4072. If the server supports the ERP extensions, - it caches the ERP-Realm value with the session data, and continues the EAP - authentication. When the authentication is complete, if it is - successful and the EAP method generated an EMSK, the server MUST - derive the rRK as - specified in RFC 5296, and include an instance of the Key - AVP - in the Diameter-EAP-Answer message. - - When the ER server proxies a Diameter-EAP-Answer message with a - Session-Id corresponding to a message to which it added an - ERP-RK-Answer, and the Result-Code is DIAMETER_SUCCESS, it MUST - examine the message, extract and remove any Key AVP - - from the - message, and save its content. If the message does not contain an - ERP-RK-Answer AVP, the ER server MAY cache this information to avoid - possible subsequent re-authentication attempts for this session. In - any case, the information stored SHOULD NOT have a lifetime greater - than the EMSK lifetime - - - - How does the ER server knows the EMSK - lifetime, if there is no ERP-RK-Answer? What is the lifetime of the - MSK for example? - - - - If the ER server is successfully bootstrapped, it MAY also add the - ERP-Realm AVP after removing the ERP-RK-Answer AVP in the EAP/DEA - message. This could be used by the authenticator to notify the peer - that ERP is bootstrapped, with the ER domain information. How this - information can be transmitted to the peer is outside the scope of - this document. - - - - Is this possible? It might be useful... - - - -

- -

- - Bootstrapping the ER server during the first re-authentication - (also known as explicit bootstrapping) offers several advantages: it - saves resources, since we generate and cache only root keys that we - actually need, and it can accomodate inter-domain handovers or ER - servers that lose their state (for example after reboot). - - - - This last point might not be true currently, since the peer would not issue - a bootstrapping exchange... But this might change also with RFC5296bis - AFAIU - - - On the other hand, the first re-authentication with the - ER server requires a one-round-trip exchange with the home EAP server, - which adds some delay to the process (but it is more efficient than a - full EAP authentication in any case). It also requires some - synchronization between the peer and the visited domain: since the ERP - message used is different - - - - and the root key used also? - - - for the - explicit bootstrapping exchange than for normal re-authentication; - explicit bootstrapping should not be used if implicit bootstrapping - was already performed. - - - - What should we do if the ER server receives an explicit - bootstrapping request but already possess the rDSRK? Can it answer - without going to the home server? That would be simpler -- planned in - rfc5296bis ? - - - - The ER server receives the ERP/DER message containing the - EAP-Initiate/Re-Auth message with the 'B' flag set. It proxies this - message, and performs the following processing in addition to standard proxy - operations: - - - Changes the Application Id in the header of the message to - Diameter EAP Application (code 5). - - - Change the content of Application-Auth-Id accordingly. - - - - Is t better to leave it unmodified? - - - - Add the ERP-RK-Request AVP, which contains the name of the - domain where the ER server is located. - - - - - - Add the Destination-Host to reach the appropriate EAP - server, the one with the EMSK. How does the ER server know this - information? - - - - - Then the server forwards the EAP/DER request, which is routed - to the home EAP server. - - If the home EAP server does not support the ERP extensions, it replies - with an error since the encapsulated EAP-Initiate/Re-auth command is - not understood. Otherwise, it processes the ERP request as described - in . - In particular, it includes the - Domain-Name TLV attribute with the content from the ERP-Realm AVP. It - creates the EAP/DEA reply message - . including an instance of the Key AVP . - - - - What about authorization AVPs? - - - - The ER server receives this EAP/DEA and proxies it as follows, in - addition to standard proxy operations: - - - Set the Application Id back to Diameter ERP (code TBD) - - - Extract and cache the content of the Key AVP. - - - - And authorization AVPs ? - - - - - The DEA is then forwarded to the authenticator, that can use - the rMSK as described in RFC 5296. - - The figure below captures this proxy behavior: - -

- Diameter ERP/DER - (EAP-Initiate) - ------------------------> - Diameter EAP/DER - (EAP-Initiate) - (ERP-RK-Request) - - <------------------------ - Diameter EAP/DEA - (EAP-Finish) - (Key AVP) - <---------------------- - Diameter ERP/DEA - (EAP-Finish) - (Key AVP) -]]> - -

- -

- - This section describes in detail a re-authentication exchange with a - (bootstrapped) ER server. The following figure summarizes the - re-authentication exchange. -

- EAP-Initiate/Re-auth - ===============================> - Diameter ERP, cmd code DER - User-Name: Keyname-NAI - EAP-Payload: EAP-Initiate/Re-auth - - <=============================== - Diameter ERP, cmd code DEA - EAP-Payload: EAP-Finish/Re-auth - Key AVP: rMSK - <---------------------- - EAP-Finish/Re-auth -]]> - - In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER - server via the authenticator. Alternatively, the authenticator 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. - - If the authenticator does not support ERP - (pure support), it discards the EAP packets with an - unknown ERP-specific code (EAP-Initiate). The peer may fallback to full - EAP authentication in this case. - - When the authenticator receives an EAP-Initiate/Re-auth message from - the peer, it process as described in with - regards to the EAP state machine. It creates a Diameter EAP Request - message following the general process of - DiameterEAP, with the following differences: - - - The Application Id in the header is set to Diameter ERP (code TBD). - - - The value in Auth-Application-Id AVP is also set to Diameter ERP - Application. - - - The keyName-NAI attribute from ERP message is used to create the - content of User-Name AVP and Destination-Realm AVP. - - - - - - What about Session-ID AVP -- in case of re-auth at the - same place, and in case of handover? - - - - - The Auth-Request-Type AVP content is set to [Editor's note: - FFS]. - - - - Do we really do authorization with Diameter ERP ? -- need - to pass the authorization attrs to the ER server in that case. Idea - FFS: we do authorization only for explicit bootstrapping - exchanges... - - - - - The EAP-Payload AVP contains the ERP message, - EAP-Initiate/Re-Auth. - - - Then this ERP/DER message is sent as described in . - - The ER server receives and processes this request as described in - . It then creates an - ERP/DEA message following the general processing described in - RFC 4072, with the following differences: - - - The Application Id in the header is set to Diameter ERP (code - TBD). - - - The value of the Auth-Application-Id AVP is also set to Diameter ERP - Application. - - - The EAP-Payload AVP contains the ERP message, - EAP-Finish/Re-auth. - - - In case of successful authentication, an instance of the Key - AVP containing the Re-authentication Master Session Key (rMSK) derived - by ERP is included. - - - - What about all the authorization attributes? If we want to - include them, they have to be present on the ER server... - - - - - When the authenticator receives this ERP/DEA answer, it processes it - as described in Diameter EAP - and RFC 5296: the content of EAP-Payload AVP content is - forwarded to the peer, and the contents of the Keying-Material AVP - is used as a shared secret for Secure Association Protocol. -

- -

- - We define a new Diameter application in this document, Diameter ERP - Application, with an Application Id value of TBD. - Diameter nodes conforming to this specification in the role of ER server - MUST advertise support by including an Auth-Application-Id AVP with a - value of Diameter ERP Application in the of the - Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands - . - - The primary use of the Diameter ERP Application Id is to ensure - proper routing of the messages, and that the nodes that advertise the - support for this application do understand the new AVPs defined in - section , although these AVP have the 'M' - flag cleared. - -

- -

- - This section discusses the AVPs used by the Diameter ERP application. - - -

- - The ERP-RK-Request AVP (AVP Code TBD) is of - type grouped AVP. This AVP is used by the ER server to indicate its - willingness to act as ER server for a particular session. - - This AVP has the M and V bits cleared. -

- { ERP-Realm } - * [ AVP ] -]]> - -

- -

- - The ERP-Realm AVP (AVP Code TBD) is of type - DiameterIdentity. It contains the name of the realm in which the ER - server is located. - - - - We may re-use Origin-Realm here instead? On the other - hand, ERP-Realm may be useful if the ER server is in a third-party - realm, if this is possible. - - - - This AVP has the M and V bits cleared. - -

- -

- - The Key AVP is of type "Grouped" and is used to carry the rMSK - and associated attributes. The usage of the Key AVP and its constituent AVPs in this application is specified in the following sub-sections. - -

- - The value of the Key-Type AVP MUST be set to 3 for rRK. - -

- - The Keying-Material AVP contains rRK sent by - the home EAP server to the ER server, in answer to a request containing - an ERP-RK-Request AVP. How this material is derived and used is - specified in RFC 5296. - -

- - This AVP contains the EMSKname which identifies the - keying material. - The derivation of this name is specified in RGC 5296. - -

- - The Key-Lifetime AVP contains the lifetime of the keying material in - seconds. It MUST NOT be greater than the remaining lifetime of the - EMSK from which the material was derived. - -

- -

- - This document does not address some known issues in Diameter ERP - mechanism. The authors would like to hear ideas about how to address - them. - - The main issue is the use of ERP for authentication after a handover - of the peer to a new authenticator (or different authenticator port). - Diameter ERP is not meant to be a mobility protocol. A number of issues - appear when we try to do handover in Diameter ERP (alone): how to manage - the Session-Id AVP; how does the ER server provide the Authorization - AVPs; how does the peer learn the ERP domain of the new authenticator; - how does the home server reachs the peer to for example terminate the - session; and so on... Therefore, the management of the session for a - mobile peer is not (yet) addressed in this document. It must be studied - how Diameter ERP can be for example used in conjunction with a mobility - application (Diameter MIP4, Diameter MIP6) to support the optimized - re-authentication in such situation. - - Another issue concerns the case where the home realm contains several - EAP servers. In multi rounds full EAP authentication, the - Destination-Host AVP provides the solution to reach the same server - across the exchanges. Only this server possess the EMSK for the session. - In case of explicit bootstrapping, the ER server must therefore be able - to reach the correct server to request the DSRK. A solution might - consist in saving the Origin-Host AVP of all successful EAP/DEA in the - ER server, which is a bit similar to the implicit bootstrapping scenario - described here -- only we save the server name instead of the root key, - and we must then be able to match the DSRK with the user name. - - Finally, this document currently lacks a description of what happens - when a Re-Auth-Request is received for a peer on the authenticator. - -

- -

- - Hannes Tschofenig wrote the initial draft for this document and - provided useful reviews. - - Vidya Narayanan reviewed a rough draft version of the document and - found some errors. - - Lakshminath Dondeti contributed to the early versions of the - document. - - Many thanks to these people! - -

- -

- - This document requires IANA registration of the following new - elements in the Authentication, - Authorization, and Accounting (AAA) Parameters registries. - -

- - This specification requires IANA to allocate a new value "Diameter - ERP" in the "Application IDs" registry - using the policy specified in Section 11.3 of RFC 3588. - -

- -

- - This specification requires IANA to allocate new values from the - "AVP Codes" registry - according to the policy specified in Section 11.1 of RFC 3588 - for the - following AVPs: - - ERP-RK-Request - ERP-Realm - These AVPs are defined in section . - -

- -

- - The security considerations from the following documents also apply here: - - RFC 3588 - RFC 4072 - RFC 5247 - RFC 5295 - - - - - - Do we really respect these security considerations with - the mechanism we describe here? - Is it safe to use ERP-RK-Request / - Answer AVPs? What is the worst case? - - - 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. - - - - What does this paragraph actually mean? - - - -