# HG changeset patch # User Sebastien Decugis # Date 1288928343 -32400 # Node ID 9d8dd59747f49b117ddff5b74bf6b7e1d4be22cc # Parent 6ac9daa8c7752ae2f97826846bbc45505fd76882 Cleanup folder structure diff -r 6ac9daa8c775 -r 9d8dd59747f4 2009-02-20 interim ERP v2.odp Binary file 2009-02-20 interim ERP v2.odp has changed diff -r 6ac9daa8c775 -r 9d8dd59747f4 DiME/drafts/draft-ietf-dime-erp.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/DiME/drafts/draft-ietf-dime-erp.xml Fri Nov 05 12:39:03 2010 +0900 @@ -0,0 +1,888 @@ + + + + + + + + + +]> + + + + + + + + + + + + + + + + + + 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 + + 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" 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? + + + +
+ + + + + &RFC2119; + &RFC3588; + &RFC4072; + &RFC5295; + &RFC5296; + &I-D.ietf-dime-local-keytran; + &RFC3748; + + + + &RFC5247; + + + diff -r 6ac9daa8c775 -r 9d8dd59747f4 DiME/drafts/draft-sdecugis-dime-diameter-erp.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/DiME/drafts/draft-sdecugis-dime-diameter-erp.xml Fri Nov 05 12:39:03 2010 +0900 @@ -0,0 +1,796 @@ + + + + + + + + + + + + + + + +]> + + + + + + + + + + + + + + + + + + Diameter support for EAP + Re-authentication Protocol (ERP) + + + NICT + +
+ + 4-2-1 Nukui-Kitamachi + + Koganei, Tokyo + + 184-8795 + + JP + + + sdecugis@nict.go.jp +
+ + + + + Operations & Management + + Diameter Maintenance and Extensions (DIME) + + Internet-Draft + + ERP + + Diameter + + Re-authentication + + + The EAP Re-authentication Protocol (ERP) provides a mechanism to + optimize EAP authentication delay in the case of re-authentication, + which can be significant in roaming mobile situation. This mechanism + assumes that a protocol for Authentication, Authorization and Accounting + (AAA) is available to transport ERP between the authenticator(s) and the + EAP/ERP server. draft-gaonkar-radext-erp-attrs-03 specifies the + transport of ERP using RADIUS. This document specifies the transport of + ERP using Diameter. + + + + +
+ defines the EAP Re-authentication + Protocol (ERP) and mechanism that consists in the two following + 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: one-round-trip exchange between the peer and + the ER server, functionally equivalent to a full EAP + 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 Diameter EAP commands + (DER/DEA). + + 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 . + +
+ This document differs from + in its design and scope. In this new version, we use a new Diameter + application id for messages with ERP payload exchanged between + authenticator and ER server. This simplifies the routing of Diameter + messages to the appropriate server, and allows more flexibility in the + deployment of ERP. + + The scope of previous documents ( and ) was focused on the + bootstrapping of the mechanism. In particular, these documents did not + consider the routing of Diameter message for re-authentication + exchanges (ERP exchange, and also for + the second document). By re-using the Diameter EAP application, they + create implicit constraints on routing of messages that cannot be met + by standard Diameter routing algorithm, as defined in the Diameter Base Protocol. + + A separate Diameter application solves this routing issue, and can + also allow the authenticator to dynamically discover if the local + domain supports re-authentication or not. +
+
+ +
+ We re-use in this document the terminology from . In particular, unless specified otherwise, the + EAP server has implicit support for ERP extensions for generation of ERP + keying material and its transmission to ER server. These terms + "authenticator", "ER server", "EAP server" designate logical functional + entities and make no assumption on the real implementation and + deployment. + + "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 re-use also some terminology and abbreviations from , for example DER/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 . +
+
+ +
+ During the lifetime of an EMSK (derived during a full EAP + authentication by compatible EAP methods), 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, so it can + be used in case of multihoming or handovers between different access + technologies. 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 home EAP server is assumed to be + constant for a given peer. + +
+ |Authenticator|<=======>| ER server | <---> | EAP | + +-------------+ +-----------+ | server | + +--------+ + (*) Several protocols can be used between ER server and + home EAP server to transport bootstrapping material. +]]> +
+ + 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). Can the ER server be located in a + third domain (ex: broker's)? + + 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 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. + +
+ + 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. + + The content of this section is to be written, + I am just listing the ideas here. + + See guidelines in . + + 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? It would + involve: + An additional AVP during bootstrapping of ER server, in the + ERP-RK-Answer, to pass the real User-Name and Session-Id (only in + case of explicit bootstrapping) + + An additional AVP in Diameter ERP/DEA (EAP-Finish/Re-Auth) to + pass the real Session-Id and User-Name and Destination-Realm of the + re-authenticated peer, for accounting messages. + +
+ +
+ Hannes Tschofenig, Lakshminath Dondeti, Julien Bournelle, and Lionel + Morand wrote the initial Diameter ERP draft document. +
+ +
+ Vidya Narayanan reviewed a rough draft version of the previous + document and found some errors. + + Qin Wu and Glen Zorn actively participated in the discussions on the + design for Diameter ERP, providing the point of view and experience from + HOKEY workgroup. + + Hannes Tschofenig provided useful advices for the writing of this + 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 created by in . + +
+ +
+
+ +
+ This specification requires IANA to allocate new values from the + "AVP Codes" registry defined in for the + following AVPs: + ERP-RK-Request + + ERP-Realm + + ERP-RK-Answer + + ERP-RK + + ERP-RK-Name + + ERP-RK-Lifetime + These AVPs are defined in section . +
+
+ +
+ The security considerations from the following RFC apply here: , , , , and . + + FFS: 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? +
+ + + + + &RFC2119; + + &RFC3588; + + &RFC4072; + + &RFC5295; + + &RFC5296; + + + + &RFC3748; + + &RFC4187; + + &RFC5247; + + &I-D.ietf-hokey-key-mgm; + + &I-D.gaonkar-radext-erp-attrs; + + &I-D.ietf-dime-erp; + + &I-D.wu-dime-local-keytran; + + &I-D.ietf-dime-app-design-guide; + + + diff -r 6ac9daa8c775 -r 9d8dd59747f4 DiME/presentations/ERP-IETF74.odp Binary file DiME/presentations/ERP-IETF74.odp has changed diff -r 6ac9daa8c775 -r 9d8dd59747f4 DiME/presentations/ERP-IETF75.pptx Binary file DiME/presentations/ERP-IETF75.pptx has changed diff -r 6ac9daa8c775 -r 9d8dd59747f4 DiME/presentations/ERP-IETF76.pptx Binary file DiME/presentations/ERP-IETF76.pptx has changed diff -r 6ac9daa8c775 -r 9d8dd59747f4 DiME/presentations/ERP-IETF77.pptx Binary file DiME/presentations/ERP-IETF77.pptx has changed diff -r 6ac9daa8c775 -r 9d8dd59747f4 DiME/presentations/ERP-Interim-2009-02-20.odp Binary file DiME/presentations/ERP-Interim-2009-02-20.odp has changed diff -r 6ac9daa8c775 -r 9d8dd59747f4 IETF74-ERP.odp Binary file IETF74-ERP.odp has changed diff -r 6ac9daa8c775 -r 9d8dd59747f4 IETF75-ERP.pptx Binary file IETF75-ERP.pptx has changed diff -r 6ac9daa8c775 -r 9d8dd59747f4 IETF76-ERP.pptx Binary file IETF76-ERP.pptx has changed diff -r 6ac9daa8c775 -r 9d8dd59747f4 IETF77-ERP.pptx Binary file IETF77-ERP.pptx has changed diff -r 6ac9daa8c775 -r 9d8dd59747f4 Makefile --- a/Makefile Mon Oct 25 17:07:09 2010 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,14 +0,0 @@ -all: New_ERP_draft.txt - -clean: - rm -f New_ERP_draft.txt - -New_ERP_draft.txt: New_ERP_draft_src.txt Makefile - fold -s New_ERP_draft_src.txt > New_ERP_draft.txt - echo "=====================" >> New_ERP_draft.txt - echo " History:" >> New_ERP_draft.txt - hg log New_ERP_draft_src.txt >> New_ERP_draft.txt - echo "=====================" >> New_ERP_draft.txt - fromdos New_ERP_draft.txt - - diff -r 6ac9daa8c775 -r 9d8dd59747f4 New_ERP_draft.txt --- a/New_ERP_draft.txt Mon Oct 25 17:07:09 2010 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,431 +0,0 @@ -*Status of this Memo* - -This is a work document intended to present ideas for a possible future -Internet-Draft in the DIME working-group. -The copyright for this memo is writen by the end of the document (same as -Internet-Drafts) - - - -*Abstract* - -The EAP Re-authentication Protocol [RFC5296] provides an optimization for EAP -authentication when a peer moves from an authenticator to another. This -protocol assumes that a AAA protocol is available to transport the ERP messages -between authenticator and ER server. [draft-gaonkar-radext-erp-attrs-03] -specifies the transport of ERP using RADIUS. This document specifies the -transport of ERP using Diameter [RFC3588]. - - - -*Differences with [draft-ietf-dime-erp-00]* - -In this document, we specify a new Diameter application ID for Diameter -messages transporting ERP exchanges between authenticator and ER server. We -re-use the mechanism described in [draft-ietf-dime-erp-00] as an option -available to provide implicit bootstrapping to the ER server. - - - -*Introduction.* - -During full EAP authentication, both the peer and the home EAP server derive -EMSK material in addition to MSK. The EMSK can be used to derive a -re-authentication root key (rRK or rDSRK) as described in [RFC5296]. This root -key is transported to an ER server, this is called bootstrapping the ER server. -When the peer re-authenticates using ERP, a one round-trip exchange occurs -between the authenticator and the ER server, where new rMSK material is -derived. The ER server may be located in the visited domain or home domain. - -There are two types of exchanges between AAA entities in the Re-authentication -mechanism: transport of the re-authentication root key between the home EAP -server and the ER server to bootstrap the mechanism, and transport of ERP -messages and rMSK material between ER server and authenticator. This document -specifies how the re-authentication exchange is transported using Diameter. It -also provides information on how bootstrapping can be achieved in several -situations. - - Diameter +--------+ - +-------------+ ERP +-----------+ (*) | Home | -Peer <->|Authenticator|<=======>| ER server | <---> | EAP | - +-------------+ +-----------+ | server | - +--------+ -(*) Several protocols can be used between ER server and home EAP server to -transport bootstrapping material. Diameter EAP is one of the possibilities. - - Figure 1. Diameter applications used in the ERP mechanism. - - - -*Assumptions.* - -For the peer to start an ERP exchange when attaching to a new authenticator, -the following assumptions must be verified. Note that the peer can always fall -back to full EAP authentication if one of these conditions is not met. These -assumptions are implicit from [RFC5296]. - -The peer must have non-expired keying material (EMSK) derived from a previous -full EAP authentication. - -The peer must learn the realm of the new authenticator before starting the -exchange, for example using L2-dependent mechanism. If this condition is not -met, the peer cannot assume that an ER server is available and bootstrapped in -the realm of this authenticator. It should start an ERP bootstrapping exchange -as described in [RFC5296]. In addition, if the peer is attaching to this realm -for the first time since the EMSK was derived (inter-domain handover), an ERP -bootstrapping exchange must be initiated. - -The authenticator must support ERP extensions. If this condition is not met, -the ERP messages will be dropped by the authenticator conforming to [RFC4072] -and ERP will fail. - - - -*Overview* - -We define a new Diameter Application ID for ERP. When the authenticator -receives an EAP-Initiate/Re-auth message, it encapsulates it in a DER message -following the rules described in [RFC4072]. The application id of the DER -message is set to the Diameter ERP application ID. The User-Name and -Destination-Realm AVPs are extracted from the keyName-NAI included in the ERP -message, as described in [RFC5296]. In the case were ERP is already -bootstrapped in this domain, and the peer knows it, the Destination-Realm of -the message is the local domain. In other cases, the peer is initiating a -bootstrapping ERP exchange, and the Destination-Realm is the home domain. - -When ERP is already bootstrapped, the message is routed to the bootstrapped ER -server. This server processes the ERP message as described in [RFC5296] then -derives a new rMSK and answers a DEA encapsulating the EAP-Finish/Re-auth -answer and the rMSK for the authenticator. Re-authentication is complete {see -pending question in the end of this document}. This exchange is described in -Figure 2 bellow. - -There are several options to bootstrap the ER server. This document discusses -some of the options, but a different mechanism not described here may be -deployed as well. See the following sections for more details about -bootstrapping scenarii. - - ER server - (bootstrapped) - Peer Authenticator (local or home domain) - ==== ============= ====================== - [ <------------------------ ] - [optional EAP-Initiate/Re-auth-start] - - -----------------------> - 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 - - Figure 2. Diameter ERP exchange. - - - -*Bootstrapping* - -The purpose of bootstrapping is to provide the keying material to the ER -server. This keying material is rRK (directly derived from EMSK) when the ER -server is in the peer's home domain. The keying material is rDSRK (derived from -DSRK, itself derived from EMSK) when the ER server is in the visited domain. - - - -*Scenario 1: explicit bootstrapping* - -As described in [RFC5296], an explicit bootstrapping exchange can be initiated -by the peer. In this case, the realm part of the Keyname-NAI is the home domain -of the peer. - -The authenticator processes the ERP as described in the overview: encapsulate -the ERP message in a DER command with application-id set to Diameter ERP. The -Destination-Realm extracted from Keyname-NAI is the home domain. - -If an ER server is located in the local domain, it should proxy the request and -process as described bellow. Otherwise the request is sent to the ER server in -the home domain. - -When the ER server (in local or home domain) receives the ERP/DER request, it -must process as follow: -- Check in the local key store if a key with same name is available. If such -key is found, process the request locally and answer. -- Check if the EAP-Initiate/Re-auth message has the [B] (bootstrapping) flag -set. If this flag is not set, relay the message without altering it (except -adding the Route-Record information) or reply with an error if no other -Diameter node is available to handle the request, following the rules of -Diameter Base Protocol. -- If the [B] flag was set, the message is proxied locally and modified as -follow: - * Change the application-id of the message from Diameter ERP to Diameter EAP -(so that the message will reach the Home EAP server). - * Add the ERP-RK-Request AVP, defined in this document. - * Send the new message. It will reach the Home EAP server. - -If the home EAP server does not support ERP extensions, it replies with an -error since encapsulated EAP-Initiate/Re-auth command is not understood. -Otherwise, it processes the EAP-Initiate/Re-auth message as described in -[RFC5296] and derives the requested rDSRK or rRK, and new rMSK. It sends this -material using the new ERP-RK-Answer AVP described in this document. It also -includes the realm of the ER server in the EAP-Finish/Re-auth message to inform -the peer of the location of the ER server. - -The ER server receives this DEA, extracts and cache the rRK or rDSRK material, -restores the application-id to Diameter ERP and forwards the message to the -authenticator. - -This flow is captured figure 3. - -Authenticator ER server Home EAP server -============= ========= =============== - -----------------------> - 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) - - Figure 3. ERP explicit bootstrapping message flow. - - - -*Scenario 2: implicit bootstrapping during full EAP authentication* - -In some deployment scenarii, the ER server may be collocated with an EAP proxy -or server. In that case, the optional ERP AVPs defined in this document may be -used during initial full EAP authentication to provide implicit bootstrapping -(section 5.1 of [RFC5296]) as described bellow. - -In this scenario, the ERP key material is derived and cached regardless of the -peer support and willingness for ERP. This may lead to scalability and other -issues. Implementors may provide other ways to select which sessions should use -implicit bootstrapping. - -In the first round of full EAP exchange, the ER server adds the ERP-RK-Request -AVP to the DER message. -If the home EAP server supports ERP extensions, it caches this request and -continues the normal EAP authentication until completion. Otherwise, the -optional AVP is simply ignored. -When the authentication is successful and EMSK is generated, the home EAP -server derives the rRK or rDSRK as requested, and adds this material to the -last DEA in the ERP-RK-Answer AVP defined in this document. The server may -check that the ER server that requested the material is in the Route-Record -list of the last DER, but this is not mandatory. - -When the ER server collocated with EAP proxy receives the DEA containing -ERP-RK-Answer AVP, it extracts this AVP and saves the rRK or rDSRK material for -later use. - - EAP Proxy / -Authenticator ER server Home EAP server -============= =========== =============== - -------------------------> - 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) - - Figure 4. Implicit ERP bootstrapping during full EAP authentication. - - - -*Scenario 3: Case of MIP6* - -{TODO: study this case ?} - - - -*Scenario 4: Other possibilities* - -{In case implementation-specific solution is retained, list here the -constraints?} - - - -*Commands and AVPs* - -This document does not define a new command. It reuses the Diameter-EAP-Request -and Diameter-EAP-Answer as defined in [RFC4072]. It is also compatible with -extensions defined in [draft-ietf-dime-mip6-split-16]. - - Command-Name Abbrev. Code Reference Application - --------------------------------------------------------- - Diameter-EAP-Request DER 268 RFC 4072 Diameter ERP - Diameter-EAP-Answer DEA 268 RFC 4072 Diameter ERP - - Figure 5: Command Codes -The following new AVPs are defined in this document. - - - -*ERP-RK-Request AVP* - -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-RK-Request ::= < AVP Header: TBD > - { ERP-Realm } - * [ AVP ] - - - -*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?} - - - -*ERP-RK-Answer AVP* - -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-Answer ::= < AVP Header: TBD > - { ERP-RK } - { ERP-RK-Name } - { ERP-RK-Lifetime } - * [ AVP ] - - - -*ERP-RK 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 this session -belongs. How this material is derived and used is specified in [RFC5296]. - - - -*ERP-RK-Name AVP* - -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 [RFC5296]. - - - -*ERP-RK-Lifetime AVP* - -The ERP-RK-Lifetime AVP (AVP Code TBD) is of type {Unsigned64? 32?} and -contains the root key material lifetime in seconds. - - - -*Pending question on accounting and sessions.* - -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? - - - -*Full Copyright Statement* - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -===================== - History: -changeset: 17:8b6e98eec7ef -parent: 14:1c2d1b7327af -user: Sebastien Decugis -date: Thu Mar 19 10:46:29 2009 +0900 -summary: Added copyright and status before publishing. - -changeset: 13:aa31cf892b1b -parent: 11:c8dd0bdbd9e6 -user: Sebastien Decugis -date: Wed Mar 18 14:21:19 2009 +0900 -summary: Yet more cleanups... - -changeset: 11:c8dd0bdbd9e6 -user: Sebastien Decugis -date: Wed Mar 18 14:16:22 2009 +0900 -summary: More cleanups. - -changeset: 9:5fdd3345477f -user: Sebastien Decugis -date: Wed Mar 18 14:06:05 2009 +0900 -summary: Cleanups. - -changeset: 8:45a13fe6e0be -user: Sebastien Decugis -date: Wed Mar 18 13:21:39 2009 +0900 -summary: Completed initial description of the mechanism for explicit bootstrapping and implicit during Diameter EAP authentication. - -changeset: 5:5fc766d71da4 -parent: 3:e7bcb9ee39b5 -user: Sebastien Decugis -date: Tue Mar 17 17:22:52 2009 +0900 -summary: Temporary status, scenarios must be developped a little more. The basic ideas are present already. For early comments. - -changeset: 3:e7bcb9ee39b5 -user: Sebastien Decugis -date: Tue Mar 17 14:20:38 2009 +0900 -summary: Document to present alternative design for Diameter ERP, initial commit (incomplete work) - -===================== diff -r 6ac9daa8c775 -r 9d8dd59747f4 New_ERP_draft_src.txt --- a/New_ERP_draft_src.txt Mon Oct 25 17:07:09 2010 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,283 +0,0 @@ -*Status of this Memo* - -This is a work document intended to present ideas for a possible future Internet-Draft in the DIME working-group. -The copyright for this memo is writen by the end of the document (same as Internet-Drafts) - - - -*Abstract* - -The EAP Re-authentication Protocol [RFC5296] provides an optimization for EAP authentication when a peer moves from an authenticator to another. This protocol assumes that a AAA protocol is available to transport the ERP messages between authenticator and ER server. [draft-gaonkar-radext-erp-attrs-03] specifies the transport of ERP using RADIUS. This document specifies the transport of ERP using Diameter [RFC3588]. - - -*** TODO *** --> Add a Session-Id AVP in the ERP-RK-Answer grouped AVP. This AVP contains the Session ID corresponding to the full EAP authentication. The ER server learns this Session ID and is able to send it to the NAS (how? TBD) when the peer re-authenticates. Then, on successful re-authentication, the NAS can send accounting records containing the proper Session-Id information (is it OK?) - - -*Differences with [draft-ietf-dime-erp-00]* - -In this document, we specify a new Diameter application ID for Diameter messages transporting ERP exchanges between authenticator and ER server. We re-use the mechanism described in [draft-ietf-dime-erp-00] as an option available to provide implicit bootstrapping to the ER server. - - - -*Introduction.* - -During full EAP authentication, both the peer and the home EAP server derive EMSK material in addition to MSK. The EMSK can be used to derive a re-authentication root key (rRK or rDSRK) as described in [RFC5296]. This root key is transported to an ER server, this is called bootstrapping the ER server. When the peer re-authenticates using ERP, a one round-trip exchange occurs between the authenticator and the ER server, where new rMSK material is derived. The ER server may be located in the visited domain or home domain. - -There are two types of exchanges between AAA entities in the Re-authentication mechanism: transport of the re-authentication root key between the home EAP server and the ER server to bootstrap the mechanism, and transport of ERP messages and rMSK material between ER server and authenticator. This document specifies how the re-authentication exchange is transported using Diameter. It also provides information on how bootstrapping can be achieved in several situations. - - Diameter +--------+ - +-------------+ ERP +-----------+ (*) | Home | -Peer <->|Authenticator|<=======>| ER server | <---> | EAP | - +-------------+ +-----------+ | server | - +--------+ -(*) Several protocols can be used between ER server and home EAP server to transport bootstrapping material. Diameter EAP is one of the possibilities. - - Figure 1. Diameter applications used in the ERP mechanism. - - - -*Assumptions.* - -For the peer to start an ERP exchange when attaching to a new authenticator, the following assumptions must be verified. Note that the peer can always fall back to full EAP authentication if one of these conditions is not met. These assumptions are implicit from [RFC5296]. - -The peer must have non-expired keying material (EMSK) derived from a previous full EAP authentication. - -The peer must learn the realm of the new authenticator before starting the exchange, for example using L2-dependent mechanism. If this condition is not met, the peer cannot assume that an ER server is available and bootstrapped in the realm of this authenticator. It should start an ERP bootstrapping exchange as described in [RFC5296]. In addition, if the peer is attaching to this realm for the first time since the EMSK was derived (inter-domain handover), an ERP bootstrapping exchange must be initiated. - -The authenticator must support ERP extensions. If this condition is not met, the ERP messages will be dropped by the authenticator conforming to [RFC4072] and ERP will fail. - - - -*Overview* - -We define a new Diameter Application ID for ERP. When the authenticator receives an EAP-Initiate/Re-auth message, it encapsulates it in a DER message following the rules described in [RFC4072]. The application id of the DER message is set to the Diameter ERP application ID. The User-Name and Destination-Realm AVPs are extracted from the keyName-NAI included in the ERP message, as described in [RFC5296]. In the case were ERP is already bootstrapped in this domain, and the peer knows it, the Destination-Realm of the message is the local domain. In other cases, the peer is initiating a bootstrapping ERP exchange, and the Destination-Realm is the home domain. - -When ERP is already bootstrapped, the message is routed to the bootstrapped ER server. This server processes the ERP message as described in [RFC5296] then derives a new rMSK and answers a DEA encapsulating the EAP-Finish/Re-auth answer and the rMSK for the authenticator. Re-authentication is complete {see pending question in the end of this document}. This exchange is described in Figure 2 bellow. - -There are several options to bootstrap the ER server. This document discusses some of the options, but a different mechanism not described here may be deployed as well. See the following sections for more details about bootstrapping scenarii. - - ER server - (bootstrapped) - Peer Authenticator (local or home domain) - ==== ============= ====================== - [ <------------------------ ] - [optional EAP-Initiate/Re-auth-start] - - -----------------------> - 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 - - Figure 2. Diameter ERP exchange. - - - -*Bootstrapping* - -The purpose of bootstrapping is to provide the keying material to the ER server. This keying material is rRK (directly derived from EMSK) when the ER server is in the peer's home domain. The keying material is rDSRK (derived from DSRK, itself derived from EMSK) when the ER server is in the visited domain. - - - -*Scenario 1: explicit bootstrapping* - -As described in [RFC5296], an explicit bootstrapping exchange can be initiated by the peer. In this case, the realm part of the Keyname-NAI is the home domain of the peer. - -The authenticator processes the ERP as described in the overview: encapsulate the ERP message in a DER command with application-id set to Diameter ERP. The Destination-Realm extracted from Keyname-NAI is the home domain. - -If an ER server is located in the local domain, it should proxy the request and process as described bellow. Otherwise the request is sent to the ER server in the home domain. - -When the ER server (in local or home domain) receives the ERP/DER request, it must process as follow: -- Check in the local key store if a key with same name is available. If such key is found, process the request locally and answer. -- Check if the EAP-Initiate/Re-auth message has the [B] (bootstrapping) flag set. If this flag is not set, relay the message without altering it (except adding the Route-Record information) or reply with an error if no other Diameter node is available to handle the request, following the rules of Diameter Base Protocol. -- If the [B] flag was set, the message is proxied locally and modified as follow: - * Change the application-id of the message from Diameter ERP to Diameter EAP (so that the message will reach the Home EAP server). - * Add the ERP-RK-Request AVP, defined in this document. - * Send the new message. It will reach the Home EAP server. - -If the home EAP server does not support ERP extensions, it replies with an error since encapsulated EAP-Initiate/Re-auth command is not understood. Otherwise, it processes the EAP-Initiate/Re-auth message as described in [RFC5296] and derives the requested rDSRK or rRK, and new rMSK. It sends this material using the new ERP-RK-Answer AVP described in this document. It also includes the realm of the ER server in the EAP-Finish/Re-auth message to inform the peer of the location of the ER server. - -The ER server receives this DEA, extracts and cache the rRK or rDSRK material, restores the application-id to Diameter ERP and forwards the message to the authenticator. - -This flow is captured figure 3. - -Authenticator ER server Home EAP server -============= ========= =============== - -----------------------> - 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) - - Figure 3. ERP explicit bootstrapping message flow. - - - -*Scenario 2: implicit bootstrapping during full EAP authentication* - -In some deployment scenarii, the ER server may be collocated with an EAP proxy or server. In that case, the optional ERP AVPs defined in this document may be used during initial full EAP authentication to provide implicit bootstrapping (section 5.1 of [RFC5296]) as described bellow. - -In this scenario, the ERP key material is derived and cached regardless of the peer support and willingness for ERP. This may lead to scalability and other issues. Implementors may provide other ways to select which sessions should use implicit bootstrapping. - -In the first round of full EAP exchange, the ER server adds the ERP-RK-Request AVP to the DER message. -If the home EAP server supports ERP extensions, it caches this request and continues the normal EAP authentication until completion. Otherwise, the optional AVP is simply ignored. -When the authentication is successful and EMSK is generated, the home EAP server derives the rRK or rDSRK as requested, and adds this material to the last DEA in the ERP-RK-Answer AVP defined in this document. The server may check that the ER server that requested the material is in the Route-Record list of the last DER, but this is not mandatory. - -When the ER server collocated with EAP proxy receives the DEA containing ERP-RK-Answer AVP, it extracts this AVP and saves the rRK or rDSRK material for later use. - - EAP Proxy / -Authenticator ER server Home EAP server -============= =========== =============== - -------------------------> - 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) - - Figure 4. Implicit ERP bootstrapping during full EAP authentication. - - - -*Scenario 3: Case of MIP6* - -{TODO: study this case ?} - - - -*Scenario 4: Other possibilities* - -{In case implementation-specific solution is retained, list here the constraints?} - - - -*Commands and AVPs* - -This document does not define a new command. It reuses the Diameter-EAP-Request and Diameter-EAP-Answer as defined in [RFC4072]. It is also compatible with extensions defined in [draft-ietf-dime-mip6-split-16]. - - Command-Name Abbrev. Code Reference Application - --------------------------------------------------------- - Diameter-EAP-Request DER 268 RFC 4072 Diameter ERP - Diameter-EAP-Answer DEA 268 RFC 4072 Diameter ERP - - Figure 5: Command Codes -The following new AVPs are defined in this document. - - - -*ERP-RK-Request AVP* - -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-RK-Request ::= < AVP Header: TBD > - { ERP-Realm } - * [ AVP ] - - - -*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?} - - - -*ERP-RK-Answer AVP* - -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-Answer ::= < AVP Header: TBD > - { ERP-RK } - { ERP-RK-Name } - { ERP-RK-Lifetime } - * [ AVP ] - - - -*ERP-RK 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 this session belongs. How this material is derived and used is specified in [RFC5296]. - - - -*ERP-RK-Name AVP* - -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 [RFC5296]. - - - -*ERP-RK-Lifetime AVP* - -The ERP-RK-Lifetime AVP (AVP Code TBD) is of type {Unsigned64? 32?} and contains the root key material lifetime in seconds. - - - -*Pending question on accounting and sessions.* - -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? - - - -*Full Copyright Statement* - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - diff -r 6ac9daa8c775 -r 9d8dd59747f4 draft-ietf-dime-erp-00.xml --- a/draft-ietf-dime-erp-00.xml Mon Oct 25 17:07:09 2010 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,560 +0,0 @@ - - - - - - - - - ]> - - - - - - - - - - Diameter Support for EAP Re-authentication Protocol - - - QUALCOMM, Inc. -
- 5775 Morehouse Dr - San Diego - CA - USA - - +1 858-845-1267 - ldondeti@qualcomm.com -
- - - - 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 -
- - - - - - Operations and Management - Diameter Maintenance and Extensions (DIME) - Internet-Draft EAP - Diameter Re-authentication - inter-authenticator roaming - - - - EAP Re-authentication Protocol (ERP) defines extensions to - the Extensible Authentication Protocol (EAP) to support efficient - re-authentication between the EAP peer and an EAP - re-authentication server through any EAP/ERP authenticator. - This document specifies Diameter support for ERP. The Diameter - EAP application is re-used for encapsulating the newly defined - EAP codes specified in the ERP specification. Additionally, - this document also defines specific Diameter processing rules - relevant to ERP. - - - - - - - -
- - RFC 4072 specifies a Diameter - application that carries EAP packets between a Diameter client - and the Diameter Server/EAP server. RFC 5296 defines the EAP Re-authentication - Protocol to allow faster re-authentication of a previously - authenticated peer. - - - - In ERP, a peer is authenticated by the network thanks to - keying material obtained during a previous EAP exchange. This - keying material is derived from the Extended Master Session - Key (EMSK) as defined in the RFC 5295 . To accomplish - the EAP reauthentication functionality, ERP defines two new - EAP codes - EAP-Initiate and EAP Finish. This document - specifies the reuse of Diameter EAP Application to carry these - new EAP messages. - - ERP is executed between the peer and a server located either in - the peer's home domain or in the local domain visited by the - peer. In the latter case, a Domain Specific Root Key (DSRK) is - derived from the EMSK, as defined in the RFC 5295 , and is provided - by the Home EAP server to the local domain server. For that - purpose, this document specifies the transport of the DSRK - using the Diameter EAP Application. - -
- -
- - - This document defines only additional optional AVPs for usage - with the Diameter EAP application. This document does not - define a new Diameter application and therefore a new - Application ID is not required, as described in the Diameter - Base protocol . - - - In this document, when EAP re-authentication is performed in - the domain visited by the peer, it is assumed that the local ER - server is co-located with a Diameter agent in the visited - domain present in the path of the full EAP exchange. (Editor's - Note: it is not clear at the time of writing wether this - document must require this local AAA server to be on the path.) - - -
- -
- -
- - The Diameter EAP Application is used to transport ERP - messages between the NAS (authenticator) and an - authentication server (ER server). - - - In ERP, the peer sends an EAP-Initiate/Re-auth message to - the ER server via the authenticator. Alternatively, the NAS - may send an EAP-Initiate/Re-auth-Start message to the peer - to trigger the start of ERP. In this case, the peer responds with an - EAP-Initiate/Re-auth message to the NAS. - - The general guidelines for encapsulating EAP messages in - Diameter from RFC 4072 apply to - the new EAP codes defined for ERP as well. The - EAP-Initiate/Re-auth message is encapsulated in an - EAP-Payload AVP of a Diameter EAP Request (DER) message by the - NAS and sent to the Diameter server. The NAS MUST copy the - contents of the value field of the 'KeyName-NAI' TLV or - the 'peer-id' TLV (when the former is not present) of the EAP - Initiate/Re-auth message into a User-Name AVP of the - Diameter EAP-Request. - - - - - - The ER server processes the EAP-Initiate/Re-auth message in - accordance with and responds with - an EAP-Finish/Re-auth message. The Diameter server MUST - encapsulate the EAP-Finish/Re-auth message within an - EAP-Payload AVP of a Diameter EAP Answer message. In an - EAP re-authentication successful case, an - EAP-Master-Session-Key AVP is included in the Diameter EAP - Answer (DEA) message that contains the Re-authentication - Master Session Key (rMSK). The Diameter Result-Code SHOULD - be a success Result-Code. In an EAP re-authentication - failure case, the Diameter Result-Code AVP of the a - Diameter EAP Answer (DEA) message SHOULD be a failure - Result-Code and no EAP-Master-Session-Key AVP is present. - (Editor's Note: it is FFS if a SHOULD is sufficient) (2nd - Editor's Note: add a figure ?) - -
- -
- - A local ER server, collocated with a Diameter proxy in the - domain visited by the peer, may request a DSRK from the home EAP/ERP - server, either in the initial EAP exchange (implicit - bootstrapping) or in an ERP bootstrapping exchange - (explicit bootstrapping). This is done by including the - EAP-DSRK-Request AVP in the Diameter EAP Request (DER) message. - The EAP-DSRK-Request AVP contains the domain or server - identity required to derive the DSRK. - - - - In successful case, the DSRK is carried by the EAP-DSRK AVP - in the Diameter EAP Answer (DEA) message. Along with the - EAP-DSRK AVP, an EAP-DSRK-Name AVP MUST be used to send the - DSRK's keyname and an EAP-DSRK-Lifetime AVP MUST be used to - send the DSRK's lifetime. (Editor's Note: add a figure ?). - - -
-
- -
- - This document re-uses the EAP application commands and does not define new command - codes. - - - -
- - -
- - This section defines new AVPs for the ERP support within - Diameter EAP Application. - - -
- - The EAP-DSRK Request AVP (AVP Code TBD) is of type - DiameterIdentity. This AVP fulfills two purposes: first, it - indicates that a ERP server is located in the local domain - that is willing to play the role of an ERP server for a - particular session. Second, it conveys information about - the domain name to the - Diameter/EAP/ERP server. (Editor's Note: it is FFS if - DiameterIdentity is the correct type). - -
- -
- - The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. This - AVP contains keying material to be used by the visited - domain (i.e. the DSRK). Exactly how this keying material is - derived is beyond the scope of this document. - -
- -
- - The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. - This AVP contains the EMSKname which identifies the keying - material. How this name is derived is beyond the scope - of this document and defined in . - -
- -
- - The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type - Unsigned64 and contains the DSRK lifetime in - seconds. (Editor's Note: it is FFS if Unsigned32 is not - sufficient). (Editor's Note: it is FFS default value) - -
- -
- - - -
- - The following table lists the AVPs that may optionally be present in the DER and DEA - commands . - - -
- -
- - - When the EAP-DSRK AVP is present in the DEA then the - EAP-DSRK-Name and the EAP-DSRK-Lifetime MUST also be - present. - -
- -
- - The following table describes the Diameter AVPs, their AVP Code - values, types, possible flag values, and whether the AVP MAY be - encrypted. The Diameter base specifies - the AVP Flag rules for AVPs in Section 4.5. - - -
- -
- -
- - - -
- - The security considerations specified in RFC 4072 , and RFC 3588 - are applicable to this document. - - EAP channel bindings may be necessary to ensure that the - Diameter client and the server are in sync regarding the key - Requesting Entity's Identity. Specifically, the Requesting - Entity advertises its identity through the EAP lower layer, and - the user or the EAP peer communicates that identity to the EAP - server (and the EAP server communicates that identity to the - Diameter server) via the EAP method for user/peer to server - verification of the Requesting Entity's Identity. - -
- - - -
- - This document requires IANA registration of the following new AVPs to the AVP - registry established by RFC 3588 : - EAP-DSRK-Request - EAP-DSRK - EAP-DSRK-Name - EAP-DSRK-Lifetime - - - -
- -
- - Vidya Narayanan reviewed a rough draft version and found some - errors. Many thanks for her input. - -
- - - - - &rfc2119; &rfc3588; - &rfc4072; &rfc5296; - - &rfc3748; &rfc5295; - - - diff -r 6ac9daa8c775 -r 9d8dd59747f4 draft-ietf-dime-erp-06.xml --- a/draft-ietf-dime-erp-06.xml Mon Oct 25 17:07:09 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 6ac9daa8c775 -r 9d8dd59747f4 draft-ietf-dime-erp.xml --- a/draft-ietf-dime-erp.xml Mon Oct 25 17:07:09 2010 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,888 +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 - - 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" 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? - - - -
- - - - - &RFC2119; - &RFC3588; - &RFC4072; - &RFC5295; - &RFC5296; - &I-D.ietf-dime-local-keytran; - &RFC3748; - - - - &RFC5247; - - - diff -r 6ac9daa8c775 -r 9d8dd59747f4 draft-sdecugis-dime-diameter-erp.xml --- a/draft-sdecugis-dime-diameter-erp.xml Mon Oct 25 17:07:09 2010 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,796 +0,0 @@ - - - - - - - - - - - - - - - -]> - - - - - - - - - - - - - - - - - - Diameter support for EAP - Re-authentication Protocol (ERP) - - - NICT - -
- - 4-2-1 Nukui-Kitamachi - - Koganei, Tokyo - - 184-8795 - - JP - - - sdecugis@nict.go.jp -
- - - - - Operations & Management - - Diameter Maintenance and Extensions (DIME) - - Internet-Draft - - ERP - - Diameter - - Re-authentication - - - The EAP Re-authentication Protocol (ERP) provides a mechanism to - optimize EAP authentication delay in the case of re-authentication, - which can be significant in roaming mobile situation. This mechanism - assumes that a protocol for Authentication, Authorization and Accounting - (AAA) is available to transport ERP between the authenticator(s) and the - EAP/ERP server. draft-gaonkar-radext-erp-attrs-03 specifies the - transport of ERP using RADIUS. This document specifies the transport of - ERP using Diameter. - - - - -
- defines the EAP Re-authentication - Protocol (ERP) and mechanism that consists in the two following - 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: one-round-trip exchange between the peer and - the ER server, functionally equivalent to a full EAP - 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 Diameter EAP commands - (DER/DEA). - - 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 . - -
- This document differs from - in its design and scope. In this new version, we use a new Diameter - application id for messages with ERP payload exchanged between - authenticator and ER server. This simplifies the routing of Diameter - messages to the appropriate server, and allows more flexibility in the - deployment of ERP. - - The scope of previous documents ( and ) was focused on the - bootstrapping of the mechanism. In particular, these documents did not - consider the routing of Diameter message for re-authentication - exchanges (ERP exchange, and also for - the second document). By re-using the Diameter EAP application, they - create implicit constraints on routing of messages that cannot be met - by standard Diameter routing algorithm, as defined in the Diameter Base Protocol. - - A separate Diameter application solves this routing issue, and can - also allow the authenticator to dynamically discover if the local - domain supports re-authentication or not. -
-
- -
- We re-use in this document the terminology from . In particular, unless specified otherwise, the - EAP server has implicit support for ERP extensions for generation of ERP - keying material and its transmission to ER server. These terms - "authenticator", "ER server", "EAP server" designate logical functional - entities and make no assumption on the real implementation and - deployment. - - "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 re-use also some terminology and abbreviations from , for example DER/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 . -
-
- -
- During the lifetime of an EMSK (derived during a full EAP - authentication by compatible EAP methods), 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, so it can - be used in case of multihoming or handovers between different access - technologies. 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 home EAP server is assumed to be - constant for a given peer. - -
- |Authenticator|<=======>| ER server | <---> | EAP | - +-------------+ +-----------+ | server | - +--------+ - (*) Several protocols can be used between ER server and - home EAP server to transport bootstrapping material. -]]> -
- - 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). Can the ER server be located in a - third domain (ex: broker's)? - - 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 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. - -
- - 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. - - The content of this section is to be written, - I am just listing the ideas here. - - See guidelines in . - - 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? It would - involve: - An additional AVP during bootstrapping of ER server, in the - ERP-RK-Answer, to pass the real User-Name and Session-Id (only in - case of explicit bootstrapping) - - An additional AVP in Diameter ERP/DEA (EAP-Finish/Re-Auth) to - pass the real Session-Id and User-Name and Destination-Realm of the - re-authenticated peer, for accounting messages. - -
- -
- Hannes Tschofenig, Lakshminath Dondeti, Julien Bournelle, and Lionel - Morand wrote the initial Diameter ERP draft document. -
- -
- Vidya Narayanan reviewed a rough draft version of the previous - document and found some errors. - - Qin Wu and Glen Zorn actively participated in the discussions on the - design for Diameter ERP, providing the point of view and experience from - HOKEY workgroup. - - Hannes Tschofenig provided useful advices for the writing of this - 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 created by in . - -
- -
-
- -
- This specification requires IANA to allocate new values from the - "AVP Codes" registry defined in for the - following AVPs: - ERP-RK-Request - - ERP-Realm - - ERP-RK-Answer - - ERP-RK - - ERP-RK-Name - - ERP-RK-Lifetime - These AVPs are defined in section . -
-
- -
- The security considerations from the following RFC apply here: , , , , and . - - FFS: 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? -
- - - - - &RFC2119; - - &RFC3588; - - &RFC4072; - - &RFC5295; - - &RFC5296; - - - - &RFC3748; - - &RFC4187; - - &RFC5247; - - &I-D.ietf-hokey-key-mgm; - - &I-D.gaonkar-radext-erp-attrs; - - &I-D.ietf-dime-erp; - - &I-D.wu-dime-local-keytran; - - &I-D.ietf-dime-app-design-guide; - - - diff -r 6ac9daa8c775 -r 9d8dd59747f4 peer and authenticator.txt --- a/peer and authenticator.txt Mon Oct 25 17:07:09 2010 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,208 +0,0 @@ -Interoperability and deployment issues for Diameter ERP. -Author: s.decugis - -I - Peer and authenticator considerations. - -This draft document considers all possible situations between the peer and the authenticator, -with regards to ERP and feature supported on each entity. -It is based on my understanding of ERP mechanism, which is not complete, so if you see big mistakes -please let me know. -In the first section, I detail the different situations that can occur for interoperability issues. -In the second section, I explain the sequence of events that are expected to occur in the different -combinations of situations. -In the third section, I give my views on what needs to be changed in the design so that some of the -problems detailed here will be avoided. -A separate document will be written later for: II - The backend considerations (interactions between ERP and EAP) - - -1. The variables. - -1.1. Peer. - -a. ERP support. - -The peer may or may not support the ERP feature. -Support means being able to derive a rRK and rIK material from a EMSK, -or from a DSRK derived from the EMSK and local domain name. -Support means also ability to send and receive ERP messages (new EAP codes). - -Notation: -A1 = The peer supports ERP feature. -A2 = The peer does not support these features. - - -b. Availability of keying material. - -When the peer supports the ERP feature, it must also have available -keying material, i.e. valid EMSK, to use the feature. - -Notation: -B1 = The peer has a valid EMSK from a previous EAP authentication. -B2 = The peer doesn't have such material available. - - -1.2. Authenticator. - -a. ERP support. - -An authenticator that does not support ERP feature is supposed to drop all -ERP packets. The support of ERP feature means that the authenticator is able -to extract the keyName-NAI from ERP message to help routing the Diameter message. - -In some cases, the authenticator may also understand ERP messages but have determined -that no backend is available (configuration, capability exchange, other...) to perform -ERP operations and therefore simply reply errors to ERP messages from the peer. The -benefit of this situation is that the peer does not have to retransmit and timeout the -ERP messages. On a functional point of view, this is equivalent to the case where the -peer does not support ERP. - -Notation: -C1 = The authenticator supports ERP features. -C2 = The authenticator does not support ERP features or always sends Failure error codes. - - -b. Local domain name publication. - -With some lower layers, the local domain name can be advertized to the peer -during discovery phase, while some other LL do not allow this. - -It is always possible to advertise the local domain name in the EAP-Initiate/Re-auth-Start -packet as a TLV, but the peer may initiate EAP-Initiate/Re-auth exchange previously to receiving -the packet. Both situation have the same effect (peer not knowing the local domain name). - -We must consider both situations. - -Notation: -D1 = The authenticator advertises the local domain name through the LL or Re-Auth-Start ERP message -D2 = The peer does not receive this name. - - - -2. Sequence of events. - -This section is an attempt to describe the sequence of events that will occur when -a peer attaches to a new authenticator, in order to highlight the requirements and -possible issues for the ERP backend. - -Reminder: the first step is the discovery phase. During this phase, the peer and authenticator -may exchange information such as: ERP support, local domain name, who will start the exchange, ... -Then the EAP or ERP exchange occurs. It may take several echanges of messages. When -terminated, either the (re)authentication fails, or keying material (r)MSK is available to both -the peer and the authenticator. In the later case, a Security Association Protocol is initiated -and uses the keying material to establish a protected connection to the network for the peer. - -The following cases are considered in this section: - --- authenticator --- - | C1 | C2 | - | D1 | D2 | D1/D2 | - |---------------------------| - | A1 B1 | 1 | 2 | | - p-----------------| 5 | - e A1 B2 | 3 | | - e---------------------------| - r A2 | 4 | - | B1/B2 | | - |---------------------------- - - -2.1. A1, B1, C1, D1 - all conditions OK for ERP. - -The peer receives the domain name from the new authenticator, and has a valid EMSK available. -It may also receive a EAP-Initiate/Re-auth-Start packet from the authenticator. If domain name -was not received during discovery phase, the peer should wait for the EAP-Initiate/Re-auth-Start -message to check if it contains the domain name. - -Thanks to the domain name received from the authenticator, the peer can determine -if it is attaching to its home domain or a foreign domain. - -The peer must determine whether to start a bootstrapping ERP exchange or a normal ERP exchange. - -In the case where the peer is in its home domain, bootstrapping or normal exchanges are equivalent. -(which one should be started?) - -In the case where the peer is in a visited domain, a normal exchange will succeed only if the local -ER server possesses the DSRK material corresponding to the EMSK for this session of this peer. -This happens when: -- a previous ERP bootstrapping exchange already occurred in this domain. -- a full EAP authentication occurred in this domain, and implicit bootstrapping was used - (how does the peer know???) -- Alternatively, is it possible for the local ER server to request material from home ER server - if it does not have the required DSRK? - -If the peer determines that a bootstrapping exchange is started, it uses the rIK derived from the EMSK to -protect the ERP message, and the keyName-NAI is EMSKname@homedomain. The local ER server adds a -ERP-DSRK-Request AVP while forwarding to the home ER server. The home ER server answers and adds the DSRK -(for the local ER server), the DS-rMSK (for the authenticator) and the domain name in the ERP message for the peer. -The peer uses this domain name to compute DSRK, DS-rRK and DS-rMSK. - -If one of the conditions listed previously is matched, the peer may start a normal ERP exchange. In that case, -the keyName-NAI is EMSKname@localdomain. The message is protected by the DS-rIK. The local ER server receives this -request and provides a DS-rMSK to the authenticator. - - -2.2. A1, B1, C1, D2 - The peer does not receive the local domain name. - -In this case, the peer will start an exchange with its home server. It may (should?) include the 'B' flag -(indicating bootstrapping exchange) to discover the local domain name if any. - - -2.3. A1, B2, C1 - No valid EMSK available to the peer. - -In this case, a full EAP authentication is started. If the peer receives a EAP-Initiate/Re-auth-Start -from the authenticator, it ignores it and waits for a Request/Identity (how to avoid this -delay ??? not clear in ERP document). - -In the case where local domain name is received (D1), the peer can assume that this local domain -have a DSRK available for further re-authentication, making the assumption that ERP implicit bootstrapping was used. - -What if no local ER server is available? The authenticator must not advertise the local domain? - - -2.4. A2 - The peer does not support ERP. - -In that case, the peer drops EAP-Initiate/Re-auth-Start packet if any and always uses full EAP authentication. -Initiating ERP implicit bootstrapping in that case is just a waste of computational power (and energy) -on the ER local and home servers. - -It is not important to know what features are supported by the authenticator in that case. - -FFS: how to avoid implicit bootstrapping in that case? (to be "green") - - -2.5. A1, C2 - Authenticator (or backend) does not support ERP. - -Any ERP message from the peer will be dropped or answered with failure code by the authenticator. -As a result the peer's EAP-Initiate/Re-auth will fail and the peer should fall back to using -full EAP authentication. - -If there is a local ER server, it may start implicit bootstrapping. Note that it will re-do -implicit bootstrapping everytime the peer re-authenticates, using full EAP authentication each time. - -We have the same problem as in 2.3, the peer can not know when no local ER server is available, and therefore -can not rely on implicit bootstrapping without more information. - - - -3. Conclusion. - -My conclusions with regards to the considerations from this document are as follow: - -- The peer should always wait for first message from the authenticator if it does not receive domain name from LL, -and the authenticator should always send a EAP-Initiate/Re-auth-Start message with domain-name TLV. - -Pro: no dependency on lower layer to provide local domain name to the peer -Pro: reduces the number of possible situations to handle on the peer and authenticator. - - -- The peer must choose between initiating normal or bootstrapping ERP exchange. We restrict normal exchanges -to occur only after previous bootstrapping exchange in the same domain, that resulted in reception -of the domain name (proof that the home ER server has sent the DSRK to a local ER server) i.e. we do never rely -on implicit bootstrapping. - -Pro: the peer can decide whether to do normal or bootstrapping ERP. -Pro: no useless key derivation computation. -Pro: allow to use different Diameter Application ID for ERP, elimitating all current constraints on Diameter routing (FFS). -Pro: allow more flexibility in deployment scenario. -Con: need to re-design the Diameter ERP almost from scratch (but currently it can't work anyway...) -Con: one additional round-trip with home domain in the worst case. -