Mercurial > hg > ietf
changeset 58:6ac9daa8c775
Version -05 submitted, prepared for next one.
| author | Sebastien Decugis <sdecugis@nict.go.jp> |
|---|---|
| date | Mon, 25 Oct 2010 17:07:09 +0900 |
| parents | b2ed5f2fcd30 |
| children | 9d8dd59747f4 |
| files | draft-ietf-dime-erp-05.xml draft-ietf-dime-erp-06.xml |
| diffstat | 2 files changed, 723 insertions(+), 723 deletions(-) [+] |
line wrap: on
line diff
--- a/draft-ietf-dime-erp-05.xml Fri Oct 22 15:55:24 2010 +0900 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,723 +0,0 @@ -<?xml version="1.0" encoding="US-ASCII"?> -<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ -<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> -<!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml"> -<!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml"> -<!ENTITY RFC4072 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml"> -<!ENTITY RFC5247 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml"> -<!ENTITY RFC5295 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml"> -<!ENTITY RFC5296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml"> -<!ENTITY I-D.ietf-dime-local-keytran SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-local-keytran-08.xml"> -]> -<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> -<?rfc strict="yes"?> -<?rfc comments="no"?> -<?rfc inline="yes"?> -<?rfc editing="no"?> -<?rfc toc="yes"?> -<?rfc tocompact="yes"?> -<?rfc tocdepth="3"?> -<?rfc symrefs="yes"?> -<?rfc sortrefs="yes"?> -<?rfc compact="yes"?> -<?rfc subcompact="no"?> -<?rfc rfcedstyle="yes"?> -<?rfc rfcprocack="no"?> -<?rfc tocindent="yes"?> -<rfc category="std" docName="draft-ietf-dime-erp-05.txt" ipr="trust200902"> - <front> - <title abbrev="Diameter ERP Application">Diameter Support for the EAP - Re-authentication Protocol (ERP)</title> - - <author fullname="Julien Bournelle" initials="J." surname="Bournelle"> - <organization abbrev="Orange Labs">Orange Labs</organization> - - <address> - <postal> - <street>38-40 rue du general Leclerc</street> - - <city>Issy-Les-Moulineaux</city> - - <code>92794</code> - - <country>France</country> - </postal> - - <email>julien.bournelle@orange-ftgroup.com</email> - </address> - </author> - - <author fullname="Lionel Morand" initials="L." surname="Morand"> - <organization abbrev="Orange Labs">Orange Labs</organization> - - <address> - <postal> - <street>38-40 rue du general Leclerc</street> - - <city>Issy-Les-Moulineaux</city> - - <code>92794</code> - - <country>France</country> - </postal> - - <email>lionel.morand@orange-ftgroup.com</email> - </address> - </author> - - <author fullname="Sebastien Decugis" initials="S." role="editor" - surname="Decugis"> - <organization abbrev="NICT">NICT</organization> - - <address> - <postal> - <street>4-2-1 Nukui-Kitamachi</street> - - <city>Tokyo</city> - - <code>184-8795</code> - - <country>Koganei, Japan</country> - </postal> - - <email>sdecugis@nict.go.jp</email> - </address> - </author> - - <author fullname="Qin Wu" initials="Q." surname="Wu"> - <organization abbrev="Huawei">Huawei Technologies Co., - Ltd</organization> - - <address> - <postal> - <street>Site B, Floor 12F, Huihong Mansion, No.91 Baixia - Rd.</street> - - <city>Nanjing</city> - - <code>210001</code> - - <country>China</country> - </postal> - - <email>sunseawq@huawei.com</email> - </address> - </author> - - <author fullname="Glen Zorn" initials="G." role="editor" surname="Zorn"> - <organization>Network Zen</organization> - - <address> - <postal> - <street>1463 East Republican Street</street> - - <city>Seattle</city> - - <region>Washington</region> - - <code>98112</code> - - <country>USA</country> - </postal> - - <phone>+1 206 931 0768</phone> - - <email>gwz@net-zen.net</email> - </address> - </author> - - <date year="2010" /> - - <area>Operations & Management</area> - - <keyword>Internet-Draft</keyword> - - <keyword>EAP</keyword> - - <keyword>Diameter</keyword> - - <keyword>Re-authentication</keyword> - - <keyword>AAA</keyword> - - <keyword>inter-authenticator roaming</keyword> - - <abstract> - <t>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.</t> - </abstract> - </front> - - <middle> - <section anchor="Introduction" title="Introduction"> - <t><xref target="RFC5296">RFC 5296</xref> defines the EAP - Re-authentication Protocol (ERP). It consists of the following steps: - <list style="hanging"> - <t hangText="Bootstrapping"><vspace blankLines="0" /> A root key for - re-authentication is derived from the Extended Master Session Key - (EMSK) created during EAP authentication <xref - target="RFC5295"></xref>. This root key is transported from the EAP - server to the ER server.</t> - - <t hangText="Re-authentication"><vspace blankLines="0" /> 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.</t> - </list> 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). <vspace blankLines="1" /> 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 <xref target="RFC5295">RFC - 5295</xref>.</t> - </section> - - <section title="Terminology"> - <t>This document uses terminology defined in <xref target="RFC3748">RFC - 3748</xref>, <xref target="RFC5295">RFC 5295</xref>, <xref - target="RFC5296">RFC 5296</xref>, and <xref target="RFC4072">RFC - 4072</xref>. <vspace blankLines="1" /> "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. <vspace - blankLines="1" /> 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" <xref - target="IANA_AppId"></xref>; the same commands are denoted "EAP/DER" and - "EAP/DEA" when the Application Id in the message is set to "Diameter EAP - Application" <xref target="RFC4072"></xref>.</t> - - <section title="Requirements Language"> - <t>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 <xref - target="RFC2119"></xref>.</t> - </section> - </section> - - <section title="Assumptions"> - <t>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.</t> - </section> - - <section anchor="Overview" title="Protocol Overview"> - <t>The following figure shows the components involved in ERP, and their - interactions. <figure align="center" anchor="Fig-Overview" - title="Diameter ERP Overview"> - <artwork><![CDATA[ - Diameter +--------+ - +-------------+ ERP +-----------+ (*) | Home | -Peer <->|Authenticator|<=======>| ER server | <---> | EAP | - +-------------+ +-----------+ | server | - +--------+ -(*) Diameter EAP application, explicit bootstrapping scenario only. -]]></artwork> - </figure> 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). <vspace blankLines="1" /> When the peer - initiates an ERP exchange, the authenticator creates a - Diameter-EAP-Request message <xref target="RFC4072"></xref>. 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 <xref target="Re-authentication"></xref>. <vspace - blankLines="1" /> 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. <vspace blankLines="1" /> 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 <xref target="RFC5296">RFC - 5296</xref>, 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. <vspace - blankLines="1" /> 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 <xref target="RFC3588"></xref> - 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. <vspace blankLines="1" /> 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 <xref - target="RFC5296">RFC 5296</xref> then creates the ERP/DEA answer as - described in <xref target="Re-authentication"></xref>. The rMSK is - included in this answer. <vspace blankLines="1" /> Finally, the - authenticator extracts the rMSK from the ERP/DEA as described in <xref - target="RFC5296">RFC 5296</xref>, and forwards the content of the - EAP-Payload AVP, the EAP-Finish/Re-Auth message, to the peer. <vspace - blankLines="1" /> 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 <xref target="Bootstrapping"></xref> for more - detail on this process.</t> - </section> - - <section anchor="Bootstrapping" title="Bootstrapping the ER Server"> - <t>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. <vspace blankLines="1" /> 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.</t> - - <section title="Bootstrapping During the Initial EAP authentication"> - <t>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. <vspace blankLines="1" /> 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. <figure align="center" anchor="Implict" - title="ERP Bootstrapping During Full EAP Authentication"> - <artwork><![CDATA[ - ER server & -Authenticator EAP Proxy 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) - (Key AVP (rRK)) - <------------------------- - Diameter EAP/DEA - (EAP-Success) - (MSK) - [ ERP-Realm ] -]]></artwork> - </figure> 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. <vspace - blankLines="1" /> If the EAP server does not support the ERP - extensions, it simply ignores the ERP-RK-Request AVP and continues as - specified in <xref target="RFC4072">RFC 4072</xref>. 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 <xref target="RFC5296">RFC 5296</xref>, using the - saved domain name. It then includes the rRK inside a Key AVP <xref - target="KAVP"></xref> with the Key-Type AVP set to rRK, before sending - the DEA as usual.<vspace blankLines="1" /> 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 <xref target="KAVP"></xref> 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. <vspace blankLines="1" /> 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.</t> - </section> - - <section title="Bootstrapping During the First Re-authentication"> - <t>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. <vspace - blankLines="1" /> 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: <list> - <t>Changes the Application Id in the header of the message to - Diameter EAP Application (code 5).</t> - - <t>Change the content of Application-Auth-Id accordingly. <list - style="hanging"> - <t hangText="QUESTION:"><vspace blankLines="0" /> Is it better - to leave it unmodified, so that the server can easily - differenciate between ERP and standard EAP message ?</t> - </list></t> - - <t>Add the ERP-RK-Request AVP, which contains the name of the - domain where the ER server is located.</t> - - <t><list style="hanging"> - <t hangText="PROBLEM:"><vspace blankLines="0" /> 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?</t> - </list></t> - </list> Then the proxied EAP/DER request is sent and routed to the - home Diameter EAP server. <vspace blankLines="1" /> 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 <xref - target="RFC5296"></xref>. In particular, it includes the Domain-Name - TLV attribute with the content from the ERP-Realm AVP. It creates the - EAP/DEA reply message <xref target="RFC4072"></xref>. including an - instance of the Key AVP <xref target="KAVP"></xref> with Key-Type AVP - set to rRK. <vspace blankLines="1" /> The ER server receives this - EAP/DEA and proxies it as follows, in addition to standard proxy - operations: <list> - <t>Set the Application Id back to Diameter ERP application Id - (code TBD)</t> - - <t>Extract and cache the content of the Key AVP with Key-Type set - to rRK, as described in implicit scenario.</t> - </list> The ERP/DEA message is then forwarded to the authenticator, - that can use the rMSK as described in <xref target="RFC5296">RFC - 5296</xref>. <vspace blankLines="1" /> The figure below captures this - proxy behavior: <figure align="center" anchor="FigExplicit" - title="ERP Explicit Bootstrapping Message Flow"> - <artwork><![CDATA[ -Authenticator ER server Home EAP server -============= ========= =============== - -----------------------> - 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)) -]]></artwork> - </figure></t> - </section> - </section> - - <section anchor="Re-authentication" title="Re-Authentication"> - <t>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. <figure align="center" - anchor="FigReauth" title="Diameter ERP Re-authentication Exchange"> - <artwork><![CDATA[ - ER server - Peer Authenticator (bootstrapped) - ==== ============= ====================== - [ <------------------------ ] - [optional EAP-Initiate/Re-auth-start,] - [ possibly with ERP domain name ] - - -----------------------> - 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 -]]></artwork> - </figure> 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. <vspace blankLines="1" /> If the authenticator does not support - ERP (pure <xref target="RFC4072">Diameter EAP</xref> 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. <vspace blankLines="1" /> When the authenticator receives an - EAP-Initiate/Re-auth message from the peer, it processes as described in - <xref target="RFC5296"></xref> with regards to the EAP state machine. It - creates a Diameter EAP Request message following the general process of - <xref target="RFC4072">Diameter EAP</xref>, with the following - differences: <list> - <t>The Application Id in the header is set to Diameter ERP (code - TBD).</t> - - <t>The value in Auth-Application-Id AVP is also set to Diameter ERP - Application.</t> - - <t>The keyName-NAI attribute from ERP message is used to create the - content of User-Name AVP and Destination-Realm AVP.</t> - - <t><list style="hanging"> - <t hangText="FFS:"><vspace blankLines="0" /> What about - Session-ID AVP ?</t> - </list></t> - - <t>The Auth-Request-Type AVP content is set to [Editor's note: FFS - -- cf. open issues].</t> - - <t>The EAP-Payload AVP contains the EAP-Initiate/Re-Auth - message.</t> - </list> Then this ERP/DER message is sent as described in <xref - target="Overview"></xref>. <vspace blankLines="1" /> The ER server - receives and processes this request as described in <xref - target="Overview"></xref>. It then creates an ERP/DEA message following - the general processing described in <xref target="RFC4072">RFC - 4072</xref>, with the following differences: <list> - <t>The Application Id in the header is set to Diameter ERP (code - TBD).</t> - - <t>The value of the Auth-Application-Id AVP is also set to Diameter - ERP Application.</t> - - <t>The EAP-Payload AVP contains the EAP-Finish/Re-auth message.</t> - - <t>In case of successful authentication, an instance of the Key AVP - containing the Re-authentication Master Session Key (rMSK) derived - by ERP is included.</t> - </list> When the authenticator receives this ERP/DEA answer, it - processes it as described in <xref target="RFC4072">Diameter EAP</xref> - and <xref target="RFC5296">RFC 5296</xref>: the content of EAP-Payload - AVP content is forwarded to the peer, and the contents of the - Keying-Material AVP <xref target="I-D.ietf-dime-local-keytran"></xref> - is used as a shared secret for Secure Association Protocol.</t> - </section> - - <section anchor="ApplicationId" title="Application Id"> - <t>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 <xref target="RFC3588"></xref>. - <vspace blankLines="1" /> 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 <xref target="AVPs"></xref>, although these AVP have - the 'M' flag cleared.</t> - </section> - - <section anchor="AVPs" title="AVPs"> - <t>This section discusses the AVPs used by the Diameter ERP - application.</t> - - <section title="ERP-RK-Request AVP"> - <t>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. <vspace blankLines="1" /> This AVP - has the M and V bits cleared. <figure align="center" anchor="ERRABNF" - title="ERP-RK-Request ABNF"> - <artwork><![CDATA[ - ERP-RK-Request ::= < AVP Header: TBD > - { ERP-Realm } - * [ AVP ] -]]></artwork> - </figure></t> - </section> - - <section title="ERP-Realm AVP"> - <t>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. - <vspace blankLines="1" /> This AVP has the M and V bits cleared.</t> - </section> - - <section anchor="KAVP" title="Key AVP"> - <t>The Key AVP <xref target="I-D.ietf-dime-local-keytran"></xref> 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.</t> - - <section title="Key-Type AVP"> - <t>The value of the Key-Type AVP MUST be set to 2 for rRK or 3 for - rMSK.</t> - </section> - - <section title="Keying-Material AVP"> - <t>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 <xref - target="RFC5296">RFC 5296</xref>.</t> - </section> - - <section title="Key-Name AVP"> - <t>This AVP contains the EMSKname which identifies the keying - material. The derivation of this name is specified in <xref - target="RFC5296">RGC 5296</xref>.</t> - </section> - - <section title="Key-Lifetime AVP"> - <t>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.</t> - </section> - </section> - </section> - - <section anchor="Issues" title="Open issues"> - <t>This document does not address some known issues in Diameter ERP - mechanism. The authors would like to hear ideas about how to address - them. <vspace blankLines="1" /> 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:<list> - <t>how to manage the Session-Id AVP -- is it a new session each - time, or do we try to reuse the same Diameter session?;</t> - - <t>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?)</t> - - <t>how does the peer learn the ERP domain of the new authenticator - -- this is being addressed in HOKEY architecture draft;</t> - - <t>how does the home server reachs the peer to for example terminate - the session if there is no notification sent to the home domain;</t> - </list><vspace blankLines="1" /> 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. <vspace blankLines="1" />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.<vspace blankLines="1" /> Finally, - this document currently lacks a description of what happens when a - Re-Auth-Request is received for a peer on the authenticator.</t> - </section> - - <section anchor="Acknowledgements" title="Acknowledgements"> - <t>Hannes Tschofenig wrote the initial draft for this document and - provided useful reviews. <vspace blankLines="1" /> Vidya Narayanan - reviewed a rough draft version of the document and found some errors. - <vspace blankLines="1" /> Lakshminath Dondeti contributed to the early - versions of the document. <vspace blankLines="1" /> Many thanks to these - people!</t> - </section> - - <section anchor="IANA" title="IANA Considerations"> - <t>This document requires IANA registration of the following new - elements in the <eref - target="http://www.iana.org/assignments/aaa-parameters/">Authentication, - Authorization, and Accounting (AAA) Parameters</eref> registries.</t> - - <section anchor="IANA_AppId" title="Diameter Application Identifier"> - <t>This specification requires IANA to allocate a new value "Diameter - ERP" in the "Application IDs" registry <xref target="RFC3588"> using - the policy specified in Section 11.3 of RFC 3588</xref>.</t> - </section> - - <section anchor="IANA_AVP" title="New AVPs"> - <t>This specification requires IANA to allocate new values from the - "AVP Codes" registry <xref target="RFC3588">according to the policy - specified in Section 11.1 of RFC 3588</xref> for the following AVPs: - <list> - <t>ERP-RK-Request</t> - - <t>ERP-Realm</t> - </list>These AVPs are defined in <xref target="AVPs"></xref>.</t> - </section> - </section> - - <section anchor="Security" title="Security Considerations"> - <t>The security considerations from the following documents also apply - here: <list style="symbols"> - <t><xref target="RFC3588">RFC 3588</xref></t> - - <t><xref target="RFC4072">RFC 4072</xref></t> - - <t><xref target="RFC5247">RFC 5247</xref></t> - - <t><xref target="RFC5295">RFC 5295</xref></t> - - <t><xref target="RFC5296"></xref></t> - </list> <list style="hanging"> - <t hangText="FFS:"><vspace blankLines="0" /> 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?</t> - </list> 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. <list style="hanging"> - <t hangText="QUESTION:"><vspace blankLines="0" /> What does this - paragraph actually mean?</t> - </list></t> - </section> - </middle> - - <back> - <references title="Normative References"> - &RFC2119; - - &RFC3588; - - &RFC4072; - - &RFC5295; - - &RFC5296; - - &I-D.ietf-dime-local-keytran; - - &RFC3748; - </references> - - <references title="Informative References"> - &RFC5247; - </references> - </back> -</rfc>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/draft-ietf-dime-erp-06.xml Mon Oct 25 17:07:09 2010 +0900 @@ -0,0 +1,723 @@ +<?xml version="1.0" encoding="US-ASCII"?> +<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ +<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> +<!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml"> +<!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml"> +<!ENTITY RFC4072 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml"> +<!ENTITY RFC5247 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml"> +<!ENTITY RFC5295 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml"> +<!ENTITY RFC5296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml"> +<!ENTITY I-D.ietf-dime-local-keytran SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-local-keytran-08.xml"> +]> +<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> +<?rfc strict="yes"?> +<?rfc comments="no"?> +<?rfc inline="yes"?> +<?rfc editing="no"?> +<?rfc toc="yes"?> +<?rfc tocompact="yes"?> +<?rfc tocdepth="3"?> +<?rfc symrefs="yes"?> +<?rfc sortrefs="yes"?> +<?rfc compact="yes"?> +<?rfc subcompact="no"?> +<?rfc rfcedstyle="yes"?> +<?rfc rfcprocack="no"?> +<?rfc tocindent="yes"?> +<rfc category="std" docName="draft-ietf-dime-erp-06.txt" ipr="trust200902"> + <front> + <title abbrev="Diameter ERP Application">Diameter Support for the EAP + Re-authentication Protocol (ERP)</title> + + <author fullname="Julien Bournelle" initials="J." surname="Bournelle"> + <organization abbrev="Orange Labs">Orange Labs</organization> + + <address> + <postal> + <street>38-40 rue du general Leclerc</street> + + <city>Issy-Les-Moulineaux</city> + + <code>92794</code> + + <country>France</country> + </postal> + + <email>julien.bournelle@orange-ftgroup.com</email> + </address> + </author> + + <author fullname="Lionel Morand" initials="L." surname="Morand"> + <organization abbrev="Orange Labs">Orange Labs</organization> + + <address> + <postal> + <street>38-40 rue du general Leclerc</street> + + <city>Issy-Les-Moulineaux</city> + + <code>92794</code> + + <country>France</country> + </postal> + + <email>lionel.morand@orange-ftgroup.com</email> + </address> + </author> + + <author fullname="Sebastien Decugis" initials="S." role="editor" + surname="Decugis"> + <organization abbrev="NICT">NICT</organization> + + <address> + <postal> + <street>4-2-1 Nukui-Kitamachi</street> + + <city>Tokyo</city> + + <code>184-8795</code> + + <country>Koganei, Japan</country> + </postal> + + <email>sdecugis@nict.go.jp</email> + </address> + </author> + + <author fullname="Qin Wu" initials="Q." surname="Wu"> + <organization abbrev="Huawei">Huawei Technologies Co., + Ltd</organization> + + <address> + <postal> + <street>Site B, Floor 12F, Huihong Mansion, No.91 Baixia + Rd.</street> + + <city>Nanjing</city> + + <code>210001</code> + + <country>China</country> + </postal> + + <email>sunseawq@huawei.com</email> + </address> + </author> + + <author fullname="Glen Zorn" initials="G." role="editor" surname="Zorn"> + <organization>Network Zen</organization> + + <address> + <postal> + <street>1463 East Republican Street</street> + + <city>Seattle</city> + + <region>Washington</region> + + <code>98112</code> + + <country>USA</country> + </postal> + + <phone>+1 206 931 0768</phone> + + <email>gwz@net-zen.net</email> + </address> + </author> + + <date year="2010" /> + + <area>Operations & Management</area> + + <keyword>Internet-Draft</keyword> + + <keyword>EAP</keyword> + + <keyword>Diameter</keyword> + + <keyword>Re-authentication</keyword> + + <keyword>AAA</keyword> + + <keyword>inter-authenticator roaming</keyword> + + <abstract> + <t>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.</t> + </abstract> + </front> + + <middle> + <section anchor="Introduction" title="Introduction"> + <t><xref target="RFC5296">RFC 5296</xref> defines the EAP + Re-authentication Protocol (ERP). It consists of the following steps: + <list style="hanging"> + <t hangText="Bootstrapping"><vspace blankLines="0" /> A root key for + re-authentication is derived from the Extended Master Session Key + (EMSK) created during EAP authentication <xref + target="RFC5295"></xref>. This root key is transported from the EAP + server to the ER server.</t> + + <t hangText="Re-authentication"><vspace blankLines="0" /> 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.</t> + </list> 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). <vspace blankLines="1" /> 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 <xref target="RFC5295">RFC + 5295</xref>.</t> + </section> + + <section title="Terminology"> + <t>This document uses terminology defined in <xref target="RFC3748">RFC + 3748</xref>, <xref target="RFC5295">RFC 5295</xref>, <xref + target="RFC5296">RFC 5296</xref>, and <xref target="RFC4072">RFC + 4072</xref>. <vspace blankLines="1" /> "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. <vspace + blankLines="1" /> 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" <xref + target="IANA_AppId"></xref>; the same commands are denoted "EAP/DER" and + "EAP/DEA" when the Application Id in the message is set to "Diameter EAP + Application" <xref target="RFC4072"></xref>.</t> + + <section title="Requirements Language"> + <t>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 <xref + target="RFC2119"></xref>.</t> + </section> + </section> + + <section title="Assumptions"> + <t>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.</t> + </section> + + <section anchor="Overview" title="Protocol Overview"> + <t>The following figure shows the components involved in ERP, and their + interactions. <figure align="center" anchor="Fig-Overview" + title="Diameter ERP Overview"> + <artwork><![CDATA[ + Diameter +--------+ + +-------------+ ERP +-----------+ (*) | Home | +Peer <->|Authenticator|<=======>| ER server | <---> | EAP | + +-------------+ +-----------+ | server | + +--------+ +(*) Diameter EAP application, explicit bootstrapping scenario only. +]]></artwork> + </figure> 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). <vspace blankLines="1" /> When the peer + initiates an ERP exchange, the authenticator creates a + Diameter-EAP-Request message <xref target="RFC4072"></xref>. 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 <xref target="Re-authentication"></xref>. <vspace + blankLines="1" /> 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. <vspace blankLines="1" /> 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 <xref target="RFC5296">RFC + 5296</xref>, 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. <vspace + blankLines="1" /> 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 <xref target="RFC3588"></xref> + 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. <vspace blankLines="1" /> 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 <xref + target="RFC5296">RFC 5296</xref> then creates the ERP/DEA answer as + described in <xref target="Re-authentication"></xref>. The rMSK is + included in this answer. <vspace blankLines="1" /> Finally, the + authenticator extracts the rMSK from the ERP/DEA as described in <xref + target="RFC5296">RFC 5296</xref>, and forwards the content of the + EAP-Payload AVP, the EAP-Finish/Re-Auth message, to the peer. <vspace + blankLines="1" /> 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 <xref target="Bootstrapping"></xref> for more + detail on this process.</t> + </section> + + <section anchor="Bootstrapping" title="Bootstrapping the ER Server"> + <t>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. <vspace blankLines="1" /> 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.</t> + + <section title="Bootstrapping During the Initial EAP authentication"> + <t>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. <vspace blankLines="1" /> 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. <figure align="center" anchor="Implict" + title="ERP Bootstrapping During Full EAP Authentication"> + <artwork><![CDATA[ + ER server & +Authenticator EAP Proxy 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) + (Key AVP (rRK)) + <------------------------- + Diameter EAP/DEA + (EAP-Success) + (MSK) + [ ERP-Realm ] +]]></artwork> + </figure> 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. <vspace + blankLines="1" /> If the EAP server does not support the ERP + extensions, it simply ignores the ERP-RK-Request AVP and continues as + specified in <xref target="RFC4072">RFC 4072</xref>. 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 <xref target="RFC5296">RFC 5296</xref>, using the + saved domain name. It then includes the rRK inside a Key AVP <xref + target="KAVP"></xref> with the Key-Type AVP set to rRK, before sending + the DEA as usual.<vspace blankLines="1" /> 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 <xref target="KAVP"></xref> 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. <vspace blankLines="1" /> 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.</t> + </section> + + <section title="Bootstrapping During the First Re-authentication"> + <t>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. <vspace + blankLines="1" /> 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: <list> + <t>Changes the Application Id in the header of the message to + Diameter EAP Application (code 5).</t> + + <t>Change the content of Application-Auth-Id accordingly. <list + style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> Is it better + to leave it unmodified, so that the server can easily + differenciate between ERP and standard EAP message ?</t> + </list></t> + + <t>Add the ERP-RK-Request AVP, which contains the name of the + domain where the ER server is located.</t> + + <t><list style="hanging"> + <t hangText="PROBLEM:"><vspace blankLines="0" /> 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?</t> + </list></t> + </list> Then the proxied EAP/DER request is sent and routed to the + home Diameter EAP server. <vspace blankLines="1" /> 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 <xref + target="RFC5296"></xref>. In particular, it includes the Domain-Name + TLV attribute with the content from the ERP-Realm AVP. It creates the + EAP/DEA reply message <xref target="RFC4072"></xref>. including an + instance of the Key AVP <xref target="KAVP"></xref> with Key-Type AVP + set to rRK. <vspace blankLines="1" /> The ER server receives this + EAP/DEA and proxies it as follows, in addition to standard proxy + operations: <list> + <t>Set the Application Id back to Diameter ERP application Id + (code TBD)</t> + + <t>Extract and cache the content of the Key AVP with Key-Type set + to rRK, as described in implicit scenario.</t> + </list> The ERP/DEA message is then forwarded to the authenticator, + that can use the rMSK as described in <xref target="RFC5296">RFC + 5296</xref>. <vspace blankLines="1" /> The figure below captures this + proxy behavior: <figure align="center" anchor="FigExplicit" + title="ERP Explicit Bootstrapping Message Flow"> + <artwork><![CDATA[ +Authenticator ER server Home EAP server +============= ========= =============== + -----------------------> + 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)) +]]></artwork> + </figure></t> + </section> + </section> + + <section anchor="Re-authentication" title="Re-Authentication"> + <t>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. <figure align="center" + anchor="FigReauth" title="Diameter ERP Re-authentication Exchange"> + <artwork><![CDATA[ + ER server + Peer Authenticator (bootstrapped) + ==== ============= ====================== + [ <------------------------ ] + [optional EAP-Initiate/Re-auth-start,] + [ possibly with ERP domain name ] + + -----------------------> + 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 +]]></artwork> + </figure> 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. <vspace blankLines="1" /> If the authenticator does not support + ERP (pure <xref target="RFC4072">Diameter EAP</xref> 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. <vspace blankLines="1" /> When the authenticator receives an + EAP-Initiate/Re-auth message from the peer, it processes as described in + <xref target="RFC5296"></xref> with regards to the EAP state machine. It + creates a Diameter EAP Request message following the general process of + <xref target="RFC4072">Diameter EAP</xref>, with the following + differences: <list> + <t>The Application Id in the header is set to Diameter ERP (code + TBD).</t> + + <t>The value in Auth-Application-Id AVP is also set to Diameter ERP + Application.</t> + + <t>The keyName-NAI attribute from ERP message is used to create the + content of User-Name AVP and Destination-Realm AVP.</t> + + <t><list style="hanging"> + <t hangText="FFS:"><vspace blankLines="0" /> What about + Session-ID AVP ?</t> + </list></t> + + <t>The Auth-Request-Type AVP content is set to [Editor's note: FFS + -- cf. open issues].</t> + + <t>The EAP-Payload AVP contains the EAP-Initiate/Re-Auth + message.</t> + </list> Then this ERP/DER message is sent as described in <xref + target="Overview"></xref>. <vspace blankLines="1" /> The ER server + receives and processes this request as described in <xref + target="Overview"></xref>. It then creates an ERP/DEA message following + the general processing described in <xref target="RFC4072">RFC + 4072</xref>, with the following differences: <list> + <t>The Application Id in the header is set to Diameter ERP (code + TBD).</t> + + <t>The value of the Auth-Application-Id AVP is also set to Diameter + ERP Application.</t> + + <t>The EAP-Payload AVP contains the EAP-Finish/Re-auth message.</t> + + <t>In case of successful authentication, an instance of the Key AVP + containing the Re-authentication Master Session Key (rMSK) derived + by ERP is included.</t> + </list> When the authenticator receives this ERP/DEA answer, it + processes it as described in <xref target="RFC4072">Diameter EAP</xref> + and <xref target="RFC5296">RFC 5296</xref>: the content of EAP-Payload + AVP content is forwarded to the peer, and the contents of the + Keying-Material AVP <xref target="I-D.ietf-dime-local-keytran"></xref> + is used as a shared secret for Secure Association Protocol.</t> + </section> + + <section anchor="ApplicationId" title="Application Id"> + <t>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 <xref target="RFC3588"></xref>. + <vspace blankLines="1" /> 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 <xref target="AVPs"></xref>, although these AVP have + the 'M' flag cleared.</t> + </section> + + <section anchor="AVPs" title="AVPs"> + <t>This section discusses the AVPs used by the Diameter ERP + application.</t> + + <section title="ERP-RK-Request AVP"> + <t>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. <vspace blankLines="1" /> This AVP + has the M and V bits cleared. <figure align="center" anchor="ERRABNF" + title="ERP-RK-Request ABNF"> + <artwork><![CDATA[ + ERP-RK-Request ::= < AVP Header: TBD > + { ERP-Realm } + * [ AVP ] +]]></artwork> + </figure></t> + </section> + + <section title="ERP-Realm AVP"> + <t>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. + <vspace blankLines="1" /> This AVP has the M and V bits cleared.</t> + </section> + + <section anchor="KAVP" title="Key AVP"> + <t>The Key AVP <xref target="I-D.ietf-dime-local-keytran"></xref> 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.</t> + + <section title="Key-Type AVP"> + <t>The value of the Key-Type AVP MUST be set to 2 for rRK or 3 for + rMSK.</t> + </section> + + <section title="Keying-Material AVP"> + <t>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 <xref + target="RFC5296">RFC 5296</xref>.</t> + </section> + + <section title="Key-Name AVP"> + <t>This AVP contains the EMSKname which identifies the keying + material. The derivation of this name is specified in <xref + target="RFC5296">RGC 5296</xref>.</t> + </section> + + <section title="Key-Lifetime AVP"> + <t>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.</t> + </section> + </section> + </section> + + <section anchor="Issues" title="Open issues"> + <t>This document does not address some known issues in Diameter ERP + mechanism. The authors would like to hear ideas about how to address + them. <vspace blankLines="1" /> 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:<list> + <t>how to manage the Session-Id AVP -- is it a new session each + time, or do we try to reuse the same Diameter session?;</t> + + <t>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?)</t> + + <t>how does the peer learn the ERP domain of the new authenticator + -- this is being addressed in HOKEY architecture draft;</t> + + <t>how does the home server reachs the peer to for example terminate + the session if there is no notification sent to the home domain;</t> + </list><vspace blankLines="1" /> 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. <vspace blankLines="1" />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.<vspace blankLines="1" /> Finally, + this document currently lacks a description of what happens when a + Re-Auth-Request is received for a peer on the authenticator.</t> + </section> + + <section anchor="Acknowledgements" title="Acknowledgements"> + <t>Hannes Tschofenig wrote the initial draft for this document and + provided useful reviews. <vspace blankLines="1" /> Vidya Narayanan + reviewed a rough draft version of the document and found some errors. + <vspace blankLines="1" /> Lakshminath Dondeti contributed to the early + versions of the document. <vspace blankLines="1" /> Many thanks to these + people!</t> + </section> + + <section anchor="IANA" title="IANA Considerations"> + <t>This document requires IANA registration of the following new + elements in the <eref + target="http://www.iana.org/assignments/aaa-parameters/">Authentication, + Authorization, and Accounting (AAA) Parameters</eref> registries.</t> + + <section anchor="IANA_AppId" title="Diameter Application Identifier"> + <t>This specification requires IANA to allocate a new value "Diameter + ERP" in the "Application IDs" registry <xref target="RFC3588"> using + the policy specified in Section 11.3 of RFC 3588</xref>.</t> + </section> + + <section anchor="IANA_AVP" title="New AVPs"> + <t>This specification requires IANA to allocate new values from the + "AVP Codes" registry <xref target="RFC3588">according to the policy + specified in Section 11.1 of RFC 3588</xref> for the following AVPs: + <list> + <t>ERP-RK-Request</t> + + <t>ERP-Realm</t> + </list>These AVPs are defined in <xref target="AVPs"></xref>.</t> + </section> + </section> + + <section anchor="Security" title="Security Considerations"> + <t>The security considerations from the following documents also apply + here: <list style="symbols"> + <t><xref target="RFC3588">RFC 3588</xref></t> + + <t><xref target="RFC4072">RFC 4072</xref></t> + + <t><xref target="RFC5247">RFC 5247</xref></t> + + <t><xref target="RFC5295">RFC 5295</xref></t> + + <t><xref target="RFC5296"></xref></t> + </list> <list style="hanging"> + <t hangText="FFS:"><vspace blankLines="0" /> 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?</t> + </list> 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. <list style="hanging"> + <t hangText="QUESTION:"><vspace blankLines="0" /> What does this + paragraph actually mean?</t> + </list></t> + </section> + </middle> + + <back> + <references title="Normative References"> + &RFC2119; + + &RFC3588; + + &RFC4072; + + &RFC5295; + + &RFC5296; + + &I-D.ietf-dime-local-keytran; + + &RFC3748; + </references> + + <references title="Informative References"> + &RFC5247; + </references> + </back> +</rfc>