Network Working Group T. Clancy
Internet-Draft LTS
Intended status: Standards Track K. Hoeper
Expires: December 28, 2008 NIST
June 26, 2008
Channel Binding Support for EAP Methods
draft-clancy-emu-chbind-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines how to implement channel bindings for
Extensible Authentication Protocol (EAP) methods.
Clancy & Hoeper Expires December 28, 2008 [Page 1]
Internet-Draft EAP-CHBIND June 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 4
5. Channel Binding Protocol . . . . . . . . . . . . . . . . . . . 6
6. Lower-Layer Bindings . . . . . . . . . . . . . . . . . . . . . 7
6.1. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. IEEE 802.16 . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Internet Key Exchange v2 (IKEv2) . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Consequences of Trust Violation . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Clancy & Hoeper Expires December 28, 2008 [Page 2]
Internet-Draft EAP-CHBIND June 2008
1. Introduction
The so-called "lying NAS" problem is a well-documented problem with
the current Extensible Authentication Protocol (EAP) architecture
[RFC3748] when used in pass-through authenticator mode. Here, a
Network Access Server (NAS), or pass-through authenticator, may
authenticate to the backend AAA infrastructure using one set of
credentials, while representing contrary information to EAP clients.
A concrete example of this may be an IEEE 802.11 access point with a
security association to a particular AAA server. While there may be
some identity tied to that security association, there's no reason
the access point needs to advertise the same identity to clients. In
fact, it may include whatever information in its beacons (e.g.
different SSID or security properties) it desires. This could lead
to situations where, for example, a client joins one network that is
masquerading as another.
In this document, we utilize "AAA Payloads" [I-D.clancy-emu-aaapay]
to transport key channel binding characteristics from the client to
the server, allowing the server to verify the authenticator has
advertised valid information to the peer. The server can also
respond back with additional information that could be useful for the
client to decide whether or not to continue its session with the
authenticator.
2. Terminology
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 [RFC2119].
3. Problem Statement
In a [RFC4017] and [RFC4962]-compliant EAP authentication, the EAP
client 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 client in an effort to affect its operation in
some way. Additionally, while an authenticator may not be
compromised, other compromised elements in the network could provide
false information to the authenticator that it could simply be
relaying to EAP clients. Our goal is to ensure that the
Clancy & Hoeper Expires December 28, 2008 [Page 3]
Internet-Draft EAP-CHBIND June 2008
authenticator is providing correct information to the EAP client
during the initial network discovery, selection, and authentication.
There are two different types of networks to consider: enterprise
networks and service provider networks. In enterprise networks, we
assume a single administrative domain, making it 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 client is outside
its home administrative domain, the goal is to ensure that the level
of service received by the client is consistent with the contractual
agreement between the two service providers.
The following are a couple example attacks possible by presenting
false network information to clients.
o Enterprise Network: A corporate network may have multiple virtual
LANs (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 clients to
connect to a network with a false sense of security regarding
their traffic.
o Service Provider Network: An EAP-enabled 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.
To address these problems, a mechanism is required to validate
unauthenticated information advertised by EAP authenticators.
4. Channel Bindings
EAP channel bindings seek to authenticate previously unauthenticated
information provided by the authenticator to the EAP peer, by
allowing the client and server to compare their perception of network
properties in a secure channel.
Clancy & Hoeper Expires December 28, 2008 [Page 4]
Internet-Draft EAP-CHBIND June 2008
It should be noted that the definition of EAP channel bindings
differs somewhat from regular channel bindings, documented in
[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 [RFC5056], EAP channel bindings do not ensure
the binding different layers of a session but rather the information
advertised to EAP client by an authenticator acting as pass-through
device during an EAP session.
There are two main approaches to EAP channel bindings:
o After keys have been derived during an EAP authentication, the
peer and server can, in an integrity-protected channel, exchange
plaintext information about the network with each other, and
verify consistency and correctness.
o Network information can be uniquely encoded into an opaque blob
that can be included directly in to the derivation of the EAP
session keys.
Both approaches have advantages and disadvantages. Advantages of
exchanging plaintext information include:
o It allows for fuzzy comparisons of network properties, rather than
requiring absolute comparisons. This allows for a broader
definition of consistency, rather than bitwise equality.
o EAP methods that support extensible, integrity-protected channels
can easily include support for exchanging this network
information. Direct inclusion into the key derivation would
require revisions to existing EAP methods or a wrapper EAP method.
o Given it doesn't affect the key derivation, exact use of the
results can be subject to policy, to facilitate debugging,
incremental deployment, and backward compatibility.
The following are advantages of directly including channel binding
information in the key derivation:
o 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.
o It can guarantee proper channel information, since subsequent
communication would be impossible if differences in channel
information yielded different session keys on the EAP client and
server.
Clancy & Hoeper Expires December 28, 2008 [Page 5]
Internet-Draft EAP-CHBIND June 2008
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 you expect your home EAP server to
know about the authenticator and/or network to which you are
connected. In roaming cases, they are likely to only know
information contained in their roaming agreements.
Also, a peer's expectations of a network may also differ. 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.
Any deployment of channel bindings should take into consideration
both what knowledge the EAP server is likely to know, and also what
type of network information the peer would want and need
authenticated.
5. Channel Binding Protocol
This section defines how to use "AAA Payloads"
[I-D.clancy-emu-aaapay] within EAP methods to implement channel
bindings. The protocol uses the approach where plaintext data is
exchanged, since it allows channel bindings to be used more flexibly
in varied deployment models.
---
-------- ------------- / \ ----------
|EAP peer|<---->|Authenticator|<-->( AAA )<-->|EAP Server|
-------- ------------- \ / ----------
. i1 . --- . | ______
.<-----------------. . | (______)
. . i1 . \--| |
.--------------------------------------------->. | DB |
. isConsistant(i1, i2), [i2] . | i2 |
.<---------------------------------------------. (______)
Figure 1: Overview of Channel Binding
Channel bindings are always provided between two communication
Clancy & Hoeper Expires December 28, 2008 [Page 6]
Internet-Draft EAP-CHBIND June 2008
endpoints, here the EAP client and server, who communicate through an
authenticator in pass-trough mode. During network advertisement,
selection, and authentication, the authenticator presents
unauthenticated information, labeled i1 for convenience, about the
network to the peer. As there is no established trust relationship
between the peer and authenticator, there is no way for the peer to
validate this information. Our goal is to transport i1 from the peer
to the server, and allow the server to validate it against
information i2 it has stored in its local database, labeled DB.
This information, i1, could include the identity of the authenticator
and the network it represents, in addition to advertised network
information such as offered services and roaming information. To
prevent attacks by rogue authenticators, the EAP server must be able
to verify that i1 either matches its knowledge of the network
(enterprise model) or is consistent with the contractual agreement
between itself and the roaming partner network to which the client is
connected (service provider model).
Note that in addition to just returning a validation result
indicating whether i1 and i2 are consistent, the EAP server can
optionally return i2 in its entirety. This would allow the EAP
server to provide additional, authenticated information about network
or authenticator to which the client has connected that the client
may wish to use in deciding whether the authenticator is authorized
to provide the type of service the client desires. This goes beyond
the general definition of channel binding, but allows for additional
flexibility.
The single round-trip exchange consists of a series of Diameter AVPs
formatted and encapsulated in EAP methods per
[I-D.clancy-emu-aaapay]. For each lower layer, this document defines
the parameters of interest, and the appropriate Diameter AVPs for
transporting them. Additionally, guidance on how to perform
consistency checks on those values will be provided.
6. Lower-Layer Bindings
This section discusses AVPs of some EAP-employing lower layer link
protocols that seem appropriate for providing channel bindings. The
discussion is limited to protocols that establish fresh authentic
keying material because such keying material is necessary to protect
the integrity of all AVPs that are exchanged as part of the channel
binding. For each protocol, a variety of network information that
can be encapsulated in AVPs is of interest for server and peer to
ensure channel binding. The respective appropriate AVPs depend on
the lower layer protocol as well as on the network type (i.e.
Clancy & Hoeper Expires December 28, 2008 [Page 7]
Internet-Draft EAP-CHBIND June 2008
enterprise network or service provider network) of an application.
For each EAP lower layer, a variety of AAA properties may be of
interest to the server. These values may already be known by the
server, or may be transported to the server via an existing RADIUS or
Diameter connection.
As part of the channel binding protocol, the EAP peer sends
encapsulated AVPs to the server. The server then validates the
received information by comparing it to information stored in a local
database. If the received information is unsatisfactory given some
validation policy, the server SHOULD respond by halting the EAP
authentication and returning an EAP-Failure.
If validation is successful, the server SHOULD send a message
indicating the success to the client. In addition, the server MAY
respond back to the EAP peer with information encapsulated in AVPs
that can be of use to the peer, and information the peer may not have
any way of otherwise knowing.
[[Note: Do we need to specify the SUCCESS message
(isConsistant(i1,i2) in Figure 1)?]]
6.1. IEEE 802.11
The client SHOULD transmit to the server the following fields,
encapsulated within the appropriate Diameter AVPs:
SSID
BSSID
RSN IE (if present)
The server MAY send the Cost-Information AVP from the Diameter
Credit-Control Application [RFC4006] to the peer indicating how much
peers will be billed for service.
6.2. IEEE 802.16
TBD
6.3. Internet Key Exchange v2 (IKEv2)
TBD
7. Security Considerations
Clancy & Hoeper Expires December 28, 2008 [Page 8]
Internet-Draft EAP-CHBIND June 2008
7.1. Trust Model
We consider a trust model in which the peer and server trust each
other. This is not unreasonable, considering they already have a
trust relationship. In this trust model, client and authentication
server are honest while the authenticator is maliciously sending
false information to client and/or server. The following are the
trust relationships:
o The server trusts that the channel binding information received
from the client is the information that the client received from
the authenticator.
o The client trusts the channel binding result received from the
server.
o The server trusts the information contained within its local
database.
In order to establish the first two trust relationships during an EAP
execution, an EAP method MUST provide the following:
o mutual authentication between client and server
o derivation of keying material including a key for integrity
protection of channel binding messages
o sending i1 from client to server over an integrity-protected
channel
o sending the result and optionally i2 from server to client over an
integrity-protected channel
7.2. Consequences of Trust Violation
If any of the trust relationships listed in Section 7.1 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.
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
and the server will abort the EAP authentication. 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. All cases do not seem to be of any benefit to a peer
and do no pose a security risk.
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
Clancy & Hoeper Expires December 28, 2008 [Page 9]
Internet-Draft EAP-CHBIND June 2008
binding is offered or not. On the other hand, dishonest servers can
claim a successful validation even for an invalid i1. 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.
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.
8. IANA Considerations
This document contains no IANA considerations.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
9.2. Informative References
[I-D.ietf-eap-keying]
Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress),
November 2007.
Clancy & Hoeper Expires December 28, 2008 [Page 10]
Internet-Draft EAP-CHBIND June 2008
[I-D.clancy-emu-aaapay]
Clancy, T., "EAP Method Support for Transporting AAA
Payloads", Internet Draft draft-clancy-emu-aaapay-00,
December 2007.
[HC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail",
ICST QShine, August 2007.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
Loughney, "Diameter Credit-Control Application", RFC 4006,
August 2005.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
Authors' Addresses
T. Charles Clancy
Laboratory for Telecommunications Sciences
US Department of Defense
College Park, MD
USA
Email: clancy@ltsnet.net
Katrin Hoeper
National Institute of Standards and Technology
100 Bureau Drive, mail stop 8930
Gaithersburg, MD 20878
USA
Email: khoeper@nist.gov
Clancy & Hoeper Expires December 28, 2008 [Page 11]
Internet-Draft EAP-CHBIND June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Clancy & Hoeper Expires December 28, 2008 [Page 12]