One document matched: draft-dondeti-dime-erp-diameter-01.xml
<?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 I-D.ietf-hokey-erx PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hokey-erx.xml'>
<!ENTITY I-D.ietf-hokey-emsk-hierarchy PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hokey-emsk-hierarchy.xml'>
]>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="no"?>
<?rfc comments="yes"?>
<?rfc inline="no"?>
<rfc ipr="full3978" docName="draft-dondeti-dime-erp-diameter-01.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="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization abbrev="Nokia Siemens Networks">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<date year="2007"/>
<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>An EAP extension, called "EAP Re-authentication Protocol (ERP)", has been specified
that supports an EAP method-independent protocol for efficient re-authentication
between the peer and the server through an authenticator. This document specifies
Diameter support for ERP. The Diameter EAP application is re-used for encapsulating
the newly defined EAP Initiate and EAP Finish messages specified in the ERP
specification. AVPs for request and delivery of
Domain Specific Root Keys from the AAA/EAP server to the ER server are also specified. Additionally,
this document also specifies 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. <xref target="I-D.ietf-hokey-erx"/> defines the EAP Re-authentication
Protocol to allow faster re-authentication of a previously authenticated peer. In
ERP, a peer authenticates to 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="I-D.ietf-hokey-emsk-hierarchy"/>. 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 to the local domain ER server. The peer and the local server
subsequently use the re-authentication key hierarchy from the DSRK to authenticate
and derive authenticator specific keys within that domain. 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="I-D.ietf-hokey-emsk-hierarchy"/>, <xref target="I-D.ietf-hokey-erx"/>,
and <xref target="RFC4072"/>. </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>
</section>
<section title="Diameter Support for ERP" anchor="diameter_support">
<section title="Protocol Overview" anchor="overview">
<t>Diameter may be 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 Reauth message to the ER server via the
authenticator. Alternatively, the NAS may send an EAP Initiate Reauth-Start
message to the peer to trigger the start of ERP; the peer then responds with an
EAP Initiate Reauth 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 messages defined for ERP as
well. The EAP Initiate Reauth message is encapsulated in an EAP-Payload AVP of a
Diameter EAP-Request message by the NAS and sent to the Diameter server. The NAS
MUST copy the contents of the value field of the 'rIKName as NAI' TLV or the
peer-id TLV (when the former is not present) of the EAP Initiate Reauth message
into a User-Name AVP of the Diameter EAP-Request.</t>
<t>The ER server processes the EAP Initiate Reauth message in accordance with <xref
target="I-D.ietf-hokey-erx"/>, and if that is successful, it responds with
an EAP Finish Reauth message indicating a success ('R' flag set to 0). The
Diameter server MUST encapsulate the EAP Finish Reauth message with the R flag
set to zero 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 Reauth message resulted in a failure, the
Diameter server MUST encapsulate an EAP Finish Reauth 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>
</section>
<section title="DSRK Request and Delivery" anchor="dsrk">
<t>A local ER server, collocated with a Diameter proxy in the peer's visited domain,
may request a DSRK from the EAP server, either in the initial EAP exchange
(implicit bootstrapping) or in an ERP bootstrapping exchange (explicit
bootstrapping). It does this by including the EAP-DSRK-Request AVP in the
Diameter EAP-Response message. The EAP-DSRK-Request AVP contains the domain or
server identity required to derive the DSRK. </t>
<t>An EAP server MAY send the DSRK when it receives a valid Diameter EAP-Request
message containing an EAP-DSRK-Request AVP. An 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>
</section>
</section>
<section title="Command Codes">
<t> This document re-uses the EAP application commands <xref target="RFC4072"/>:</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">
<section title="EAP-DSRK-Request AVP">
<t>The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. This AVP fulfills
two purposes: First, it indicates that a ER server is located in the local
domain that is willing to play the role of an ER server for a particular
session. Second, it conveys information about the domain and ER server identity
to the Diameter/EAP server. </t>
</section>
<section title="EAP-DSRK AVP">
<t>The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. The Domain Specific Root
Key (DSRK) is carried in this payload. </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 name of the DSRK key that is later used during the re-authentication
exchange to select the correct DSRK. </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.</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; &I-D.ietf-hokey-erx; </references>
<references title="Informative References"> &rfc3748; &I-D.ietf-hokey-emsk-hierarchy;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:10:30 |