One document matched: draft-ietf-emu-chbind-05.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 RFC4006 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4006.xml'>
<!ENTITY RFC4017 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4017.xml'>
<!ENTITY RFC5056 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
<!ENTITY I-D.aboba-radext-wlan PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.aboba-radext-wlan.xml'>
]>
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocompact="no"?>
<?rfc compact="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<rfc ipr="pre5378Trust200902" category="std">
<front>
<title abbrev="EAP-CHBIND">Channel Binding Support for EAP Methods</title>
<author initials="S." surname="Hartman" fullname="Sam Hartman" role="editor">
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott ST</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>USA</country>
</postal>
<email>hartmans-ietf@mit.edu</email>
</address>
</author>
<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>
<code>20740</code>
<country>USA</country>
</postal>
<email>clancy@LTSnet.net</email>
</address>
</author>
<author initials="K." surname="Hoeper" fullname="Katrin Hoeper">
<organization abbrev="Motorola, Inc.">Motorola, Inc.</organization>
<address>
<postal>
<street>1301 E. Algonquin Road</street>
<city>Schaumburg</city>
<region>IL</region>
<code>60196</code>
<country>USA</country>
</postal>
<email>khoeper@motorola.com</email>
</address>
</author>
<date />
<area>Security</area>
<workgroup>EMU Working Group</workgroup>
<keyword>EAP</keyword>
<keyword>Channel Bindings</keyword>
<abstract>
<t>This document defines how to implement channel bindings for
Extensible Authentication Protocol (EAP) methods to address
the lying NAS as well as the lying provider problem.</t>
</abstract>
</front>
<middle>
<!-- ******************************************************************** -->
<section title="Introduction">
<t>The so-called "lying NAS" problem is a well-documented
problem with the current Extensible Authentication Protocol
(EAP) architecture <xref target="RFC3748"/> when used in
pass-through authenticator mode. Here, a Network Access
Server (NAS), or pass-through authenticator, may represent one
set of information (e.g. network identity, capabilities,
configuration, etc) to the backend Authentication,
Authorization, and Accounting (AAA) infrastructure, while
representing contrary information to EAP peers. Another
possibility is that the same false information could be
provided to both the EAP peer and EAP server by the NAS. A "lying" entity can also be located anywhere on the AAA path between the NAS and the
EAP server. </t>
<t>As a concrete example, consider an organization with two
different IEEE 802.11 wireless networks. One is a relatively
low-security network for reading e-mail while the other has
access to valuable confidential information. An access point on
the e-mail network could act as a lying NAS, sending the SSID of
the confidential network in its beacons. This access point could
gain an advantage by doing so if it tricks clients intending to
connect to the confidential network to connect to it and
disclose confidential information.</t>
<t>A similar problem can be observed in the context of roaming. Here, the lying entity is located in a visited service provider network,
e.g. attempting to lure peers to connect to the network based on false advertized roaming rates. This is referred to as "lying provider" problem
in the remainder of this document. The lying entity's motivation
often is financial; the entity may be paid whenever peers roam to
its service. However a lying entity in a provider network can
gain access to traffic that it might not otherwise see.</t>
<t>This document defines and implements EAP channel bindings to
solve the lying NAS and the lying provider problems, using a process in which the EAP
peer provides information about the characteristics of the
service provided by the authenticator to the AAA server
protected within the EAP method.
This allows the server to verify the authenticator is providing
information to the peer that is consistent with the information
received from this authenticator as well as the information stored about this authenticator.
"AAA Payloads" defined in
<xref target="I-D.clancy-emu-aaapay"/> proposes a mechanism to
carry this information.</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="probstate" title="Problem Statement">
<t>In a <xref target="RFC4017"/> compliant EAP authentication, the
EAP peer and EAP server mutually authenticate each other, and
derive keying material. However, when operating in pass-through
mode, the EAP server can be far removed from the authenticator.
A malicious or compromised authenticator may represent incorrect
information about the network to the peer in an effort to
affect its operation in some way. Additionally, while an
authenticator may not be compromised, other compromised elements
in the network (such as proxies) could provide false information to the
authenticator that it could simply be relaying to EAP peers.
Hence, the goal must be to ensure that the authenticator is providing
correct information to the EAP peer during the initial network
discovery, selection, and authentication.</t>
<t>There are two different types of networks to consider:
enterprise networks and service provider networks. In
enterprise networks, assuming a single administrative domain,
it is feasible for an EAP server to have information about
all the authenticators in the network. In service provider
networks, global knowledge is infeasible due to indirection via
roaming. When a peer is outside its home administrative
domain, the goal is to ensure that the level of service received
by the peer is consistent with the contractual agreement
between the two service providers. The same EAP server may
need to support both types of networks. For example an
enterprise may have a roaming agreement permitting its users
to use the networks of third-party service providers. In these
situations, the EAP server may authenticate for an enterprise
and provider network. </t>
<t>The following are example attacks possible by
presenting false network information to peers.</t>
<t><list style="symbols">
<t>Enterprise Network: A corporate network may have multiple
virtual Lads (VLANs) running throughout their campus
network, and have IEEE 802.11 access points connected to
each VLAN. Assume one VLAN connects users to the firewalled
corporate network, while the other connects users to a
public guest network. The corporate network is assumed to
be free of adversarial elements, while the guest network is
assumed to possibly have malicious elements. Access Points
on both VLANs are serviced by the same EAP server, but
broadcast different SSIDs to differentiate. A compromised
access point connected to the guest network could advertise
the SSID of the corporate network in an effort to lure
peers to connect to a network with a false sense of
security regarding their traffic. Conditions and further
details of this attack can be found in the Appendix.
<vspace blankLines="1"/></t>
<t>Service Provider Network: An EAP-enabled mobile phone provider could advertize very competitive flat rates
but send per minute rates to the home server, thus, luring peers to connect to their network and overcharging them.
In more elaborate attacks, peers can be tricked into roaming without their knowledge. For example,
a mobile phone provider operating along a geo-political boundary could
boost their cell towers' transmission power and advertise
the network identity of the neighboring country's indigenous
provider. This would cause unknowing handsets to associate
with an unintended operator, and consequently be subject to
high roaming fees without realizing they had roamed off
their home provider's network.
These types of scenarios can be considered as "lying provider" problem, because here the
provider configures its NAS to broadcast false information. For the purpose of channel bindings as defined in
this draft, it does not matter which local entity (or
entities) is "lying" in a service provider network (local
NAS, local authentication server and/or local proxies),
because the only information received from the visited
network that is verified by channel bindings is the
information the home authentication server received from the
last hop in the communication chain. In other words, channel
bindings enable the detection of inconsistencies in the
information from a visited network, but cannot determine
which entity is lying. Naturally, channel bindings for EAP
methods can only verify the endpoints and, if desirable,
intermediate hops need to be protected by the employed AAA
protocol.<vspace blankLines="1"/></t>
<t>Enterprise and provider networks: In a situation where an
enterprise has a roaming agreements with providers, a
compromised access point in a provider network could
masquerade as the enterprise network in an attempt to gain
confidential information.</t>
</list></t>
<t>To address these problems, a mechanism is required to validate
unauthenticated information advertised by EAP
authenticators.</t>
</section>
<!-- ******************************************************************** -->
<section anchor="overview" title="Channel Bindings">
<t>EAP channel bindings seek to authenticate previously
unauthenticated information provided by the authenticator to
the EAP peer, by allowing the peer and server to compare
their perception of network properties in a secure
channel.</t>
<t>It should be noted that the definition of EAP channel
bindings differs somewhat from channel bindings documented in
<xref target="RFC5056"/>, which seek to securely bind together
the end points of a multi-layer protocol, allowing lower
layers to protect data from higher layers. Unlike
<xref target="RFC5056"/>, EAP channel bindings do not ensure
the binding of different layers of a session but rather the
information advertised to EAP peer by an authenticator
acting as pass-through device during an EAP execution. The
term channel bindings was independently adopted by these two
related concepts; by the time the conflict was discovered, a
wide body of literature existed for each usage.</t>
<section anchor="bindingtypes" title="Types of EAP Channel Bindings">
<t>There are two categories of approach to EAP channel bindings:</t>
<t><list style="symbols">
<t>After keys have been derived during an EAP execution,
the peer and server can, in an integrity-protected
channel, exchange plaintext information about the
network with each other, and verify consistency and
correctness.<vspace blankLines="1"/></t>
<t>The peer and server can both uniquely encode their respective view of the network information without exchanging it,
resulting into an opaque blob that can be included directly into the derivation of EAP session keys.</t>
</list></t>
<t>Both approaches are only applicable to key deriving EAP
methods and both have advantages and disadvantages. Various hybrid approaches are also possible. Advantages of
exchanging plaintext information include:</t>
<t><list style="symbols">
<t>It allows for policy-based comparisons of network
properties, rather than requiring precise matches for
every field, which achieves a policy-defined
consistency, rather than bitwise equality. This allows
network operators to define which properties are
important and even verifiable in their
network.<vspace blankLines="1"/></t>
<t>EAP methods that support extensible,
integrity-protected channels can easily include support
for exchanging this network information. In contrast,
direct inclusion into the key derivation would require
more extensive revisions to existing EAP methods or a wrapper EAP
method.<vspace blankLines="1"/></t>
<t>Given it doesn't affect the key derivation, this
approach facilitates debugging, incremental deployment,
backward compatibility and a logging mode in which
verification results are recorded but do not have an
affect on the remainder of the EAP execution. The exact
use of the verification results can be subject to the
network policy. Additionally, consistent information
canonicalization and formatting for the key derivation
approach would likely cause significant deployment
problems.</t>
</list></t>
<t>The following are advantages of directly including channel
binding information in the key derivation:</t>
<t><list style="symbols">
<t>EAP methods not supporting extensible,
integrity-protected channels could still be supported,
either by revising their key derivation, revising EAP,
or wrapping them in a universal method that supports
channel binding.<vspace blankLines="1"/></t>
<t>It can guarantee proper channel information, since
subsequent communication would be impossible if
differences in channel information yielded different
session keys on the EAP peer and server.</t>
</list></t>
</section>
<section anchor="SAP" title="Channel Bindings in the Secure Association
Protocol">
<t>This document describes channel bindings performed by
transporting channel binding information as part of an
integrity-protected exchange within an EAP
method. Alternatively, some future document could specify a
mechanism for transporting channel bindings within the lower
layer's secure association protocol. Such a specification
would need to describe how channel bindings are exchanged
over the lower layer protocol between the peer and
authenticator. In addition, since the EAP exchange concludes
before the secure association protocol begins, a mechanism for
transporting the channel bindings from the authenticator to
the EAP server needs to be specified. A mechanism for
transporting a protected result from the EAP server, through
the authenticator, back to the peer needs to be
specified..</t>
<t>The channel bindings MUST be transported with integrity
protection based on a key known only to the peer and EAP
server. The channel bindings SHOULD be confidentiality
protected using a key known only to the peer and EAP
server. For the system to function, the EAP server needs
access to the channel binding information from the peer as
well as the AAA attributes and a local database described
later in this document.</t>
<t>The primary advantage of sending channel bindings as part
of the secure association protocol is that EAP methods need
not be changed. The disadvantage is that a new AAA exchange is
required, and secure association protocols need to be
changed. As the result of the secure association protocol
change, every NAS needs to be upgraded to support channel
bindings within the secure association protocol.</t>
<t>For many deployments, changing all the NASes is expensive
and adding channel binding support to enough EAP methods to
meet the goals of the deployment will be cheaper. However for
deployment of new equipment, or especially deployment of a new
lower layer technology, changing the NASes may be cheaper than
changing EAP methods. Especially if such a deployment needed
to support a large number of EAP methods, sending channel
bindings in the secure association protocol might make
sense.</t>
<t>If channel bindings using a secure association protocol is
specified, semantics as well as the set of information that
peers exchange can be shared with the mechanism described in
this document.</t>
</section>
<section title="Channel Bindings Architecture">
<t>The scope of EAP channel bindings differs somewhat
depending on the type of deployment in which they are being
used. In enterprise networks, they can be used to
authenticate very specific properties of the authenticator
(e.g. MAC address, supported link types and data rates,
etc), while in service provider networks they can generally
only authenticate broader information about a roaming
partner's network (e.g. network name, roaming information,
link security requirements, etc). The reason for the
difference has to do with the amount of information about the authenticator
and/or network to which the peer is connected the home EAP
server is expected to have access to. In roaming
cases, the home server is likely to only have access to information
contained in their roaming agreements.</t>
<t>With any multi-hop AAA infrastructure, many of the NAS-specific
AAA attributes are obscured by the AAA proxy that's
decrypting, reframing, and retransmitting the underlying AAA
messages. Especially service provider networks are affected
by this and the AAA information received from the last hop may
not contain much verifiable information any longer. For
example, information carried in AAA attributes such as the NAS IP address may have been lost in transition and are thus not
known to the EAP server. This affects the ability of the
EAP server to verify specific NAS properties. However,
often verification of the MAC or IP address of the NAS is
not useful for improving the overall security posture of a
network. More often it is useful to make policy decisions
about services being offered to peers. For example, in an
IEEE 802.11 network, the EAP server may wish to ensure that
peers connecting to the corporate intranet are using
secure link-layer encryption, while link-layer security
requirements for peers connecting to the guest network
could be less stringent. These types of policy decisions
can be made without knowing or being able to verify the IP
address of the NAS through which the peer is connecting.</t>
<t>The properties of the network that the peer wishes to
validate depend on the specific deployment. In a mobile phone network, peers generally don't care what
the name of the network is, as long as they can make their
phone call and are charged the expected amount for the call.
However, in an enterprise network a peer may be more
concerned with specifics of where their network traffic is
being routed and what VLAN is in use.</t>
<t>As discussed in the next section, some of the most
important information to verify cannot come from AAA
attributes but instead comes from local configuration. For
example in the mobile phone case, the expected roaming rate
cannot come from the roaming provider without being verified
against the contract between the two providers. Similarly, in
an enterprise, the SSID a particular access point is expected
to advertize is a matter of configuration rather than
something that can be trusted because it is included in an AAA
exchange.</t>
<t>Channel bindings can be important form forming pockets of
trust, especially when provider networks are involved, and
exact information is not available to the EAP server. Without
channel bindings, all entities in the system need to be held
to the standards of the most trusted entity that could be
accessed using the EAP credential. Otherwise, a less trusted
entity can impersonate a more trusted entity. However when
channel bindings are used, the EAP server can use information
supplied by the peer, AAA protocols and local database to
distinguish less trusted entities from more trusted
entities. One possible deployment involves being able to
verify a number of characteristics about relatively trusted
entities while for other entities simply verifying that they
are less trusted.</t>
<t>Any deployment of channel bindings should take into
consideration both what information the EAP server is likely
to know or have access to, and also what type of network information the peer
would want and need authenticated.</t>
</section>
</section>
<!-- ******************************************************************** -->
<section anchor="chbp" title="Channel Binding Protocol">
<t>This section defines the protocol for verifying channel binding
information during an EAP authentication. The protocol uses
the approach where plaintext data is exchanged, since it
allows channel bindings to be used more flexibly in varied
deployment models (see <xref target="bindingtypes"/>). In the first subsection, the general communication infrastructure is outlined,
the messages used for channel binding verifications are specified, and the protocol flows are defined.
The second subsection explores the difficulties of checking the different pieces of information that are exchanged during the channel binding
protocol for consistency. </t>
<section title="Protocol Operation">
<t>Channel bindings are always provided between two
communication endpoints, here the EAP peer and the EAP server, who
communicate through an authenticator in pass-through mode. For the channel binding protocol presented in this draft to work,
the EAP server needs to be able to access information from the AAA server that is utilized during the EAP session and a
local database. For example, the EAP server and the local database can be co-located with the AAA server, as illustrated in
<xref target="chbinddiag"/>. </t>
<figure anchor="chbinddiag" title="Overview of Channel Binding">
<artwork><![CDATA[
+ -------------------------+
-------- ------------- | ---------- ______ |
|EAP peer|<---->|Authenticator|<--> | |EAP Server|___(______) |
-------- ------------- | ---------- | DB | |
. . |AAA (______) |
. i1 . +--------------------------+
.<----------------. i2 . .
. .------------> .
. i1 .
.-------------------------------------->.
. CB_success/failure(i1, i2,info) .
.<--------------------------------------.
]]></artwork>
</figure>
<t>During network advertisement, selection, and authentication,
the authenticator presents unauthenticated information,
labeled i1, about the network to the peer. Message i1 could include an authenticator identifier and
the identity of the network it represents, in addition to
advertised network information such as offered services and
roaming information. Information may be communicated implicitly in i1,
such as the type of media in use. As there is no established trust
relationship between the peer and authenticator, there is no
way for the peer to validate this information.</t>
<t>Additionally, during the transaction the authenticator
presents a number of information properties in form of AAA attributes about itself and the current request to
the AAA infrastructure which may or may not be valid. This information is labeled i2.
Message i2 is the information the AAA server receives from
the last hop in the AAA proxy chain which is not necessarily
the authenticator.</t>
<t>The local database is perhaps the most important part of
this system. In order for the EAP server or AAA server to know whether i1
and i2 are correct, they need access to trustworthy information, since
an authenticator could include false information in both i1
and i2. Additional reasons why such a database is necessary for channel bindings to work are discussed in the next subsection.
The information contained within the database could
involve wildcards. For example, this could be used to
check whether WiFi access points on a particular IP subnet
all use a specific SSID. The exact IP address is
immaterial, provided it is on the correct subnet.</t>
<t>During an EAP method execution with channel bindings, the
peer sends i1 to the EAP server using the mechanism
described in <xref target="I-D.clancy-emu-aaapay"/>. the EAP
server verifies the consistency of i1 provided by
the peer, i2 provided by the authenticator, and the information in the local database. Upon the check, the EAP server
sends a message to the peer indicating whether the channel binding validation check succeeded or failed and optionally includes all or some of
the information that was used in the check. The message flow is illustrated in <xref target="chbinddiag"/>.</t>
<t>If the compliance of i1 or i2 information with the authoritative
policy source is mandatory and a consistency check failed, then after
sending a protected indication of failed consistency, the
EAP server MUST send an EAP-Failure message to terminate the
session. If the EAP server is otherwise configured, it MUST
allow the EAP session to complete normally, and leave the
decision about network access up to the peer's policy.</t>
</section>
<section title="Channel Binding Consistency Check">
<t>The validation check that is the core of the channel binding protocol described in the previous subsection,
consists of two parts in which the server checks whether:<vspace blankLines="1"/>
<list style='numbers'>
<t> the authenticator is lying to the peer, i.e. i1 contains false information, <vspace blankLines="1"/> </t>
<t> the authenticator or any entity on the AAA path to the AAA server provides false information in form of AAA attributes,
i.e. i2 contains false information, <vspace blankLines="1"/> </t>
</list>
These checks enable the EAP server to detect lying NAS/authenticator in enterprise networks and lying providers in service provider networks.
</t>
<t>Checking the consistency of i1 and i2 is nontrivial, as has been pointed out already in <xref target="HC07"/>.
First, i1 can contain any type of information propagated by the authenticator,
whereas i2 is restricted to information that can be carried in AAA attributes. Second, because the authenticator typically
communicates over different link layers with the peer and the AAA infrastructure, different type of identifiers and addresses may have been
presented to both communication endpoints. Whether these different identifiers and addresses belong to the same device cannot be directly
checked by the EAP server or AAA server without additional information. Finally, i2 may be different from
the original information sent by the authenticator because
of en route processing or malicious modifications. As a
result, in the service provider model, typically the i1 information available to the EAP
server can only be verified against the last-hop portion of i2, or
values propagated by proxy servers. In addition, checking the consistency of i1 and i2
alone is insufficient because an authenticator could lie to both, the peer and
the EAP server, i.e. i1 and i2 may be consistent but both contain false information.</t>
<t>A local database is required to leverage the above mentioned shortcomings and support the consistency and validation checks. In particular,
information stored for each NAS/authenticator (enterprise scenario) or each roaming partner (service provider scenario) enables
a comparison of any information received in i1 with AAA attributes in i2 as well as additionally stored AAA attributes
that might have gone lost in transition. Furthermore, only such a database enables the EAP server and AAA server to check
the received information against trusted information about the network including roaming agreements. </t>
<t><xref target="l2bindings"/> describes lower-layer
specific properties that can be exchanged as a part of i1.
<xref target="aaabind"/> describes specific AAA
attributes that can be included and evaluated in i2. The EAP server
reports back the results from the channel binding validation check that compares the
consistency of all the values with those in the local
database. The challenges of setting up such a local database
are discussed in
<xref target="OMcons"/>.</t>
</section>
</section>
<!-- ******************************************************************** -->
<section anchor="sysreq" title="System Requirements">
<t>This section defines requirements on components used to
implement the channel bindings protocol.</t>
<t>The channel binding protocol defined in this document must
be transported after keying material has been derived
between the EAP peer and server, and before the peer would
suffer adverse affects from joining an adversarial
network. This document describes a protocol for performing
channel binding within EAP methods. As discussed in <xref
target="SAP" />, an alternative approach for meeting this
requirement is to perform channel bindings during the secure
association protocol of the lower layer.</t>
<section anchor="req_tranport" title="General Transport Protocol Requirements">
<t>The transport protocol for carrying channel binding
information MUST support end-to-end (i.e. between the EAP
peer and server) message integrity protection to prevent
the adversarial NAS or AAA device from manipulating the
transported data. The transport protocol SHOULD provide
confidentiality. The motivation for this that the channel
bindings could contain private information, including peer
identities, which SHOULD be protected.
If confidentiality cannot be provided, private information MUST NOT be sent as part of the channel binding information.</t>
<t>One way to transport the single round-trip exchange is as
a series of TLVs formatted and encapsulated in
EAP methods. These TLVs carry different types of data. Since i2 messages are carried within a AAA protocol it is useful to define one
type of data carried as AAA AVPs, but other types of data may be defined that are not carried in AAA attributes and are only compared
against the information stored in the local database. This document describes some AAA attributes that are useful for channel binding checks.
Additionally, guidance on how to
perform consistency checks on those values will be
provided. Since the Diameter namespace contains the RADIUS namespace the TLVs of AAA AVP type carry Diameter attributes. </t>
<t>Any transport needs to be careful not to exceed the MTU
for its lower-layer medium. In particular, if channel
binding information is exchanged within protected EAP
method channels, these methods may or may not support
fragmentation. In order to work with all methods, the
channel binding messages must fit within the available
payload. For example, if the EAP MTU is 1020 octets, and
EAP-GPSK is used as the authentication method, and
maximal-length identities are used, a maximum of 384
octets are available for conveying channel binding
information. Other methods, such as EAP-TTLS, support
fragmentation and could carry significantly longer
payloads.</t>
</section>
<section title="EAP Method Requirements">
<t>If transporting data directly within an EAP method, it
MUST be able to carry integrity protected data from the
EAP peer to server. EAP methods SHOULD provide a
mechanism to carry protected data from server to peer.
EAP methods MUST exchange channel binding data with the AAA
subsystem hosting the EAP server. EAP methods MUST be able to
import channel binding data from the lower layer on the
EAP peer.</t>
</section>
</section>
<!-- ******************************************************************** -->
<section anchor="l2bindings" title="Channel Binding TLV">
<t>This section defines some channel binding TLVs. While message i1 is not limited to AAA attributes, for the sake of tangible attributes that are already in place, this
section discusses AAA AVPs that are appropriate for carrying channel bindings (i.e. data from i1 in
<xref target="chbp"/>). In particular, attributes for IEEE
802.11 are provided, which can be used as a template for developing
bindings for other EAP lower-layer protocols. </t>
<t>For any lower-layer protocol, network information of
interest to the peer and server can be encapsulated in AVPs or other defined payload containers.
The appropriate AVPs depend on the lower layer protocol as
well as on the network type (i.e. enterprise network or
service provider network) and its application. Additional TLV types can be defined beyond AAA AVPs. For example it may be useful to define TLVs that can carry 802.11 information elements. </t>
<section title="Requirements for Lower-Layer Bindings">
<t>Lower-layer protocols MUST support EAP in order to
support EAP channel bindings. These lower layers MUST
support EAP methods that derive keying material, as
otherwise no integrity-protected channel would be
available to execute the channel bindings protocol.
Lower-layer protocols need not support traffic encryption,
since this is independent of the authentication phase.
</t>
<t>Any binding value that is communicated in AAA MUST be encoded as a Diameter AVP. The data conveyed within
the AVP type MUST NOT conflict with the externally-defined
usage of the AVP. Additional TLV types SHOULD be defined for values that are not communicated within AAA attributes.</t>
</section>
<section title="General Attributes">
<t>This section lists AAA AVPs useful to all link-layers. The peer SHOULD transmit to the server the following
fields, encapsulated within the appropriate Diameter
AVPs:</t>
<t><list style="hanging">
<t hangText="NAS-Port-Type:">
Indicates the underlying link-layer technology used to
connect (e.g. IEEE 802.11, PPP, etc), and SHOULD be
included by the EAP peer, and SHOULD be verified
against the database and NAS-Port-Type received from
the NAS. <vspace blankLines="1"/></t>
<t hangText="Cost-Information:"> AVP from the Diameter
Credit-Control Application <xref target="RFC4006" />
to the peer indicating how much peers will be billed
for service and MAY be included by the EAP peer and
verified against roaming profiles stored in the
database.</t>
</list></t>
</section>
<section title="IEEE 802.11">
<t>The peer SHOULD transmit to the server the following
fields, encapsulated within the appropriate Diameter
AVPs:</t>
<t><list style="hanging">
<t hangText="Called-Station-Id:">
contains BSSID and SSID and SHOULD be verified against the
database and Called-Station-Id received from the NAS
<vspace blankLines="1"/></t>
</list></t>
<section title="IEEE 802.11r">
<t>In addition to the AVPs for IEEE 802.11, an IEEE
802.11r client SHOULD transmit the following additional
field:</t>
<t><list style="hanging">
<t hangText="Mobility-Domain-Id:"> contains the identity of the
mobility domain and SHOULD be verified against the database
and Mobility-Domain-Id received from the NAS
<xref target="I-D.aboba-radext-wlan"/></t>
</list></t>
</section>
</section>
</section>
<!-- ******************************************************************** -->
<section anchor="aaabind" title="AAA-Layer Bindings">
<t>This section discusses which AAA attributes in a AAA
Accept-Request messages can and should be validated by a AAA
server (i.e. data from i2 in <xref target="chbp"/>).
As noted before, this data can be manipulated by AAA proxies
either to enable functionality (e.g. removing realm
information after messages have been proxied) or maliciously
(e.g. in the case of a lying provider). As such, this data
cannot always be easily validated. However as thorough of a
validation as possible should be conducted in an effort to
detect possible attacks.</t>
<t><list style="hanging">
<t hangText="User-Name:"> This value should be checked for
consistency with the database and any method-specific
user information. If EAP method identity protection is
employed, this value typically contains a pseudonym or
keyword. <vspace blankLines="1"/></t>
<t hangText="NAS-IP-Address:"> This value is typically the
IP address of the authenticator, but in a proxied
connection it likely will not match the source IP
address of an Access-Request. A consistency check MAY
verify the subnet of the IP address was correct based on
the last-hop proxy. <vspace blankLines="1"/></t>
<t hangText="NAS-IPv6-Address:"> This value is typically
the IPv6 address of the authenticator, but in a proxied
connection it likely will not match the source IPv6
address of an Access-Request. A consistency check MAY
verify the subnet of the IPv6 address was correct based
on the last-hop proxy. <vspace blankLines="1"/></t>
<t hangText="Called-Station-Id:"> This is typically the
MAC address of the NAS. On an enterprise network, it
MAY be validated against the MAC address is one that has
been provisioned on the network.
<vspace blankLines="1"/></t>
<t hangText="Calling-Station-Id:"> This is typically the
MAC address of the EAP peer, and verification of this
is likely difficult, unless EAP credentials have been
provisioned on a per-host basis to specific L2
addresses. It SHOULD be validated against the database
in an enterprise deployment.
<vspace blankLines="1"/></t>
<t hangText="NAS-Identifier:"> This is an identifier
populated by the NAS, and could be related to the MAC
address, and should be validated similarly to the
Called-Station-Id. <vspace blankLines="1"/></t>
<t hangText="NAS-Port-Type:"> This specifies the
underlying link technology. It SHOULD be validated
against the value received from the peer in the
information exchange, and against a database of
authorized link-layer technologies.</t>
</list></t>
</section>
<!-- ******************************************************************** -->
<section anchor="seccons" title="Security Considerations">
<t>This section discusses security considerations
surrounding the use of EAP channel bindings.</t>
<section anchor="trustmodel" title="Trust Model">
<t>In the considered trust model, EAP peer and authentication server are honest while the
authenticator is maliciously sending false information to
peer and/or server. In the model, the peer and server
trust each other, which is not an unreasonable assumption, considering
they already have a trust relationship. The following are the trust
relationships:</t>
<t><list style="symbols">
<t>The server trusts that the channel binding information
received from the peer is the information that the peer received from the authenticator.</t>
<t>The peer trusts the channel binding result received from
the server.</t>
<t>The server trusts the information contained within its
local database.</t>
</list></t>
<t>In order to establish the first two trust relationships during
an EAP execution, an EAP method needs to provide the following:</t>
<t><list style="symbols">
<t>mutual authentication between peer and server</t>
<t>derivation of keying material including a key for
integrity protection of channel binding messages</t>
<t>sending i1 from peer to server over an
integrity-protected channel</t>
<t>sending the result and optionally i2 from server to
peer over an integrity-protected channel</t>
</list></t>
</section>
<section title="Consequences of Trust Violation">
<t>If any of the trust relationships listed in <xref target="trustmodel"/> are
violated, channel binding cannot be provided. In other
words, if mutual authentication with key establishment as
part of the EAP method as well as protected database access
are not provided, then achieving channel binding is not
feasible.</t>
<t>Dishonest peers can only manipulate the first message i1 of
the channel binding protocol. In this scenario, a peer
sends i1’ to the server. If i1’ is invalid, the channel
binding validation will fail. On the other hand if i1’ passes the
validation, either the original i1 was wrong and i1’
corrected the problem or both i1 and i1’ constitute valid
information. A peer could potentially gain an advantage
in auditing or charging if both are valid and information
from i1 is used for auditing or charging. Such peers can
be detected by including the information in i2 and
checking i1 against i2.</t>
<t>Dishonest servers can send EAP-Failure messages and abort
the EAP authentication even if the received i1 is valid.
However, servers can always abort any EAP session
independent of whether channel binding is offered or not.
On the other hand, dishonest servers can claim a successful
validation even if i1 contains invalid information. This can be seen as
collaboration of authenticator and server. Channel binding
can neither prevent nor detect such attacks. In general
such attacks cannot be prevented by cryptographic means and
should be addressed using policies making servers liable for
their provided information and services.</t>
<t>Additional network entities (such as proxies) might be on
the communication path between peer and server and may
attempt to manipulate the channel binding protocol. If these
entities do not possess the keying material used for
integrity protection of the channel binding messages, the
same threat analysis applies as for the dishonest
authenticators. Hence, such entities can neither manipulate
single channel binding messages nor the outcome. On the
other hand, entities with access to the keying material must
be treated like a server in a threat analysis. Hence such
entities are able to manipulate the channel binding protocol
without being detected. However, the required knowledge of
keying material is unlikely since channel binding is
executed before the EAP method is completed, and thus before
keying material is typically transported to other
entities.</t>
</section>
<section title="Privacy Violations">
<t>While the channel binding information exchanged between EAP
peer and EAP server (i.e. i1 and the optional result
message) must always be integrity-protected it may not be
encrypted. In the case that these messages contain
identifiers of peer and/or network entities, the privacy
property of the executed EAP method may be violated. Hence,
in order to maintain the privacy of an EAP method, the
exchanged channel binding information must be encrypted.
If encryption is not available, private information is not sent as part of the channel binding information, as described in
<xref target="req_tranport"/>. </t>
</section>
</section>
<!-- ******************************************************************** -->
<section anchor="OMcons" title="Operations and Management Considerations">
<t>As with any extension to existing protocols, there will be an
impact on existing systems. Typically the goal is to develop
an extension that minimizes the impact on both development and
deployment of the new system, subject to the system
requirements. This section discusses the impact on
existing devices that currently utilize EAP, assuming the
channel binding information is transported within the EAP
method execution.</t>
<t>The EAP peer will need an API between the EAP lower layer and
the EAP method that exposes the necessary information from the
NAS to be validated to the EAP peer, which can then feed that
information into the EAP methods for transport. For example,
an IEEE 802.11 system would need to make available the various
information elements that require validation to the EAP peer
which would properly format them and pass them to the EAP
method. Additionally, the EAP peer will require updated EAP
methods that support transporting channel binding information.
While most method documents are written modularly to allow
incorporating arbitrary protected information, implementations
of those methods would need to be revised to support these
extensions. Driver updates are also required so methods can
access the required information.</t>
<t>No changes to the pass-through authenticator would be
required.</t>
<t>The EAP server would need an API between the database storing
NAS information and the individual EAP server. The database may exist already exist on the AAA server in which case the EAP server
passes the parameters to the AAA server for validation. The EAP
methods need to be able to export received channel binding
information to the EAP server so it can be validated.</t>
</section>
<!-- ******************************************************************** -->
<section anchor="ianacons" title="IANA Considerations">
<t>This document contains no IANA considerations.</t>
</section>
<section title="Acknowledgements">
<t> The authors and editor would like to thank Bernard Aboba,
Glen Zorn, Joe Salowey, and Klaas Wierenga for their valuable inputs that helped to improve and shape this
document over the time.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3748;
</references>
<references title="Informative References">
&I-D.aboba-radext-wlan;
<reference anchor="I-D.clancy-emu-aaapay">
<front>
<title>EAP Method Support for Transporting AAA Payloads</title>
<author initials="T." surname="Clancy">
<organization/>
</author>
<author initials="A." surname="Lior">
<organization/>
</author>
<author role="editor" initials="G." surname="Zorn">
<organization/>
</author>
<date month="May" year="2009"/>
</front>
<seriesInfo name="Internet Draft" value="draft-clancy-emu-aaapay-02" />
</reference>
&RFC4006;
&RFC4017;
&RFC5056;
<reference anchor="HC07">
<front>
<title>Where EAP Security Claims Fail</title>
<author initials="K." surname="Hoeper">
<organization/>
</author>
<author initials="L." surname="Chen">
<organization/>
</author>
<date month="August" year="2007"/>
</front>
<seriesInfo name="ICST" value="QShine" />
</reference>
<reference anchor="80211U-D4.01">
<front>
<title>
Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications - Amendment 7: Interworking
with External Networks</title>
<author>
<organization/>
</author>
<date month="November" year="2008"/>
</front>
<seriesInfo name="IEEE" value="Draft Standard 802.11u" />
</reference>
</references>
<section title="Attacks Prevented by Channel Bindings">
<t>In the following it is demonstrated how the presented channel
bindings can prevent attacks by malicious authenticators
(representing the lying NAS problem) as well as malicious
visited networks (representing the lying provider
problem).</t>
<section title="Enterprise Subnetwork Masquerading">
<t>As outlined in <xref target="probstate"/>, an enterprise network may have
multiple VLANs providing different levels of security. In an
attack, a malicious NAS connecting to a guest network with
lesser security protection could broadcast the SSID of a
subnetwork with higher protection. This could lead peers
to believe that they are accessing the network over secure
connections, and, e.g., transmit confidential information
that they normally would not send over a weakly protected
connection. This attack works under the conditions that
peers use the same set of credentials to authenticate to
the different kinds of VLANs and that the VLANs support at
least one common EAP method. If these conditions are not
met, the EAP server would not authorize the peers to
connect to the guest network, because the peers used
credentials and/or an EAP method that is associated with the
corporate network.</t>
</section>
<section title="Forced Roaming">
<t>Mobile phone providers boosting their cell tower's
transmission power to get more users to use their networks
have occurred in the past. The increased transmission range
combined with a NAS sending a false network identity lures
users to connect to the network without being aware of that
they are roaming. </t>
<t>Channel bindings would detect the bogus network identifier
because the network identifier send to the authentication
server in i1 will neither match information i2 nor the
stored data. The verification fails because the info in i1
claims to come from the peer’s home network while the home
authentication server knows that the connection is through a
visited network outside the home domain. In the same
context, channel bindings can be utilized to provide a "home
zone" feature that notifies users every time they are about
to connect to a NAS outside their home domain.</t>
</section>
<section title="Downgrading attacks">
<t>A malicious authenticator could modify the set of offered
EAP methods in its Beacon to force the peer to choose from
only the weakest EAP method(s) accepted by the
authentication server. For instance, instead of having a
choice between EAP-MD5-CHAP, EAP-FAST and some other
methods, the authenticator reduces the choice for the peer
to the weaker EAP-MD5-CHAP method. Assuming that weak EAP
methods are supported by the authentication server, such a
downgrading attack can enable the authenticator to attack
the integrity and confidentiality of the remaining EAP
execution and/or break the authentication and key
exchange. The presented channel bindings prevent such
downgrading attacks, because peers submit the offered EAP
method selection that they have received in the beacon as
part of i1 to the authentication server. As a result, the
authentication server recognizes the modification when
comparing the information to the respective information in
its policy database.</t>
</section>
<section title="Bogus Beacons in IEEE 802.11r">
<t>In IEEE 802.11r, the SSID is bound to the TSK
calculations, so that the TSK needs to be consistent with
the SSID advertised in an authenticator’s Beacon. While
this prevents outsiders from spoofing a Beacon it does not
stop a "lying NAS" from sending a bogus Beacon and
calculating the TSK accordingly.</t>
<t>By implementing channel bindings, as described in this
draft, in IEEE 802.11r, the verification by the
authentication server would detect the inconsistencies
between the information the authenticator has sent to the
peer and the information the server received from the
authenticator and stores in the policy database.</t>
</section>
<section title="Forcing false authorization in IEEE 802.11i">
<t>In IEEE 802.11i a malicious NAS can modify the beacon to
make the peer believe it is connected to a network
different from the on the peer is actually connected
to.</t>
<t>In addition, a malicious NAS can force an authentication
server into authorizing access by sending an incorrect
Called-Station-ID that belongs to an authorized NAS in the
network. This could cause the authentication server to
believe it had granted access to a different network or
even provider than the one the peer got access to.</t>
<t>Both attacks can be prevented by implementing channel
bindings, because the server can compare the information
that was sent to the peer, with information it received
from the authenticator during the AAA communication as
well as the information stored in the policy database.</t>
</section>
</section>
<section title="Change History">
<t>RFC editor, remove this section prior to publication.</t>
<section title="Changes since version 04">
<t><list style="symbols">
<t>Clarify examples in introduction.</t>
<t>In problem statement note that one EAP server may deal
with both enterprise and provider networks.</t>
<t>Update discussion of the architecture. Talk about
channel bindings as a mechanism to introduce levels of
trust.</t>
<t>Indicate that this document is focusing on EAP channel
bindings within methods while trying to do a better job of
describing the SAP approach in more detail.</t>
<t>Claim that we're using the encoding from
draft-clancy-emu-aaapay. The WG almost certainly doesn't
have consensus on this, but in the interest of actually
describing what the protocol might be like, it is a good
straw-man proposal.</t>
<t>Update protocol description.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:34:16 |