<?xml version="1.0" encoding="UTF-8"?>
 <?xml-stylesheet type='text/xsl' href='../../../rfc2629.xslt' ?>
 <!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
 <!ENTITY rfc2119 PUBLIC '' 
 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
 <!ENTITY rfc3748 PUBLIC '' 
 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
 <!ENTITY rfc4072 PUBLIC '' 
 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml'>
 <!ENTITY rfc3588 PUBLIC '' 
 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
 <!ENTITY rfc5295 PUBLIC ''
 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml'>
 <!ENTITY rfc5296 PUBLIC ''
 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml'>
 ]>
 <?rfc toc="yes"?>
 <?rfc compact="yes"?>
 <?rfc subcompact="no"?>
 <?rfc sortrefs="yes" ?>
 <?rfc symrefs="no"?>
 <?rfc comments="yes"?>
 <?rfc inline="no"?>
<rfc ipr="trust200811" docName="draft-ietf-dime-erp-00.txt" category="std">
    <front>
        <title abbrev="Diameter Support for ERP">Diameter Support for EAP Re-authentication Protocol</title>

        <author fullname="Lakshminath Dondeti" initials="L" surname="Dondeti">
            <organization>QUALCOMM, Inc.</organization>
            <address> <postal> 
                <street>5775 Morehouse Dr</street> 
                <city>San Diego</city>
                <region>CA</region>
                <country>USA</country>
            </postal>
                <phone>+1 858-845-1267</phone>
                <email>ldondeti@qualcomm.com</email>
            </address>
        </author>

    	<author initials="J." surname="Bournelle (Editor)" fullname="Julien 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 initials="L." surname="Morand" fullname="Lionel 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 initials="S." surname="Decugis" fullname="Sebastien 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>



	<date year="2009"/> 
	<area>Operations and Management</area>
	<workgroup>Diameter Maintenance and Extensions (DIME)</workgroup>
	<keyword>Internet-Draft</keyword> <keyword>EAP</keyword>
	<keyword>Diameter</keyword> <keyword>Re-authentication</keyword>
	<keyword>inter-authenticator roaming</keyword> 
	
	<abstract> 
	    
	    <t> 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.</t> 
	    
	    </abstract> 
		
	</front> 
		
	<middle> 
		    
	   <section title="Introduction" anchor="intro">

	    <t>RFC 4072 <xref target="RFC4072"/> specifies a Diameter
		application that carries EAP packets between a Diameter client
		and the Diameter Server/EAP server. RFC 5296 <xref
		    target="RFC5296"/> defines the EAP Re-authentication
		Protocol to allow faster re-authentication of a previously
		authenticated peer.</t> 

	    <!--
	    <t> In ERP, a peer is authenticated by the network by proving
		possession of key material derived during a previous EAP
		exchange. For this purpose, an Extended Master Session Key
		(EMSK) based re-authentication key hierarchy has been defined
		<xref target="RFC5295"/>. ERP may be
		executed between the ER peer and an ER server in the peer's
		home domain or the local domain visited by the peer. In the
		latter case, a Domain Specific Root Key (DSRK), derived from
		the EMSK, is provided by the home ER server to the local domain
		ER server. 
		<t/>

	    <t> To accomplish the 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.</t> 
	    
	    <t>The DSRK can be obtained as part of the regular EAP exchange or
		as part of an ERP bootstrapping exchange. The local ER server
		requesting the DSRK needs to be in the path of the EAP or ERP
		bootstrapping exchange in order to request and obtain the DSRK.
		This document also specifies how the DSRK is transported to the
		local ER server using Diameter. </t> </section> <section
	    title="Terminology"> <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 RFC 2119 <xref target="RFC2119"/>.
	    </t> <t> This document uses terminology defined in <xref
	    target="RFC3748"/>, <xref target="RFC5295"/>,
	<xref target="RFC5296"/>, and <xref target="RFC4072"/>.  </t> --> 
    
	     <t> 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 <xref
		     target="RFC5295"/>.  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.  </t>

	    <t> 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 <xref
		    target="RFC5295"/>, 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.  </t>

	</section>

        <section title="Assumptions">
	    <!--
	    <t>This document defines additional optional AVPs for usage with
		the Diameter EAP application. Routing of these messages is
		therefore provided via the Diameter Application Identifier
		(among other elements), as specified by the Diameter Base
		protocol <xref target="RFC3588"/>. Based on the deployment of
		ERP, a local Diameter server (the same entity serves as a
		Diameter proxy during the full EAP authentication) may play the
		role of the ER server for future re-authentication attempts. As
		such, the local Diameter server requesting the DSRK needs to be
		in the path of the current EAP exchange between the peer and
		the EAP server and also along in the future. The Diameter
		client is furthermore assumed to be able to route the
		re-authentication messages to the ER server. </t>
	    -->

	    <t> 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 <xref target="RFC3588"/>.
	    </t>
	    
	    <t> 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.)
	    </t>

        </section>

        <section title="Diameter Support for ERP" anchor="diameter_support">

            <section title="Protocol Overview" anchor="overview">

		<t>The Diameter EAP Application is used to transport ERP
		    messages between the NAS (authenticator) and an
		    authentication server (ER server).</t>


		<t>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.</t>

		<t>The general guidelines for encapsulating EAP messages in
		    Diameter from RFC 4072 <xref target="RFC4072"/> 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.</t>

		<!-- To be checked: peer-id presence ? -->

		<!--
                <t>The ER server processes the EAP-Initiate/Re-auth message in accordance with <xref
                        target="RFC5296"/>, and if that is successful, it responds with
                    an EAP-Finish/Re-auth message indicating a success (R flag set to '0'). The
                    Diameter server MUST encapsulate the EAP-Finish/Re-auth message 
                    in an EAP-Payload AVP attribute of a Diameter EAP-Answer message. An
                    EAP-Master-Session-Key AVP included in the Diameter EAP-Answer contains the
                    Re-authentication Master Session Key (rMSK). The Diameter Result Code, if any,
                    SHOULD be a success Result Code. </t>

                <t>If the processing of the EAP-Initiate/Re-auth message resulted in a failure, the
                    Diameter server MUST encapsulate an EAP-Finish/Re-auth message indicating failure
                    ('R' flag set to 1) in an EAP-Payload AVP of a Diameter EAP-Answer message. The
                    Diameter Result Code, if any, SHOULD be a failure Result Code. Whether an EAP
                    Finish Reauth message is sent at all is specified in <xref
                        target="I-D.ietf-hokey-erx"/>.</t>
		-->

		<t> The ER server processes the EAP-Initiate/Re-auth message in
		    accordance with <xref target="RFC5296"/> 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 ?) </t>

            </section>

            <section title="DSRK Request and Delivery" anchor="dsrk">

		<t>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.</t>

		<!--
		<t>An EAP/ER server MAY send the DSRK when it receives a valid Diameter EAP-Request
		    message containing an EAP-DSRK-Request AVP. An EAP/ER server MUST send the DSRK (or
                    send a failure result) when it receives a valid Diameter EAP-Request message
                    containing an EAP-DSRK-Request AVP along with a valid EAP-Initiate/Re-auth
                    packet with the bootstrapping flag turned on. If an EAP-DSRK-Request AVP is
                    included in any other Diameter EAP Request message, the Diameter server MUST
                    reply with a failure result. An EAP-DSRK AVP MUST be used to send a DSRK; 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.</t>
		-->

		<t> 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 ?).</t>


            </section>
        </section>

        <section title="Command Codes">

	    <t> This document re-uses the EAP application commands <xref
		    target="RFC4072"/> and does not define new command
		codes.</t>

	    <!--
            <t>
                <figure anchor="cmd" title="ERP Command Codes">
                    <artwork><![CDATA[
Command-Name             Abbrev.   Code     Reference  Application

Diameter-EAP-Request      DER       268      RFC 4072   EAP
Diameter-EAP-Answer       DEA       268      RFC 4072   EAP
]]></artwork>
                </figure>
            </t>

            <t>Re-Auth-Request (RAR) may trigger ERP.</t>
            <t>Session-Termination-Request
                (STR), Session-Termination-Answer (STA), Abort-Session-Request (ASR),
                Abort-Session-Answer (ASA), Accounting-Request (ACR), and Accounting-Answer (ACA)
                commands are used together with Diameter ERP, they follow the rules in the Diameter
                EAP application <xref target="RFC4072"/> and the Diameter Base specification <xref
                    target="RFC3588"/>. The accounting commands use the Application Identifier value
                of 3 (Diameter Base Accounting); the others use 0 (Diameter Common Messages). </t>

            <section title="Diameter-EAP-Request (DER)">

                <t>The Diameter-EAP-Request (DER) message <xref target="RFC4072"/>, indicated by the
                    Command- Code field set to 268 and the 'R' bit set in the Command Flags field,
                    is sent by the NAS to the Diameter server to initiate a network access
                    authentication and authorization procedure.</t>

                <t>The DEA message format is the same as defined in <xref target="RFC4072"/> with an
                    addition of optional EAP Re-authentication Protocol (ERP) AVPs. The addition of
                    the EAP-DSRK-Request AVP to the Diameter-EAP-Request message indicates that an
                    ERP server is present and willing to participate in the ERP protocol for this
                    session. Furthermore, the EAP-DSRK-Request AVP provides identity information
                    about the domain of the ERP server. </t>
                <t>
                    <figure>
                        <artwork><![CDATA[
  <Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
                             < Session-Id >
                             { Auth-Application-Id }
                             { Origin-Host }
                             { Origin-Realm }
                             { Destination-Realm }
                             { Auth-Request-Type }

                             [ EAP-DSRK-Request ]

                             [ User-Name ]
                             [ Destination-Host ]
                             ...
                           * [ AVP ]
                    ]]></artwork>
                    </figure>
                </t>
            </section>
            <section title="Diameter-EAP-Answer (DEA)">
                <t>The Diameter-EAP-Answer (DEA) message defined in <xref target="RFC4072"/>,
                    indicated by the Command-Code field set to 268 and 'R' bit cleared in the
                    Command Flags field, is sent in response to the Diameter-EAP-Request message
                    (DER). </t>
                <t>The DEA message format is the same as defined in <xref target="RFC4072"/> with an
                    addition of optional EAP Re-authentication Protocol (ERP) AVPs. The addition of
                    the EAP-DSRK, EAP-DSRK-Name and the EAP-DSRK-Lifetime AVP to the
                    Diameter-EAP-Answer message indicates that an Diameter / ER server is able to
                    provide ERP support for this session and delivers keying material, lifetime and
                    a key name. </t>
                <t>
                    <figure>
                        <artwork><![CDATA[
  <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
                            < Session-Id >
                            { Auth-Application-Id }
                            { Auth-Request-Type }
                            { Result-Code }
                            { Origin-Host }
                            { Origin-Realm }

                            [ EAP-DSRK ]
                            [ EAP-DSRK-Name ]
                            [ EAP-DSRK-Lifetime ] 

                            [ User-Name ]
                            ...
                          * [ AVP ]                                     
                    ]]></artwork>
                    </figure>
                </t>
	    
	    </section>
	    -->

        </section>
        <!-- ====================================================================== -->

        <section title="Attribute Value Pair Definitions">

	    <t>This section defines new AVPs for the ERP support within
		Diameter EAP Application.
	    </t>

            <section title="EAP-DSRK-Request AVP">

		<t>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 <!--and ER server identity--> to the
		    Diameter/EAP/ERP server. (Editor's Note: it is FFS if
		    DiameterIdentity is the correct type).</t>

            </section>

            <section title="EAP-DSRK AVP">

		<t>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.</t>

            </section>

            <section title="EAP-DSRK-Name AVP">

		<t>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 <xref
			target="RFC5295"/>.</t>

	    </section>

            <section title="EAP-DSRK-Lifetime AVP">

		<t>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)</t>

            </section>

        </section>


        <!-- ====================================================================== -->
        <section title="AVP Occurrence Table">

            <t>The following table lists the AVPs that may optionally be present in the DER and DEA
                commands <xref target="RFC4072"/>. </t>

            <t>
                <figure anchor="naspavptable"
                    title="DER and
                        DEA Commands AVP Table">
                    <artwork><![CDATA[
                                +---------------+
                                |  Command-Code | 
                                +-+-----+-----+-+
   Attribute Name                 | DER | DEA |
   -------------------------------|-----+-----+
   EAP-DSRK-Request               | 0-1 |  0  |
   EAP-DSRK                       |  0  | 0-1 |
   EAP-DSRK-Name                  |  0  | 0-1 |
   EAP-DSRK-Lifetime              |  0  | 0-1 |
                                  +-----+-----+
                  ]]></artwork>
                </figure>
            </t>

	    <t>When the EAP-DSRK AVP is present in the DEA then the
		EAP-DSRK-Name and the EAP-DSRK-Lifetime MUST also be
		present.</t>

        </section>

        <section title="AVP Flag Rules">

	    <t>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 <xref target="RFC3588"/> specifies
		the AVP Flag rules for AVPs in Section 4.5. </t>

            <t>
                <figure anchor="flagstable" title="AVP Flag Rules Table">
                    <artwork><![CDATA[
                                          +---------------------+
                                          |    AVP Flag Rules   |
                                          +----+-----+----+-----+----+
                   AVP  Section           |    |     |SHLD|MUST |    |
Attribute Name     Code Defined Data Type |MUST| MAY |NOT |NOT  |Encr|
------------------------------------------+----+-----+----+-----+----+
EAP-DSRK-Request   TBD  4.7.1  DiamIdent  |    |  P  |    | V,M | Y  |
EAP-DSRK           TBD  4.7.2  OctetString|    |  P  |    | V,M | Y  |
EAP-DSRK-Name      TBD  4.7.3  OctetString|    |  P  |    | V,M | Y  |
EAP-DSRK-Lifetime  TBD  4.7.4  Unsigned64 |    |  P  |    | V,M | Y  |
------------------------------------------+----+-----+----+-----+----+

Due to space constraints, the short form DiamIdent is used to
represent DiameterIdentity.
                        ]]></artwork>
                </figure>
            </t>
        </section>

        <!-- ====================================================================== -->

        <section title="Security Considerations" anchor="SecCons">

	    <t>The security considerations specified in RFC 4072 <xref
		    target="RFC4072"/>, and RFC 3588 <xref target="RFC3588"/>
		are applicable to this document. </t>

	    <t>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. </t>

	</section>

        <!-- ====================================================================== -->

        <section title="IANA Considerations" anchor="ianaCons">

            <t>This document requires IANA registration of the following new AVPs to the AVP
                registry established by RFC 3588 <xref target="RFC3588"/>: <list style="symbols">
                    <t>EAP-DSRK-Request</t>
                    <t>EAP-DSRK</t>
                    <t>EAP-DSRK-Name</t>
                    <t>EAP-DSRK-Lifetime</t>
                </list>
            </t>

        </section>

        <section title="Acknowledgments" anchor="ack">

	    <t>Vidya Narayanan reviewed a rough draft version and found some
		errors. Many thanks for her input.</t>

        </section>
    </middle>

    <back>

        <references title="Normative References"> &rfc2119; &rfc3588; 
            &rfc4072; &rfc5296; </references>

        <references title="Informative References"> &rfc3748; &rfc5295;
            </references>
    </back>
</rfc>