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

# Date 1287994029 -32400 # Node ID 6ac9daa8c7752ae2f97826846bbc45505fd76882 # Parent b2ed5f2fcd30e720cc05ed723af673fb73078526 Version -05 submitted, prepared for next one. diff -r b2ed5f2fcd30 -r 6ac9daa8c775 draft-ietf-dime-erp-05.xml --- a/draft-ietf-dime-erp-05.xml Fri Oct 22 15:55:24 2010 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,723 +0,0 @@ - - - - - - - - - -]> - - - - - - - - - - - - - - - - - - Diameter Support for the EAP - Re-authentication Protocol (ERP) - - - Orange Labs - -

- - 38-40 rue du general Leclerc - - Issy-Les-Moulineaux - - 92794 - - France - - - julien.bournelle@orange-ftgroup.com -

- - - - Orange Labs - -

- - 38-40 rue du general Leclerc - - Issy-Les-Moulineaux - - 92794 - - France - - - lionel.morand@orange-ftgroup.com -

- - - - NICT - -

- - 4-2-1 Nukui-Kitamachi - - Tokyo - - 184-8795 - - Koganei, Japan - - - sdecugis@nict.go.jp -

- - - - Huawei Technologies Co., - Ltd - -

- - Site B, Floor 12F, Huihong Mansion, No.91 Baixia - Rd. - - Nanjing - - 210001 - - China - - - sunseawq@huawei.com -

- - - - Network Zen - -

- - 1463 East Republican Street - - Seattle - - Washington - - 98112 - - USA - - - +1 206 931 0768 - - gwz@net-zen.net -

- - - - - Operations & Management - - Internet-Draft - - EAP - - Diameter - - Re-authentication - - AAA - - inter-authenticator roaming - - - The EAP Re-authentication Protocol (ERP) defines extensions to the - Extensible Authentication Protocol (EAP) to support efficient - re-authentication between the peer and an EAP Re-authentication (ER) - server through a compatible authenticator. This document specifies - Diameter support for ERP. It defines a new Diameter ERP application to - transport ERP messages between an ER authenticator and the ER server, - and a set of new AVPs that can be used to transport the cryptographic - material needed by the re-authentication server. - - - - -

- 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" and "ERP/DEA" in this - document to refer to Diameter-EAP-Request and Diameter-EAP-Answer - commands with the Application Id set to "Diameter ERP Application" ; the same commands are denoted "EAP/DER" and - "EAP/DEA" when the Application Id in the message is set to "Diameter EAP - Application" . - -

- 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 keys) 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). When the peer - initiates an ERP exchange, the authenticator creates a - Diameter-EAP-Request message . 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 . If there is an ER server in the same domain as the - authenticator (local domain), Diameter routing 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. 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 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. 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 the ERP-RK-Request AVP to - request the root key. See 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 sub-sections. - -

- 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 acts as a Diameter EAP Proxy, - and Diameter routing must be configured so that Diameter EAP - application messages 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 several ER - servers on the path), then forwards the request. If the EAP server does not support the ERP - extensions, it simply ignores the ERP-RK-Request AVP and continues as - specified in RFC 4072. If the server - supports the ERP extensions, it saves the value of the ERP-Realm AVP - found inside the ERP-RK-Request AVP, and continues with the EAP - authentication. When the authentication completes, if it is successful - and the EAP method has generated an EMSK, the server MUST derive the - rRK as specified in RFC 5296, using the - saved domain name. It then includes the rRK inside a Key AVP with the Key-Type AVP set to rRK, before sending - the DEA as usual. 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-Request AVP, and the Result-Code - is DIAMETER_SUCCESS, it MUST examine the message and save and remove - any Key AVP with Key-Type AVP set to rRK. - If the message does not contain such Key AVP, the ER server may cache - the information that ERP is not possible for this session to avoid - possible subsequent attempts. In any case, the information stored in - ER server concerning a session should not have a lifetime greater than - the EMSK for this session. If the ER server - is successfully bootstrapped, it should also add the ERP-Realm AVP - after removing the Key AVP with Key-Type of rRK in the EAP/DEA - message. This ERP-Realm information can be used by the authenticator - to notify the peer that ER server is bootstrapped, and for which - domain. How this information can be transmitted to the peer is outside - the scope of this document. This information needs to be sent to the - peer if both implicit and explicit bootstrapping mechanisms are - possible, because the ERP message and the root key used for protecting - this message are different in bootstrapping exchanges and - non-bootstrapping exchanges. -

- -

- Bootstrapping the ER server during the first re-authentication - (also known as explicit bootstrapping) is less resource-consuming, - since root keys are generated and cached only when needed. On the - other hand, in that case first re-authentication requires a - one-round-trip exchange with the home EAP server, which is less - efficient than the implicit bootstrapping scenario. 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 it better - to leave it unmodified, so that the server can easily - differenciate between ERP and standard EAP message ? - - - Add the ERP-RK-Request AVP, which contains the name of the - domain where the ER server is located. - - - Add the - Destination-Host AVP to reach the appropriate Diameter EAP - server in case there is more than one in destination domain, - the one with the EMSK. How does the ER server know this - information? Or can we require that all Diameter EAP servers - can be used interchangeably for this purpose? - - Then the proxied EAP/DER request is sent and routed to the - home Diameter 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 with Key-Type AVP - set to rRK. 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 application Id - (code TBD) - - Extract and cache the content of the Key AVP with Key-Type set - to rRK, as described in implicit scenario. - The ERP/DEA message 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 (rRK)) - (Key AVP (rMSK)) - <---------------------- - Diameter ERP/DEA - (EAP-Finish) - (Key AVP (rMSK)) -]]> - -

- -

- This section describes in detail a re-authentication exchange with an - ER server that was previously bootstrapped. 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 -]]> - 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 - mechanism. In this case, the peer responds with an EAP-Initiate/Re-auth - message. If the authenticator does not support - ERP (pure Diameter EAP support), it - discards the EAP packets with an unknown ERP-specific code - (EAP-Initiate). The peer should fallback to full EAP authentication in - this case. When the authenticator receives an - EAP-Initiate/Re-auth message from the peer, it processes as described in - with regards to the EAP state machine. It - creates a Diameter EAP Request message following the general process of - Diameter EAP, 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 ? - - - The Auth-Request-Type AVP content is set to [Editor's note: FFS - -- cf. open issues]. - - The EAP-Payload AVP contains the EAP-Initiate/Re-Auth - message. - 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 EAP-Finish/Re-auth message. - - In case of successful authentication, an instance of the Key AVP - containing the Re-authentication Master Session Key (rMSK) derived - by ERP is included. - 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 , 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. - This AVP has the M and V bits cleared. -

- -

- The Key AVP is - of type "Grouped" and is used to carry the rRK or 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 2 for rRK or 3 for - rMSK. -

- -

- 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, or the rMSK sent by ER server to authenticator. - 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 application. A number of issues appear when we try to do - handover while using Diameter ERP: - how to manage the Session-Id AVP -- is it a new session each - time, or do we try to reuse the same Diameter session?; - - how does the ER authenticator acquire the Authorization AVPs? Is - it cached in the Diameter ER server (received during bootstrapping) - or do we use first Authenticate-Only with ER server, then - Authorize-Only with home domain (and in that case how does the ER - authenticator learn what the home domain is?) - - how does the peer learn the ERP domain of the new authenticator - -- this is being addressed in HOKEY architecture draft; - - how does the home server reachs the peer to for example terminate - the session if there is no notification sent to the home domain; - 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. In roaming environments, it - might be useful that a broker provides ERP services. The security - implications of storing the DSRK generated for the visited domain into - the broker's server should be studied. 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 . -

- -

- 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 & Key AVPs? What is the worst - case? For example if a domain tricks the peer into beliving it is - located in a different domain? - 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? - -

- - - - - &RFC2119; - - &RFC3588; - - &RFC4072; - - &RFC5295; - - &RFC5296; - - &I-D.ietf-dime-local-keytran; - - &RFC3748; - - - - &RFC5247; - - - diff -r b2ed5f2fcd30 -r 6ac9daa8c775 draft-ietf-dime-erp-06.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/draft-ietf-dime-erp-06.xml Mon Oct 25 17:07:09 2010 +0900 @@ -0,0 +1,723 @@ + + + + + + + + + +]> + + + + + + + + + + + + + + + + + + Diameter Support for the EAP + Re-authentication Protocol (ERP) + + + Orange Labs + +

+ + 38-40 rue du general Leclerc + + Issy-Les-Moulineaux + + 92794 + + France + + + julien.bournelle@orange-ftgroup.com +

+ + + + Orange Labs + +

+ + 38-40 rue du general Leclerc + + Issy-Les-Moulineaux + + 92794 + + France + + + lionel.morand@orange-ftgroup.com +

+ + + + NICT + +

+ + 4-2-1 Nukui-Kitamachi + + Tokyo + + 184-8795 + + Koganei, Japan + + + sdecugis@nict.go.jp +

+ + + + Huawei Technologies Co., + Ltd + +

+ + Site B, Floor 12F, Huihong Mansion, No.91 Baixia + Rd. + + Nanjing + + 210001 + + China + + + sunseawq@huawei.com +

+ + + + Network Zen + +

+ + 1463 East Republican Street + + Seattle + + Washington + + 98112 + + USA + + + +1 206 931 0768 + + gwz@net-zen.net +

+ + + + + Operations & Management + + Internet-Draft + + EAP + + Diameter + + Re-authentication + + AAA + + inter-authenticator roaming + + + The EAP Re-authentication Protocol (ERP) defines extensions to the + Extensible Authentication Protocol (EAP) to support efficient + re-authentication between the peer and an EAP Re-authentication (ER) + server through a compatible authenticator. This document specifies + Diameter support for ERP. It defines a new Diameter ERP application to + transport ERP messages between an ER authenticator and the ER server, + and a set of new AVPs that can be used to transport the cryptographic + material needed by the re-authentication server. + + + + +

+ 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" and "ERP/DEA" in this + document to refer to Diameter-EAP-Request and Diameter-EAP-Answer + commands with the Application Id set to "Diameter ERP Application" ; the same commands are denoted "EAP/DER" and + "EAP/DEA" when the Application Id in the message is set to "Diameter EAP + Application" . + +

+ 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 keys) 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). When the peer + initiates an ERP exchange, the authenticator creates a + Diameter-EAP-Request message . 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 . If there is an ER server in the same domain as the + authenticator (local domain), Diameter routing 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. 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 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. 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 the ERP-RK-Request AVP to + request the root key. See 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 sub-sections. + +

+ 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 acts as a Diameter EAP Proxy, + and Diameter routing must be configured so that Diameter EAP + application messages 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 several ER + servers on the path), then forwards the request. If the EAP server does not support the ERP + extensions, it simply ignores the ERP-RK-Request AVP and continues as + specified in RFC 4072. If the server + supports the ERP extensions, it saves the value of the ERP-Realm AVP + found inside the ERP-RK-Request AVP, and continues with the EAP + authentication. When the authentication completes, if it is successful + and the EAP method has generated an EMSK, the server MUST derive the + rRK as specified in RFC 5296, using the + saved domain name. It then includes the rRK inside a Key AVP with the Key-Type AVP set to rRK, before sending + the DEA as usual. 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-Request AVP, and the Result-Code + is DIAMETER_SUCCESS, it MUST examine the message and save and remove + any Key AVP with Key-Type AVP set to rRK. + If the message does not contain such Key AVP, the ER server may cache + the information that ERP is not possible for this session to avoid + possible subsequent attempts. In any case, the information stored in + ER server concerning a session should not have a lifetime greater than + the EMSK for this session. If the ER server + is successfully bootstrapped, it should also add the ERP-Realm AVP + after removing the Key AVP with Key-Type of rRK in the EAP/DEA + message. This ERP-Realm information can be used by the authenticator + to notify the peer that ER server is bootstrapped, and for which + domain. How this information can be transmitted to the peer is outside + the scope of this document. This information needs to be sent to the + peer if both implicit and explicit bootstrapping mechanisms are + possible, because the ERP message and the root key used for protecting + this message are different in bootstrapping exchanges and + non-bootstrapping exchanges. +

+ +

+ Bootstrapping the ER server during the first re-authentication + (also known as explicit bootstrapping) is less resource-consuming, + since root keys are generated and cached only when needed. On the + other hand, in that case first re-authentication requires a + one-round-trip exchange with the home EAP server, which is less + efficient than the implicit bootstrapping scenario. 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 it better + to leave it unmodified, so that the server can easily + differenciate between ERP and standard EAP message ? + + + Add the ERP-RK-Request AVP, which contains the name of the + domain where the ER server is located. + + + Add the + Destination-Host AVP to reach the appropriate Diameter EAP + server in case there is more than one in destination domain, + the one with the EMSK. How does the ER server know this + information? Or can we require that all Diameter EAP servers + can be used interchangeably for this purpose? + + Then the proxied EAP/DER request is sent and routed to the + home Diameter 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 with Key-Type AVP + set to rRK. 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 application Id + (code TBD) + + Extract and cache the content of the Key AVP with Key-Type set + to rRK, as described in implicit scenario. + The ERP/DEA message 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 (rRK)) + (Key AVP (rMSK)) + <---------------------- + Diameter ERP/DEA + (EAP-Finish) + (Key AVP (rMSK)) +]]> + +

+ +

+ This section describes in detail a re-authentication exchange with an + ER server that was previously bootstrapped. 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 +]]> + 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 + mechanism. In this case, the peer responds with an EAP-Initiate/Re-auth + message. If the authenticator does not support + ERP (pure Diameter EAP support), it + discards the EAP packets with an unknown ERP-specific code + (EAP-Initiate). The peer should fallback to full EAP authentication in + this case. When the authenticator receives an + EAP-Initiate/Re-auth message from the peer, it processes as described in + with regards to the EAP state machine. It + creates a Diameter EAP Request message following the general process of + Diameter EAP, 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 ? + + + The Auth-Request-Type AVP content is set to [Editor's note: FFS + -- cf. open issues]. + + The EAP-Payload AVP contains the EAP-Initiate/Re-Auth + message. + 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 EAP-Finish/Re-auth message. + + In case of successful authentication, an instance of the Key AVP + containing the Re-authentication Master Session Key (rMSK) derived + by ERP is included. + 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 , 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. + This AVP has the M and V bits cleared. +

+ +

+ The Key AVP is + of type "Grouped" and is used to carry the rRK or 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 2 for rRK or 3 for + rMSK. +

+ +

+ 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, or the rMSK sent by ER server to authenticator. + 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 application. A number of issues appear when we try to do + handover while using Diameter ERP: + how to manage the Session-Id AVP -- is it a new session each + time, or do we try to reuse the same Diameter session?; + + how does the ER authenticator acquire the Authorization AVPs? Is + it cached in the Diameter ER server (received during bootstrapping) + or do we use first Authenticate-Only with ER server, then + Authorize-Only with home domain (and in that case how does the ER + authenticator learn what the home domain is?) + + how does the peer learn the ERP domain of the new authenticator + -- this is being addressed in HOKEY architecture draft; + + how does the home server reachs the peer to for example terminate + the session if there is no notification sent to the home domain; + 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. In roaming environments, it + might be useful that a broker provides ERP services. The security + implications of storing the DSRK generated for the visited domain into + the broker's server should be studied. 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 . +

+ +

+ 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 & Key AVPs? What is the worst + case? For example if a domain tricks the peer into beliving it is + located in a different domain? + 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? + +

+ + + + + &RFC2119; + + &RFC3588; + + &RFC4072; + + &RFC5295; + + &RFC5296; + + &I-D.ietf-dime-local-keytran; + + &RFC3748; + + + + &RFC5247; + + +