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? + + + +