One document matched: draft-clancy-emu-aaapay-04.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 RFC2865 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml'>
<!ENTITY RFC3232 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3232.xml'>
<!ENTITY RFC3588 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY RFC3748 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY RFC4005 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4005.xml'>
<!ENTITY RFC4017 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4017.xml'>
<!ENTITY RFC4746 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4746.xml'>
<!ENTITY RFC4764 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4764.xml'>
<!ENTITY RFC4851 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4851.xml'>
<!ENTITY RFC4962 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4962.xml'>
<!ENTITY RFC5056 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
<!ENTITY RFC5247 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml'>
<!ENTITY RFC5281 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5281.xml'>
<!ENTITY RFC5433 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5433.xml'>
]>
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocompact="no"?>
<?rfc compact="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<rfc ipr="pre5378Trust200902" category="std" docName="draft-clancy-emu-aaapay-04.txt">
<front>
<title abbrev="EAP-AAAPAY">EAP Method Support for Transporting AAA Payloads</title>
<author initials="T." surname="Clancy" fullname="T. Charles Clancy">
<organization abbrev="LTS">Laboratory for Telecommunications Sciences</organization>
<address>
<postal>
<street>US Department of Defense</street>
<city>College Park</city>
<region>MD</region>
<country>USA</country>
</postal>
<email>clancy@LTSnet.net</email>
</address>
</author>
<author role="editor" initials="A." surname="Lior" fullname="Avi Lior">
<organization abbrev="BWS">Bridgewater Systems Corporation</organization>
<address>
<postal>
<street>303 Terry Fox Drive</street>
<street>Suite 500</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K2K 3J1</code>
<country>Canada</country>
</postal>
<phone>+1 (613) 591-6655</phone>
<email>avi@bridgewatersystems.com</email>
<uri>http://www.bridgewatersystems.com/</uri>
</address>
</author>
<author fullname="Glen Zorn" initials="G.Z." surname="Zorn">
<organization>Network Zen</organization>
<address>
<postal>
<street>1310 East Thomas Street</street>
<city>Seattle</city>
<region>Washington</region>
<code>98102</code>
<country>US</country>
</postal>
<phone>+1 (206) 377-9035</phone>
<email>gwz@net-zen.net</email>
</address>
</author>
<author fullname="Katrin Hoeper" initials="K." surname="Hoeper">
<organization>Motorola, Inc.</organization>
<address>
<postal>
<street>1301 E. Algonquin Road</street>
<city>Schaumburg</city>
<region>Illinois</region>
<code>60196</code>
<country>USA</country>
</postal>
<email>khoeper@motorola.com</email>
</address>
</author>
<date year="2010"/>
<area>Security</area>
<keyword>EAP</keyword>
<keyword>RADIUS</keyword>
<keyword>Diameter</keyword>
<keyword>Channel Bindings</keyword>
<abstract>
<t>This document defines bindings for existing EAP methods to
transport Diameter AVPs, called "AAA payloads". The primary
application is to support EAP channel bindings, but this could
be used for other applications as well.</t>
</abstract>
</front>
<middle>
<!-- ******************************************************************** -->
<section title="Introduction">
<t>This document defines a payload which can be securely
transported by an Extensible Authentication Method (EAP)
method <xref target="RFC3748" /> that carries arbitrary
Diameter Attribute-Value Pairs (AVPs) <xref target="RFC3588"
/>. While it may seem strange for EAP to encapsulate
Authorization, Authentication, and Accounting (AAA) messages,
since AAA typically encapsulates EAP, the security properties
are different. In particular, AAA data transported by EAP
between the client and server will be protected by an
end-to-end security relationship. This provides a secure
channel for doing things like channel bindings
<xref target="RFC5056" />.</t>
</section>
<!-- ******************************************************************** -->
<section title="Terminology">
<t>In this document, several words are used to signify the
requirements of the specification. These words are often
capitalized. 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"/>.</t>
</section>
<!-- ******************************************************************** -->
<section anchor="overview" title="Overview and Requirements">
<t>Many EAP <xref target="RFC3748" /> methods have extensible
properties that allow you to embed arbitrary data within a
secure channel. This channel is secured using keys derived
during the EAP authentication. These channels vary in the
properties that they provide, typically either providing
integrity protection or both confidentiality and integrity
protection.</t>
<t>In this document we define a payload format for encapsulating
Diameter AVPs <xref target="RFC3588" />, and via backwards
compatability <xref target="RFC4005" />, RADIUS TLVs
<xref target="RFC2865" />. We provide bindings for a variety of
existing EAP methods that would allow them to transport this
data. One specific application of this is to support EAP
channel bindings <xref target="RFC5056"/><xref target="I-D.ietf-emu-chbind" />.</t>
<t>The main goal is to provide the peer and server to exchange
AAA messages protected by an end-to-end security association.
As such, any EAP method transporting the AAA payloads defined
in this document MUST support integrity protection. To
accomplish this, a method supporting AAA payloads MUST perform
mutual authentication and derive session keys (i.e. MSK, etc),
and during this derivation process MUST derive a unique,
cryptographically independent, fresh key for protecting AAA
payloads. Protocols SHOULD also support confidentiality in
addition to integrity protection. Confidentiality is
important for identity protection, as a variety of identities
can be passed over this channel.</t>
</section>
<!-- ******************************************************************** -->
<section anchor="tokenformat" title="AAA Payload Format">
<t>This section describes the formatting for the AAA Payloads.
Each payload consists of the following fields:</t>
<t><list style="symbols">
<t>Version, 1 octet</t>
<t>Flags, 1 octet</t>
<t>length(Session-ID), 2 octets</t>
<t>Session-ID <xref target="RFC5247"/>, arbitrary length</t>
<t>One or more Diameter AVPs <xref target="RFC3588" />, arbitrary length</t>
</list></t>
<t>The version field is 1 octet. This documents defines version
0x01.</t>
<t>The flags field is 1 octet, and is the logical AND of the
following applicable values:</t>
<t><list style="symbols">
<t>0x01: Validation Failed</t>
<t>0x02: Validation Inconclusive</t>
<t>0x04: Validation Successful</t>
</list></t>
<t>The validation flag fields are used by the EAP server to convey
the success of the consistency check to the EAP peer. These
flags SHOULD NOT be used in messages from the peer to
server.</t>
<t>The Session-ID field is arbitrary length and is proceeded by
its 2-octet length specified in network-byte order.</t>
<t>Following the Session-ID is an arbitrary number of Diameter
AVPs. AVPs already contain a length field internally, so they
can be parsed without additional information.</t>
<t>The payload can be graphically depicted as:</t>
<figure anchor="chbindblob">
<artwork><![CDATA[
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version=0x01 | Flags | length(Session-ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Session-ID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Diameter AVP 1 ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Diameter AVP N ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<!-- ******************************************************************** -->
<section anchor="genmethodbindings" title="Bindings Requirements for EAP Methods">
<t>This section describes a set of general requirements for EAP methods
implementing the protected exchange of arbitrary data using the techniques
described in this draft.</t>
<t>An EAP method requiring the protected exchange of payloads during its
execution in order to enable certain features MUST:</t>
<t><list style="symbols">
<t>support at least one secure cryptographic algorithm that can be
used for integrity protection, such as an HMAC; </t>
<t>derive a session key that can be used in the integrity protection
algorithm, as soon as fresh EAP session keys are available; and</t>
<t>define a container enabling the exchange of arbitrary
payloads; and</t>
<t>provide an integrity-protected channel for at least 3 protocols
flows (i.e. 1.5 roundtrips) in which containers with payloads can be
securely exchanged</t>
</list></t>
<t>Optionally an EAP method MAY also support an encryption algorithm that is
used with a freshly derived encryption key to provide confidentiality of all
data that is exchanged in the protected channel.</t>
<t>Only existing EAP methods already satisfying these requirements can
support features that require the protected exchange of AAA payloads.</t>
<t>New EAP methods SHOULD be designed to meet all requirements.</t>
<t>For features demanding the protected exchange of potentially large chunks
of information, the support of fragmentation is RECOMMENDED.</t>
</section>
<!-- ******************************************************************** -->
<section anchor="existingmethodbindings" title="Bindings for Existing EAP Methods">
<t>This section describes how binding tokens can be included in some existing
EAP methods that already meet the requirements for secure transport of arbitrary data as specified in <xref target="genmethodbindings"/>.</t>
<section anchor="GPSKbinding" title="Generalized Pre-Shared Key (GPSK)">
<t>EAP-GPSK <xref target="RFC5433"/> defines protected data payloads. The
protected channel is available in three of its protocol flows, namely
EAP-GPSK-2, EAP-GPSK-3, and EAP-GPSK-4, and provides integrity-protection.
If a ciphersuite with encryption is selected (e.g. Ciphersuite 1 in
<xref target="RFC5433"/>) the channel also provides confidentiality.</t>
<t>Use by GPSK simply requires instantiation of a new protected data
specifier (PData/Specifier):</t>
<t><list style="symbols">
<t>0x0000002 (IANA-TBD): AAA Payload</t>
</list></t>
</section>
<section anchor="PSKbinding" title="Pre-Shared Key (PSK)">
<t>EAP-PSK <xref target="RFC4764"/> defines a protected channel. In its
standard mode, EAP-PSK provides a protected channel for payloads in two of
its flows, namely EAP-PSK-2 and EAP-PSK-3. Features requiring additional
flows can be supported in EAP-PSK extended authentication mode. The
protected channel is integrity-protected and encrypted.</t>
<t>Use by PSK simply requires instantiation of a new EXT_Type value:</t>
<t><list style="symbols">
<t>0x01 (IANA-TBD): AAA Payload</t>
</list></t>
</section>
<section anchor="PAXbinding" title="Password Authenticated Exchange (PAX)">
<t>EAP-PAX <xref target="RFC4746" /> provides an authenticated data
exchange (ADE) in three of its protocol flows (EAP-PAX-2, EAP-PAX-3, and
EAP-PAX-4). The channel provides integrity-protection but no encryption.
Channel binding is explicitly supported in EAP-PAX, in which case the
ADE flag needs to be set, and the ADE TYPE needs to be set to 0x02 for client
channel binding data and to 0x03 for server channel binding data.</t>
<t>Additional features could be supported by instantiation of a new ADE
type:</t>
<t><list style="symbols">
<t>0x04 (IANA-TBD): AAA Payload</t>
</list></t>
</section>
<section anchor="TTLSbinding" title="Tunneled Transport Layer Security (TTLS)">
<t>EAP-TTLS <xref target="RFC5281" /> uses Diameter
Attribute-Value-Pairs (AVPs) for its messaging. As such it natively
supports transporting AAA payloads. Once the TLS tunnel is established, a
variable number of flows can be exchanged in the second phase, e.g. to
exchange payloads in an integrity-protected and encrypted channel. No
protocol changes are necessary.</t>
</section>
<section anchor="FASTbinding" title="Flexible Authentication via Secure Tunneling (FAST)">
<t>EAP-FAST <xref target="RFC4851" /> uses Type-Length-Values (TLVs) for
its messaging. Once the TLS tunnel is established a variable number of
flows can be exchanged in the second phase, e.g. to exchange payloads in
an integrity-protected and encrypted channel. To embed binding tokens, a
new TLV must be defined:</t>
<t><list style="symbols">
<t>0x15 (IANA-TBD): AAA Payload</t>
</list></t>
</section>
</section>
<!-- ******************************************************************** -->
<section anchor="seccons" title="Security Considerations">
<t>Section 3 documented a variety of requirements for EAP
methods to transport these AAA payloads. They MUST support
identity protection of arbitrary payloads, and SHOULD support
confidentiality. Each method's security considerations
section would detail how they achieve those requirements.</t>
<t>The payload includes the EAP Session-ID field. This is to
prevent replay attacks. In particular, depending on how an
EAP method implements their secured channel, it may or may not
be cryptographically bound to the rest of the session. By
explicitly including the EAP Session-ID, we prevent replay
attacks. Implementations MUST verify the consistency of the
Session-ID received in the AAA payloads.</t>
<t>Certainly there are a whole host of issues surrounding the
security of what may be contained within the AAA payload
format. If the information being transported requires
confidentiality, then the method SHOULD support that.
Otherwise sensitive data could be disclosed.</t>
</section>
<!-- ******************************************************************** -->
<section anchor="ianacons" title="IANA Considerations">
<t>We require registry from a variety of IANA repositories.</t>
<t>From "EAP-GPSK PData/Specifier":</t>
<t><list style="symbols"><t>0x0000002 (IANA-TBD): AAA Payload</t></list></t>
<t>From "EAP EXT_Type Numbers":</t>
<t><list style="symbols"><t>0x01 (IANA-TBD): AAA Payload</t></list></t>
<t>From "EAP-PAX ADE Type Namespace":</t>
<t><list style="symbols"><t>0x04 (IANA-TBD): AAA Payload</t></list></t>
<t>From "EAP-FAST TLV Types":</t>
<t><list style="symbols"><t>0x15 (IANA-TBD): AAA Payload</t></list></t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3588;
&RFC3748;
</references>
<references title="Informative References">
&RFC2865;
&RFC4764;
&RFC4005;
&RFC4746;
&RFC4851;
&RFC5056;
&RFC5281;
&RFC5433;
&RFC5247;
<reference anchor="I-D.ietf-emu-chbind">
<front>
<title>Channel Binding Support for EAP Methods</title>
<author initials="T.C." surname="Clancy">
<organization>LTS</organization>
</author>
<author initials="K." surname="Hoeper">
<organization>Motorola, Inc.</organization>
</author>
<date month="October" year="2009" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-emu-chbind-04" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:36:13 |