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

+ + 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 (a.k.a. ERP, RFC5296) 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. + + + + This document differs from draft-ietf-dime-erp-00 + 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 (draft-ietf-dime-erp-00 + and draft-wu-dime-local-keytran-00) + was focused on the implicit bootstrapping scenario described in . By re-using the Diameter EAP application, + these documents create constraining requirements on routing of Diameter + messages, that cannot be met by standard Diameter routing algorithm + defined in the Diameter Base Protocol. + They also introduce interoperability problems for the peer and the NAS + that cannot be overcome easily. + + + + 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 . + + + + +

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

+ +

+ We re-use here the terminology from . + In particular, the term "EAP server" refers to a server for EAP with + sufficient extensions for ERP to create ERP keying material. + + "root key" or "bootstrapping material" refer to the rRK (for ER + server in home domain) or the rDSRK (ER server in separate domain), + depending on the context. +

+ +

+ The following figure shows the components involved in ERP, and their + interactions. During the lifetime of the EMSK derived from a full EAP + authentication, a peer may attach to several authenticators, and + eventually use different ER servers (for example in inter-domain + roaming). + +

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

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

+ +

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

+ +

+ This memo includes no request to IANA. + + (It's good - indeed pretty much mandatory now - to have an explicit + note because otherwise IANA wastes cycles trying to figure out if + something is needed..) +

+ +

+ Remember to consider security from the start.. and all drafts are + required to have a security considerations section before they will pass + the IESG. +

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

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

+ + + + + General + + keyword + + + In many standards track documents several words are used to + signify the requirements in the specification. These words are + often capitalized. This document defines these words as they + should be interpreted in IETF documents. Authors who follow these + guidelines should incorporate this phrase near the beginning of + their document: + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", + "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described + in RFC 2119. + + + Note that the force of these words is modified by the + requirement level of the document in which they are used. + + + + + + + + + + + + + + + &RFC3588; + + &RFC4005; + + &RFC5295; + + &RFC5296; + + + + &I-D.draft-ietf-hokey-key-mgm; + + +

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

+ +