Diameter support for EAP Re-authentication Protocol (ERP)

@@ -107,46 +111,57 @@

defines the EAP Re-authentication Protocol (ERP) and mechanism that consists in the two following - steps: - (bootstrapping) Creation of a root key for the session, after - initial EAP authentication of the peer. This root key is distributed - from the EAP server to the ER server. How this key is tranported is - not specified in the ERP mechanism. + steps: + Bootstrapping: creation of a root key for re-authentication, + after initial EAP authentication of the peer. This root key is + distributed from the EAP server to the ER server. How this key is + tranported is not specified in the ERP mechanism. - (re-authentication) A one-round-trip ERP exchange between the - peer and the ER server, functionally equivalent to a full EAP + Re-authentication: one-round-trip exchange between the peer and + the ER server, functionally equivalent to a full EAP authentication. - The bootstrapping of the ER server can occur before - (asynchronous) or during (synchronous) the re-authentication. + This document specifies how Diameter is used to carry the re-authentication exchange (second step). For this purpose, we define a - new Application Id for ERP, and re-use the DER/DEA commands. + new Application Id for ERP, and re-use the Diameter EAP commands + (DER/DEA). - It also discusses the key distribution (bootstrapping) and proposes - some solutions for different architectures. Anyway, a deployment that - conforms to this specification may adopt a different mechanism for key - distribution, such as described in . Security considerations for key - distribution are explained in . + We also discuss the key distribution (first step, bootstrapping) and + propose some solutions for different architectures. Anyway, implementors + are free to choose a different mechanism for key distribution, as for + example using RADIUS. + Security considerations for key distribution are explained in .

We re-use here the terminology from . - In particular, the term "EAP server" refers to a server for EAP with - sufficient extensions for ERP to create ERP keying material. + In particular, the EAP server implicitely supports ERP extensions to + generate the ERP keying material and send it to the ER server. These + terms "authenticator", "ER server", "EAP server" denote logical + functional entities and make no assumption on the real implementation + and deployment. - "root key" or "bootstrapping material" refer to the rRK (for ER - server in home domain) or the rDSRK (ER server in separate domain), - depending on the context. + "root key" or "bootstrapping material" refer to the rRK (home ER + server) or rDSRK (foreign ER server) derived from an EMSK, depending on + the context. + + We re-use also some terminology and abbreviations from , for example DER/DEA.

- The following figure shows the components involved in ERP, and their - interactions. During the lifetime of the EMSK derived from a full EAP - authentication, a peer may attach to several authenticators, and - eventually use different ER servers (for example in inter-domain - roaming). + During the lifetime of an EMSK (derived during a full EAP + authentication), a peer may attach to several authenticators. In this + case, re-authentication is more efficient than full authentication, + especially in the case of roaming. ERP provides a mechanism for + re-authentication independent of the link layer, as opposed to IEEE + 802.11r-2008 for example, so it can be used in case of multihoming or + horizontal handovers. The following figure shows the components involved + in ERP, and their interactions. When the peer attaches to a new + authenticator, the ER server involved in the transaction may change, for + example in the case of inter-domain roaming.

- The ER server may be located in the home domain (same as the EAP - server) or the visited domain (same as authenticator, in case it differs - from the home domain). TBD: Can the ER server be located in a - third domain (ex: broker's)? + The ER server may be located in the home domain (same as EAP server) + or the visited domain (same as authenticator, when it differs from the + home domain). TBD: Can the ER server be located in a third domain + (ex: broker's)? - The bootstrapping of the ER server occurs sometime between the - initial EAP authentication, and the first ERP re-authentication. See - section 4 for detail on this - process. Then, the peer re-authenticates, for example after a movement - that makes it attach to a new authenticator. The following figure - describes this process, based on , and - shows how Diameter is used in this context. See section 5 for a detailed description. + The bootstrapping of the ER server has to occur sometime between the + initial EAP authentication and the first ERP re-authentication with this + ER server. See section for detail + on this process. Then, the peer re-authenticates, for example after a + movement that makes it attach to a new authenticator. The following + figure describes this re-authentication, and shows how Diameter is used + in this context. See section + for a detailed description, and following sections for details on the + Diameter messages format.

- EAP-Initiate/Re-auth - =====================================> - Diameter ERP, cmd code DER - User-Name: Keyname-NAI - EAP-Payload: 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 - EAP-Master-Session-Key: rMSK + <================================== + Diameter ERP, cmd code DEA + EAP-Payload: EAP-Finish/Re-auth + EAP-Master-Session-Key: rMSK <---------------------- EAP-Finish/Re-auth ]]> +

- +

+ We define a Diameter ERP Application in this document, with an + Application Id value of TBD. Diameter nodes conforming to + this specification (in the role of ER server or authenticator) MUST + advertise support by including the Diameter ERP Application ID value in + the Auth-Application-Id AVP of the Capabilities-Exchange-Request and + Capabilities-Exchange-Answer command . + + 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 the + next section (although these AVP have the 'M' flag cleared). +

+ +

+ This specification defines the following new AVPs. + +

+ The ERP-RK-Request AVP (AVP Code TBD) is of type + grouped AVP. It is used by the ER server to request root key material + used in ERP. + + This AVP has the M and V bits cleared. + +

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

+ +

+ The ERP-Realm AVP (AVP Code TBD) is of type + {DiameterIdentity? OctetString?}. It contains the name of + the realm in which the ER server is located. + + FFS: We may re-use Origin-Realm here instead? On the other + hand, ERP-Realm may be useful in CER/CEA with a NAS... + + This AVP has the M and V bits cleared. +

+ +

+ The ERP-RK-Answer AVP (AVP Code TBD) is of type + grouped AVP. It is used by the home EAP server to provide ERP root key + material to the ER server. + + This AVP has the M and V bits cleared. + +

+ + { ERP-RK } + { ERP-RK-Name } + { ERP-RK-Lifetime } + * [ AVP ] +]]> + +

+ +

+ The ERP-RK AVP (AVP Code TBD) is of type OctetString. + It contains the root key (either rRK or rDSRK) to be used for ERP with + the peer to which the current session belongs. How this material is + derived and used is specified in . + + Can we re-use EAP-Master-Session-Key here? + + This AVP has the M and V bits cleared. +

+ +

+ The ERP-RK 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 . + + Can we re-use EAP-Key-Name here? + + This AVP has the M and V bits cleared. +

+ +

+ The ERP-RK-Lifetime AVP (AVP Code TBD) is of type + Unsigned64? 32? and contains the root key material + remaining lifetime in seconds. It MUST not be greater than the + remaining lifetime of the EMSK it is derived from. FFS: is it + better to pass an absolute value here, for example expiration date? + How to express it then (TZ, ...)? Synchronization problems? + + This AVP has the M and V bits cleared. +

+ +

+ We do not define any new command in this specification. We reuse the + Diameter-EAP-Request and Diameter-EAP-Answer commands defined in . + + The Application Id field in the command header and the value in + Auth-Application-Id AVP which is redundant??? can be set to + Diameter EAP application or Diameter ERP application, depending on the + situation, as explained in the next sections. + + Since the original ABNF of these commands allow other optional AVPs + ("* [ AVP ]"), and the new AVPs defined in this specification do not + have the 'M' flag set, the ABNF does not need any change. Anyway, a + Diameter node that advertize support for the Diameter ERP application + MUST support the ERP-RK-Request and ERP-RK-Answer AVP Therefore, + in DER/DEA with Diameter ERP application ID, do we set the 'M' flag to + these AVPs?. + +

+ +

- + Bootstrapping involves the ER server and the EAP server directly, but + also indirectly the peer and the authenticator. For ERP to be + successful, the peer must derive the same keying material as the ER + server. To make this possible, it must learn the domain name of the ER + server. How this is achieved is outside the scope of this specification, + but it usually involves that the authenticator is configured to + advertize this domain name. This could be achieved for example by + including the ERP-Realm AVP in a CER/CEA exchange. + + As stated in the , the bootstrapping + of an ER server has to happen between the initial EAP authentication of + the peer, when the EMSK is created, and the moment the peer + re-authenticates with this ER server, when the bootstrapping material is + needed. While asynchrounous solutions are perfectly possible, it is + usually easier to bootstrap the ER server during one of these + events. + +

+ Bootstrapping an ER server during the initial EAP authentication + offers the advantage that the server is immediatly available for + re-authentication of the peer, thus minimizing the re-authentication + delay. + + On the other hand, re-authentication may only concern a small + number of peers in the visited domain. Deriving and caching key + material for all the peers (for example, for the peers that do not + support ERP, or that are not mobile) is a waste of resources and + SHOULD be avoided. In addition, bootstrapping ERP during full EAP + authentication may prevent re-authentication in case of inter-domain + roaming. Hence, while this mecanism is useful in some situations, it + should be deployed with care. + + In the case where ER server is collocated with the Home EAP server, + ER bootstrapping is transparent with regards to this specification, + although some sort of communication might be needed inside the node. + In this case, the server MUST advertise support of both the Diameter + EAP application and the Diameter ERP application, but the new AVPs + defined in this specification are not used. + + When ER server and EAP server are different entities with regards + to Diameter, one or more Diameter EAP proxy(ies) is(are) needed in the + same domain as the ER server. While this(these) proxy(ies) might be + separate entity(ies) with secure communication channel with the ER + server, it is functionally equivalent to consider that the ER server + acts as a Diameter EAP proxy. In the rest of this section, we consider + that the ER server acts as a Diameter EAP proxy in its domain. + + In order to bootstrap the ER server during full EAP authentication, + this server must be on the route, and act as a proxy, for the first + and last round of exchanges of the full EAP authentication, as + captured in the figure bellow. + +

+ + 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) + (ERP-RK-Answer) + <------------------------- + 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, then forwards the request. + + If the EAP server does not support ERP extensions, it will simply + ignore this grouped AVP and continue as specified in . If the server supports the ERP extensions, + it caches the ERP-Realm value with the session, and continues the EAP + authentication. When the authentication is complete, if it is + successful and the EAP method generated an EMSK, the server MUST + compute the rRK or rDSRK (depending on the value of ERP-Realm) as + specified in , and add an ERP-RK-Answer + AVP in the Diameter-EAP-Request message, in addition to the MSK and + EAP-Success payload. FFS: is it important to check that the + server that added the ERP-RK-Request is in the path of the answer? + What's the worst that can happen? + + 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 and remove any ERP-RK-Answer AVP, and save its + content. If the message does not contain an ERP-RK-Answer AVP, the ER + server MAY save this information to avoid possible attempts later for + this session. In any case, the information stored SHOULD NOT have a + lifetime greater than the EMSK lifetime FFS: 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 + Diameter-EAP-Answer 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 it possible? It would be + useful... +

+ +

+ Bootstrapping the ER server during the first re-authentication + offers several advantages: it saves resources, since we generate and + cache only useful keying material, it can also accomodate inter-domain + roaming or ER servers that loose their state (for example after + reboot). + + On the other hand, the first re-authentication with the ER server + requires a one-round-trip 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). Note that following re-authentications + for the same session with the same ER server will not have this + additional delay. + + describes two types of bootstrapping + for ERP: implicit bootstrapping and explicit bootstrapping. In + implicit bootstrapping, the peer knows the domain it is located in, + and assumes that the ER server already possess the keying material for + the session. In this case, the peer uses a Keyname-NAI in the form + "EMSKname@localdomain". In explicit bootstrapping, the Keyname-NAI is + in the form "EMSKname@homedomain". As we will see in next section + , the domain part of the + Keyname-NAI becomes the Destination-Realm of the Diameter message, and + the Application Id is set to Diameter ERP application. + + In the case of implicit bootstrapping (how the peer learns that the + ER server is bootstrapped is outside the scope of this specification) + or after a first succesful re-authentication in the visited domain, + the message is routed to the local ER server following normal Diameter + routing. If the ER server does not have key information corresponding + to this EMSKname, return an error to the peer? proxy the request + and send ERP-RK-Request to the home EAP server? How do we learn which + is the home domain?. See the next section for detail. + + In the case of explicit bootstrapping (the ERP message has its 'B' + flag set), if an ER server exists in the visited domain, it SHOULD be + configured for and act as a Diameter ERP proxy, and process the + messages as described below. If not, the ER server in the home domain + will be used, which is less efficient. The description that follow for + the ER server in the visited domain is also valid for the ER server in + the home domain. + + What should we do if the ER server receives an explicit + bootstrapping request but already possess the rDSRK? + + The ER server proxies the request (DER with Diameter ERP + application code) as follow, in addition to standard proxy + operations: + Change the Application Id in the header of the message to + Diameter EAP Application (code 5). What about the + Application-Auth-Id AVP? + + Add the ERP-RK-Request AVP, which contains the name of the + domain the ER server is located in (with regards to ERP). + Then the request is forwarded as usual. With its Diameter EAP + application id and Destination-Realm set to the home domain of the + peer, the request reaches the home EAP server. If this server does not + support 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 + DEA reply message following standard processing from (in particular EAP-Master-Session-Key AVP is + used to transport the rMSK), and includes the ERP-RK-Answer AVP. + + The ER server receives this DEA and proxies it as follow, in + addition to standard proxy operations: + Set the Application Id back to Diameter ERP (code + TBD) + + Extract and cache the content of the ERP-RK-Answer. + The DEA is then forwarded to the authenticator, that can use + the rMSK as described in . + + The figure below captures this Diameter ERP Proxy behavior: + +

+ + Diameter ERP/DER + (EAP-Initiate) + ------------------------> + Diameter EAP/DER + (EAP-Initiate) + (ERP-RK-Request) + + <------------------------ + Diameter EAP/DEA + (EAP-Finish) + (ERP-RK-Answer) + (rMSK) + <---------------------- + Diameter ERP/DEA + (EAP-Finish) + (rMSK) +]]> + +

- + This section describes a re-authentication exchange with a + bootstrapped ER server. The peer is assumed to know the domain of the + bootstrapped ER server in advance. See previous section for more information. + EAP-Initiate/Re-auth-start with Domain-Name TLV is a possibility for the + peer to learn the domain of the ER server attached to the + authenticator. + + The following figure describes the re-authentication exchange. + Explication follow. + +

+ + 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 + EAP-Master-Session-Key: rMSK + <---------------------- + EAP-Finish/Re-auth + +]]> + + + The authenticator that does not support ERP discards EAP packets with unknown ERP-specific + code (EAP-Initiate). The peer falls back to full EAP authentication in + that case. + + When the ERP-compatible authenticator receives an + EAP-Initiate/Re-auth message from the peer (or after having sent a + EAP-Initiate/Re-auth-start packet), it process as described in with regards to the EAP state machine, and + similarly to Diameter EAP, with regards to + Diameter, with the following differences: + The application id is set to Diameter ERP instead of Diameter + EAP. + + The User-Name and Destination-Realm are derived from the + Keyname-NAI. + + How do we create / retrieve the Session-Id? + + + The ER server receives this request and process the ERP payload as + described in . If re-authentication is + successful, it creates a DEA answer as described in Diameter EAP, with + the following differences: + The application id is set to Diameter ERP. + + The EAP-Payload AVP contains the ERP message: + EAP-Finish/Re-auth + + The EAP-Master-Session-Key AVP contains the rMSK + + The Result-Code AVP contains DIAMETER_SUCCESS. + In case the re-authentication fails, the Result-Code AVP + contains an error code, and no EAP-Master-Session-Key AVP is + included. + + When the authenticator receives this answer, it processes it as + described in Diameter EAP: forwards the EAP payload to the peer, and use + the rMSK as a shared secret in Secure Association Protocol. +

+ +

+ This section describes how sessions are handled in case of + re-authentication. + + See guidelines in I-D.ietf-dime-app-design-guide + + During initial full EAP authentication, the identity of the + peer is used to create the Session-Id AVP, which is then used during + accounting. When the peer attaches to a new authenticator and performs + ERP, its identity is not disclosed to the authenticator. Instead, the + peer presents the Keyname-NAI. This identifiers contains the EMSKName as + user part. + + The new authenticator will therefore derive the new Session-Id + from this EMSKName and use this for accounting purpose. + + Although the home EAP server is able to link EMSKName with the + peer's identity, the other Diameter entities do not have this mapping. + In particular, the realm part of Keyname-NAI is the visited network. How + does the authenticator figures out that the account records must be sent + to the home domain of the peer? + + It is possible to cache the necessary information at the ER + server level. Is it useful to specify this mechanism in this + document?

- Remember, it's important to acknowledge people who have contributed - to the work. + Remember, it's important to acknowledge people who have + contributed to the work

- This memo includes no request to IANA. + Request a new Application Id for Diameter ERP. - (It's good - indeed pretty much mandatory now - to have an explicit - note because otherwise IANA wastes cycles trying to figure out if - something is needed..) + Request new AVP Codes for ERP-* AVPs

- Remember to consider security from the start.. and all drafts are - required to have a security considerations section before they will pass - the IESG. + Security considerations from RFC3588 (+bis), RFC4072, RFC5247, + RFC5295, and RFC5296 apply + + Is it safe to use ERP-RK-Request / Answer AVPs? What is the + worst case?

- - - - - - - Key words for use in RFCs to Indicate - Requirement Levels - - - Harvard University - -

- - 1350 Mass. Ave. - - Cambridge - - MA 02138 - - - - +1 617 495 3864 - - sob@harvard.edu -

- - - - - General - - keyword - - - In many standards track documents several words are used to - signify the requirements in the specification. These words are - often capitalized. This document defines these words as they - should be interpreted in IETF documents. Authors who follow these - guidelines should incorporate this phrase near the beginning of - their document: - 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 RFC 2119. - - - Note that the force of these words is modified by the - requirement level of the document in which they are used. - - - - - - - - - - - - - + &RFC2119; &RFC3588; - &RFC4005; + &RFC4072; &RFC5295; @@ -308,13 +694,13 @@ + &RFC3748; + &I-D.draft-ietf-hokey-key-mgm; - -

- You can add appendices just as regular sections, the only difference - is that they go within the "back" element, and not within the "middle" - element. And they follow the "reference" elements. -

+ &I-D.draft-gaonkar-radext-erp-attrs; + + &I-D.draft-ietf-dime-app-design-guide; +