One document matched: draft-dondeti-dime-erp-diameter-00.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 rfc2548 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2548.xml'>
<!ENTITY rfc3078 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3078.xml'>
<!ENTITY rfc3579 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3579.xml'>
<!ENTITY rfc4072 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml'>
<!ENTITY rfc4005 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4005.xml'>
<!ENTITY rfc3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY rfc2865 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml'>
<!ENTITY rfc2434 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml'>
<!ENTITY emskderiv SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hokey-emsk-hierarchy.xml">
<!ENTITY erp SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hokey-erx.xml">
<!ENTITY keywrap SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zorn-radius-keywrap.xml">
<!ENTITY rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.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-00" 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>
<date month="September" year="2007"/>
<area> </area>
<workgroup>Network Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>EAP</keyword>
<keyword>Diameter</keyword>
<keyword>Re-authentication</keyword>
<keyword>inter-authenticator roaming</keyword>
<abstract>
<t><xref target="I-D.ietf-hokey-erx"/> specifies the EAP Re-authentication Protocol (ERP). This document
specifies Diameter support for ERP. The EAP payload AVP defined in the Diameter EAP application
specification <xref target="RFC4072"/> is used for encapsulating the EAP Initiate and Finish messages
specified in <xref target="I-D.ietf-hokey-erx"/>. This document specifies attributes for the request and
delivery of Domain Specific Root Keys from the AAA/EAP server to the ER Server. Additionally, this
document also specifies Diameter message processing rules relevant to ERP. </t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>RFC4072<xref target="RFC4072"/> specifies EAP message encapsulation in Diameter messages. <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, ERP defines
two new EAP codes - EAP Initiate and EAP Finish. This document specifies the encapsulation of these
messages in Diameter. In addition, a Domain Specific Root Key (DSRK) may be transported from the
Diameter or EAP Server to an EAP Re-authentication (ER) server in the local domain for the purpose of
re-authenticating the peer within that domain (see Figure 2 of <xref target="I-D.ietf-hokey-erx"/>. This
document defines how the DSRK is transported to the 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="Diameter Support for ERP" anchor="diameter_support">
<t>The EAP Re-authentication Protocol, defined in <xref target="I-D.ietf-hokey-erx"/>, provides a mechanism
for efficient re-authentication of EAP peers that have unexpired keying material from 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. </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. </t>
<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 RFC4072 <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 server in the peer's visited domain, may request a DSRK
from the EAP server, either in the initial EAP exchange or in an ERP bootstrapping exchange. A
Diameter server acting as an ER server may include a EAP-DSRK-Request AVP in the Diameter
EAP-Request message containing an EAP Response or an EAP Initiate Reauth packet in the EAP-Payload
AVP. The Data field of the EAP-DSRK-Request AVP SHOULD be set to the domain or server identity
required to derive the DSRK. The format of the Data field is OctetString. If the EAP-Payload AVP
contains EAP Response, the 'M' bit in the AVP flags MUST NOT be set; if the EAP-Payload AVP contains
an EAP Initiate Reauth message with the bootstrapping flag turned on, the 'M' bit MUST be set. The
Diameter server requesting the DSRK needs to be in the path of the corresponding EAP or ERP exchange
between the peer and the EAP or ER server. </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>
<t>EAP-DSRK AVP SHALL contain Data in OctetString format; EAP-DSRK-Name AVP SHALL contain Data in
OctetString format; and finally EAP-DSRK-Lifetime AVP SHALL contain Data in Unsigned64 format
encoding DSRK lifetime in seconds.</t>
</section>
</section>
<section title="Security Considerations" anchor="SecCons">
<t>The security considerations specified in RFC 4072 <xref target="RFC4072"/>, RFC 4005 <xref
target="RFC4005"/>, and RFC 3588 <xref target="RFC3588"/> are applicable to this document. </t>
<t> EAP Channel bindings may be necessary to ensure that the Diameter user and the server are in
synchronization 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 several new Diameter AVPs: </t>
<t>EAP-DSRK-Request</t>
<t>EAP-DSRK</t>
<t>EAP-DSRK-Name</t>
<t>EAP-DSRK-Lifetime</t>
</section>
<section title="Acknowledgments" anchor="ack"><t>Vidya Narayanan reviewed a rough draft version and found some
errors. Many thanks for her input. Any remaining errors and omissions are my responsibility however.</t></section>
</middle>
<back>
<references title="Normative References"> &rfc2119; &rfc3588; &rfc4005;
&rfc4072; </references>
<references title="Informative References"> &rfc3748; &emskderiv; &keywrap; &erp;</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:13:28 |