GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6677

Internet Engineering Task Force (IETF) S. Hartman, Ed. Request for Comments: 6677 Painless Security Category: Standards Track T. Clancy ISSN: 2070-1721 Virginia Tech

                                                             K. Hoeper
                                              Motorola Solutions, Inc.
                                                             July 2012
                      Channel-Binding Support
        for Extensible Authentication Protocol (EAP) Methods

Abstract

 This document defines how to implement channel bindings for
 Extensible Authentication Protocol (EAP) methods to address the
 "lying Network Access Service (NAS)" problem as well as the "lying
 provider" problem.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6677.

Hartman, et al. Standards Track [Page 1] RFC 6677 EAP Channel Binding July 2012

Copyright Notice

 Copyright (c) 2012 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Hartman, et al. Standards Track [Page 2] RFC 6677 EAP Channel Binding July 2012

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
 3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
 4.  Channel Bindings . . . . . . . . . . . . . . . . . . . . . . .  7
   4.1.  Types of EAP Channel Bindings  . . . . . . . . . . . . . .  8
   4.2.  Channel Bindings in the Secure Association Protocol  . . .  9
   4.3.  Channel-Binding Scope  . . . . . . . . . . . . . . . . . . 10
 5.  Channel-Binding Process  . . . . . . . . . . . . . . . . . . . 12
   5.1.  Protocol Operation . . . . . . . . . . . . . . . . . . . . 12
   5.2.  Channel-Binding Consistency Check  . . . . . . . . . . . . 14
   5.3.  EAP Protocol . . . . . . . . . . . . . . . . . . . . . . . 15
     5.3.1.  Channel-Binding Codes  . . . . . . . . . . . . . . . . 17
     5.3.2.  Namespace Identifiers  . . . . . . . . . . . . . . . . 17
     5.3.3.  RADIUS Namespace . . . . . . . . . . . . . . . . . . . 18
 6.  System Requirements  . . . . . . . . . . . . . . . . . . . . . 18
   6.1.  General Transport Protocol Requirements  . . . . . . . . . 18
   6.2.  EAP Method Requirements  . . . . . . . . . . . . . . . . . 19
 7.  Channel-Binding TLV  . . . . . . . . . . . . . . . . . . . . . 19
   7.1.  Requirements for Lower-Layer Bindings  . . . . . . . . . . 19
   7.2.  EAP Lower-Layer Attribute  . . . . . . . . . . . . . . . . 20
 8.  AAA-Layer Bindings . . . . . . . . . . . . . . . . . . . . . . 20
 9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   9.1.  Trust Model  . . . . . . . . . . . . . . . . . . . . . . . 21
   9.2.  Consequences of Trust Violation  . . . . . . . . . . . . . 23
   9.3.  Bid-Down Attacks . . . . . . . . . . . . . . . . . . . . . 24
   9.4.  Privacy Violations . . . . . . . . . . . . . . . . . . . . 24
 10. Operations and Management Considerations . . . . . . . . . . . 25
 11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   11.1. EAP Lower Layers Registry  . . . . . . . . . . . . . . . . 26
   11.2. RADIUS Registration  . . . . . . . . . . . . . . . . . . . 26
 12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   13.1. Normative References . . . . . . . . . . . . . . . . . . . 27
   13.2. Informative References . . . . . . . . . . . . . . . . . . 27
 Appendix A.  Attacks Prevented by Channel Bindings . . . . . . . . 29
   A.1.  Enterprise Subnetwork Masquerading . . . . . . . . . . . . 29
   A.2.  Forced Roaming . . . . . . . . . . . . . . . . . . . . . . 29
   A.3.  Downgrading Attacks  . . . . . . . . . . . . . . . . . . . 30
   A.4.  Bogus Beacons in IEEE 802.11r  . . . . . . . . . . . . . . 30
   A.5.  Forcing False Authorization in IEEE 802.11i  . . . . . . . 30

Hartman, et al. Standards Track [Page 3] RFC 6677 EAP Channel Binding July 2012

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
 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.
 This problem results when the same credentials are used to access
 multiple services that differ in some interesting property.  The EAP
 server learns which client credentials are in use.  The client knows
 which EAP credentials are used, but cannot distinguish between
 servers that use those credentials.  For methods that distinguish
 between client and server credentials, either using different server
 credentials for access to the different services or having client
 credentials with access to a disjoint set of services can potentially
 defend against the attack.
 As a concrete example, consider an organization with two different
 IEEE 802.11 wireless networks.  One is a relatively low-security
 network for accessing the web, while the other has access to valuable
 confidential information.  An access point on the web network could
 act as a lying NAS, sending the Service Set Identifier (SSID) of the
 confidential network in its beacons.  This access point could gain an
 advantage by doing so if it tricks clients that intend to connect to
 the confidential network to connect to it and disclose confidential
 information.
 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
 falsely advertised roaming rates.  This is referred to as the "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 also gain access to traffic that it might not
 otherwise see.
 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 gives information about the characteristics of the
 service provided by the authenticator to the AAA server protected

Hartman, et al. Standards Track [Page 4] RFC 6677 EAP Channel Binding July 2012

 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 [AAA-PAY] served as the starting point for the mechanism proposed
 in this specification to carry this information.

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 an EAP authentication compliant with [RFC4017], 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 both in terms of
 network distance and number of entities who need to be trusted in
 order to establish trusted communication.  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.
 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.

Hartman, et al. Standards Track [Page 5] RFC 6677 EAP Channel Binding July 2012

 The following are example attacks possible by presenting false
 network information to peers.
 o  Enterprise network: A corporate network may have multiple virtual
    LANs (VLANs) available 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 but not the corporate
    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.
 o  Enterprise network: The EAP Generic Security Service Application
    Program Interface (GSS-API) mechanism [GSS-API-EAP] mechanism
    provides a way to use EAP to authenticate to mail servers, instant
    messaging servers, and other non-network services.  Without EAP
    channel binding, an attacker could trick the user into connecting
    to a relatively untrusted service instead of a relatively trusted
    service.  For example, the instant messaging service could
    impersonate the mail server.
 o  Service provider network: An EAP-enabled mobile phone provider
    could advertise 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 geopolitical 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
    the "lying provider" problem, because here the provider configures
    its NAS to broadcast false information.  For the purpose of
    channel bindings as defined in this document, 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

Hartman, et al. Standards Track [Page 6] RFC 6677 EAP Channel Binding July 2012

    detection of inconsistencies in the information from a visited
    network, but cannot enable the determination of which entity is
    lying.  Naturally, channel bindings for EAP methods can only
    verify the endpoints; if desirable, intermediate hops need to be
    protected by the employed AAA protocol.
 o  Enterprise and provider networks: In a situation where an
    enterprise has 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.
    Today this could potentially be solved by using different
    credentials for internal and external access.  Depending on the
    type of credential, this may introduce usability or man-in-the-
    middle security issues.
 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 peer and server to compare their perception of network properties
 in a secure channel.
 It should be noted that the definition of EAP channel bindings
 differs somewhat from channel bindings documented in [RFC5056], which
 seek to securely bind together the endpoints of a multi-layer
 protocol, allowing lower layers to protect data from higher layers.
 Unlike [RFC5056], EAP channel bindings do not ensure the binding of
 different layers of a session; rather, they ensure the accuracy of
 the information advertised to an EAP peer by an authenticator acting
 as the pass-through device during an EAP execution.  The term
 "channel bindings" was independently adopted for these two related
 concepts; by the time the conflict was discovered, a wide body of
 literature existed for each usage.  EAP channel bindings could be
 used to provide [RFC5056] channel bindings.  In particular, an inner
 EAP method could be bound to an outer method by including the
 [RFC5056] channel-binding data for the outer channel in the inner EAP
 method's channel bindings.  Doing so would provide a facility similar
 to EAP cryptographic binding, except that a man-in-the-middle could
 not extract the inner method from the tunnel.  This specification
 does not weigh the advantages of doing so nor specify how to do so;
 the example is provided only to illustrate how EAP channel binding
 and [RFC5056] channel binding overlap.

Hartman, et al. Standards Track [Page 7] RFC 6677 EAP Channel Binding July 2012

4.1. Types of EAP Channel Bindings

 There are two categories of approach to EAP channel bindings:
 o  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.
 o  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.
 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:
 o  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.
 o  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.
 o  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 effect 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.
 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.

Hartman, et al. Standards Track [Page 8] RFC 6677 EAP Channel Binding July 2012

 o  It can guarantee proper channel information, since subsequent
    communication would be impossible if differences in channel
    information yield different session keys on the EAP peer and
    server.

4.2. Channel Bindings in the Secure Association Protocol

 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.
 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 or AAA 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.
 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 results of the
 secure association protocol change, every NAS needs to be upgraded to
 support channel bindings within the secure association protocol.
 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.  Sending channel bindings in the secure
 association protocol can work even with the EAP Re-authentication
 Protocol (ERP) [RFC5296] in which previously established EAP key
 material is used for the secure association protocol without carrying
 out any EAP method during re-authentication.

Hartman, et al. Standards Track [Page 9] RFC 6677 EAP Channel Binding July 2012

 If channel bindings using a secure association protocol are
 specified, semantics as well as the set of information that peers
 exchange can be shared with the mechanism described in this document.

4.3. Channel-Binding Scope

 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., Medium Access Control (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.
 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 after transformations performed by AAA
 proxies.  For example, information carried in AAA attributes such as
 the NAS IP address may have been lost in transition and thus are not
 known to the EAP server.  Even worse, information may still be
 available but be useless, for example, representing the identity of a
 device on a private network or a middlebox.  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, the
 best approach is 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.
 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, the administrators of a

Hartman, et al. Standards Track [Page 10] RFC 6677 EAP Channel Binding July 2012

 peer may be more concerned with specifics of where their network
 traffic is being routed and what VLAN is in use.  To establish
 policies surrounding these requirements, administrators would capture
 some attribute such as SSID to describe the properties of the network
 they care about.  Channel bindings could validate the SSID.  The
 administrator would need to make sure that the network guarantees
 that when an authenticator trusted by the AAA infrastructure to offer
 a particular SSID to clients does offer this SSID, that network has
 the intended properties.  Generally, it is not possible for channel
 bindings to detect lying NAS behavior when the NAS is authorized to
 claim a particular service.  That is, if the same physical
 authenticator is permitted to advertise two networks, the AAA
 infrastructure is unlikely to be able to determine when this
 authenticator lies.
 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 that a particular
 access point is expected to advertise comes from configuration rather
 than an AAA exchange (which can be confirmed with channel binding).
 The peer and authenticator do not initially have a basis for trust.
 The peer has a credential with the EAP server that forms a basis for
 trust.  The EAP server and authenticator have a potentially indirect
 trust path using the AAA infrastructure.  Channel binding leverages
 the trust between the peer and EAP server to build trust in certain
 attributes between the peer and authenticator.
 Channel bindings can be important for forming areas 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.
 Any deployment of channel bindings should take into consideration
 both what information the EAP server is likely to know or have access
 to, and what type of network information the peer would want and need
 authenticated.

Hartman, et al. Standards Track [Page 11] RFC 6677 EAP Channel Binding July 2012

5. Channel-Binding Process

 This section defines the process 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
 Section 4.1).  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.  The third subsection describes the
 information carried in the EAP exchange.

5.1. Protocol Operation

 Channel bindings are always provided between two communication
 endpoints (here, the EAP peer and the EAP server), who communicate
 through an authenticator typically in pass-through mode.
 Specifications treat the AAA server and EAP server as distinct
 entities.  However, there is no standardized protocol for the AAA
 server and EAP server to communicate with each other.  For the
 channel-binding protocol presented in this document to work, the EAP
 server needs to be able to access information from the AAA server
 that is utilized during the EAP session (i2 below) and a local
 database.  For example, the EAP server and the local database can be
 co-located with the AAA server, as illustrated in Figure 1.  An
 alternate architecture would be to provide a mechanism for the EAP
 server to inform the AAA server what channel-binding attributes were
 supplied and the AAA server to inform the EAP server about what
 channel-binding attributes it considered when making its decision.
                                      + -------------------------+
   --------        -------------      |   ----------     ______  |
  |EAP peer|<---->|Authenticator|<--> |  |EAP Server|___(______) |
   --------        -------------      |   ----------    | DB   | |
      .                 .             |AAA              (______) |
      .       i1        .             +--------------------------+
      .<----------------.      i2     .       .
      .                 .------------>        .
      .                  i1                   .
      .-------------------------------------->.
      .     CB_success/failure(i1, i2,info)   .
      .<--------------------------------------.
            Figure 1: Overview of Channel-Binding Protocol

Hartman, et al. Standards Track [Page 12] RFC 6677 EAP Channel Binding July 2012

 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 (such as the type of media in use)
 may be communicated implicitly in i1.  As there is no established
 trust relationship between the peer and authenticator, there is no
 way for the peer to validate this information.
 Additionally, during the transaction the authenticator presents a
 number of information properties in the form of AAA attributes about
 itself and the current request.  These AAA attributes may or may not
 contain accurate information.  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.
 AAA hops between the authenticator and AAA server can validate some
 of i2.  Whether the AAA server will be able to rely on this depends
 significantly on the business relationship executed with these
 proxies and on the structure of the AAA network.
 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 IEEE 802.11 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.
 During an EAP method execution with channel bindings, the peer sends
 i1 to the EAP server using the mechanism described in Section 5.3.
 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 includes the attributes that were used in the check.  The
 message flow is illustrated in Figure 1.
 Above, the EAP server is described as performing the channel-binding
 validation.  In most deployments, this will be a necessary
 implementation constraint.  The EAP exchange needs to include an
 indication of channel-binding success or failure.  Most existing
 implementations do not have a way to have an exchange between the EAP

Hartman, et al. Standards Track [Page 13] RFC 6677 EAP Channel Binding July 2012

 server and another AAA entity during the EAP server's processing of a
 single EAP message.  However, another AAA entity can provide
 information to the EAP server to make its decision.
 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.  If i1 or i2 does not comply with policy, the EAP
 server MUST NOT list information that failed to comply in the set of
 information used to perform channel binding.  In this case, the EAP
 server SHOULD indicate channel-binding failure; this requirement may
 be upgraded to a MUST in the future.

5.2. Channel-Binding Consistency Check

 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:
 1.  the authenticator is lying to the peer, i.e., i1 contains false
     information, and
 2.  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.
 These checks enable the EAP server to detect lying NASes or
 authenticators in enterprise networks and lying providers in service
 provider networks.
 Checking the consistency of i1 and i2 is nontrivial, as has been
 pointed out already in [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 types 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 against values propagated by

Hartman, et al. Standards Track [Page 14] RFC 6677 EAP Channel Binding July 2012

 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.
 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 been
 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.
 Section 7 describes lower-layer-specific properties that can be
 exchanged as a part of i1.  Section 8 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 Section 10.

5.3. EAP Protocol

 EAP methods supporting channel binding consistent with this
 specification provide a mechanism for carrying channel-binding data
 from the peer to the EAP server and a channel-binding response from
 the EAP server to the peer.  The specifics of this mechanism are
 dependent on the method, although the content of the channel-binding
 data and channel-binding response are defined by this section.
 Typically the lower layer will communicate a set of attributes to the
 EAP implementation on the peer that should be part of channel
 binding.  The EAP implementation may need to indicate to the lower
 layer that channel-binding information cannot be sent.  Reasons for
 failing to send channel-binding information include an EAP method
 that does not support channel binding is selected, or channel-binding
 data is too big for the EAP method selected.  Peers SHOULD provide
 appropriate policy controls to select channel binding or mandate its
 success.
 The EAP server receives the channel-binding data and performs the
 validation.  The EAP method provides a way to return a response; the
 channel-binding response uses the same basic format as the channel-
 binding data.

Hartman, et al. Standards Track [Page 15] RFC 6677 EAP Channel Binding July 2012

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Code      |             Length            |      NSID     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       NS-Specific...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Length            |      NSID     | NS-Specific...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 2: Channel-Binding Encoding
 Both the channel-binding data and response use the format illustrated
 in Figure 2.  The protocol starts with a one-byte code; see
 Section 5.3.1.  Then, for each type of attribute contained in the
 channel-binding data, the following information is encoded:
 Length:  Two octets of length in network byte order, indicating the
    length of the NS-Specific data.  The NSID and length octets are
    not included.
 NSID:  Namespace identifier.  One octet describing the namespace from
    which the attributes are drawn.  See Section 5.3.3 for a
    description of how to encode RADIUS attributes in channel-binding
    data and responses.  RADIUS uses a namespace identifier of 1 .
 NS-Specific:  The encoding of the attributes in a manner specific to
    the type of attribute.
 A given NSID MUST NOT appear more than once in a channel-binding data
 or channel-binding response.  Instead, all NS-Specific data for a
 particular NSID must occur inside one set of fields (NSID, Length,
 and NS-Specific).  This set of fields may be repeated if multiple
 namespaces are included.
 In channel-binding data, the code is set to 1 (channel-binding data),
 and the full attributes and values that the peer wishes the EAP
 server to validate are included.
 In a channel-binding response, the server selects the code; see
 Section 5.3.1.  For successful channel binding, the server returns
 code 2.  The set of attributes that the EAP server returns depend on
 the code.  For success, the server returns the attributes that were
 considered by the server in making the determination that channel
 bindings are successfully validated; attributes that the server is
 unable to check or that failed to validate against what is sent by

Hartman, et al. Standards Track [Page 16] RFC 6677 EAP Channel Binding July 2012

 the peer MUST NOT be returned in a success response.  Generally,
 servers will not return a success response if any attributes were
 checked and failed to validate those specified by the peer.  Special
 circumstances such as a new attribute being phased in at a server MAY
 require servers to return success when such an attribute fails to
 validate.  The server returns the value supplied by the peer when
 returning an attribute in channel-binding responses.
 For channel-binding failure (code 3), the server SHOULD include any
 attributes that were successfully validated.  This code means that
 server policy indicates that the attributes sent by the client do not
 accurately describe the authenticator.  Servers MAY include no
 attributes in this response; for example, if the server checks the
 attributes supplied by the peer and they fail to be consistent, it
 may send a response without attributes.
 Peers MUST treat unknown codes as channel-binding failure.  Peers
 MUST ignore differences between attribute values sent in the channel-
 binding data and those sent in the response.  Peers and servers MUST
 ignore any attributes contained in a field with an unknown NSID.
 Peers MUST ignore any attributes in a response not present in the
 channel-binding data.

5.3.1. Channel-Binding Codes

             +------+-----------------------------------+
             | Code | Meaning                           |
             +------+-----------------------------------+
             | 1    | Channel-binding data from client  |
             | 2    | Channel-binding response: success |
             | 3    | Channel-binding response: failure |
             +------+-----------------------------------+

5.3.2. Namespace Identifiers

          +-----+--------------------------+---------------+
          | ID  | Namespace                | Reference     |
          +-----+--------------------------+---------------+
          | 1   | RADIUS                   | Section 5.3.3 |
          | 255 | Reserved for Private Use |               |
          +-----+--------------------------+---------------+

Hartman, et al. Standards Track [Page 17] RFC 6677 EAP Channel Binding July 2012

5.3.3. RADIUS Namespace

 RADIUS attribute-value pairs (AVPs) are encoded with a one-octet
 attribute type followed by a one-octet length followed by the value
 of the RADIUS attribute being encoded.  The length includes the type
 and length octets; the minimum legal length is 3.  Attributes are
 concatenated to form the namespace-specific portion of the packet.
     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
    |     Type      |    Length     |  Value ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
                     Figure 3: RADIUS AVP Encoding
 The full value of an attribute is included in the channel-binding
 data and response.

6. System Requirements

 This section defines requirements on components used to implement the
 channel-bindings protocol.
 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 Section 4.2, an alternative approach for meeting this
 requirement is to perform channel bindings during the secure
 association protocol of the lower layer.

6.1. General Transport Protocol Requirements

 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 is 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.
 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

Hartman, et al. Standards Track [Page 18] RFC 6677 EAP Channel Binding July 2012

 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 - Generalized
 Pre-Shared Key (EAP-GPSK) is used as the authentication method, and
 maximal-length identities are used, a maximum of 384 octets is
 available for conveying channel-binding information.  Other methods,
 such as EAP Tunneled Transport Layer Security (EAP-TTLS), support
 fragmentation and could carry significantly longer payloads.

6.2. EAP Method Requirements

 When transporting data directly within an EAP method, the method MUST
 be able to carry integrity-protected data from the EAP peer to server
 and from EAP 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.

7. Channel-Binding TLV

 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
 Section 5).
 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.

7.1. Requirements for Lower-Layer Bindings

 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.
 The data conveyed within the AVP type MUST NOT conflict with the
 externally defined usage of the AVP.  Additional TLV types MAY be
 defined for values that are not communicated within AAA attributes.
 In general, lower layers will need to specify what information should
 be included in i1.  Existing lower layers will probably require new
 documents to specify this information.  Lower-layer specifications

Hartman, et al. Standards Track [Page 19] RFC 6677 EAP Channel Binding July 2012

 need to include sufficient information in i1 to uniquely identify
 which lower layer is involved.  The preferred way to do this is to
 include the EAP-Lower-Layer attribute defined in the next section.
 This MUST be included in i1 unless an attribute specific to a
 particular lower layer is included in i1.

7.2. EAP Lower-Layer Attribute

 A new RADIUS attribute is defined to carry information on which EAP
 lower layer is used for this EAP authentication.  This attribute
 provides information relating to the lower layer over which EAP is
 transported.  This attribute MAY be sent by the NAS to the RADIUS
 server in an Access-Request or an Accounting-Request packet.  A
 summary of the EAP-Lower-Layer attribute format is shown below.  The
 fields are transmitted from left to right.
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |             Value
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value (cont.)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The code is 163, the length is 6, and the value is a 32-bit unsigned
 integer in network byte order.  The value specifies the EAP lower
 layer in use.  Values are taken from the IANA registry established in
 Section 11.1.

8. AAA-Layer Bindings

 This section discusses which AAA attributes in a AAA Access-Request
 message can and should be validated by a EAP server (i.e., data from
 i2 in Section 5).  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 to act 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.
 NAS-IP-Address:  This value is typically the IP address of the
    authenticator; however, 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.

Hartman, et al. Standards Track [Page 20] RFC 6677 EAP Channel Binding July 2012

 NAS-IPv6-Address:  This value is typically the IPv6 address of the
    authenticator; however, 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.
 NAS-Identifier:  This is an identifier populated by the NAS to
    identify the NAS to the AAA server; it SHOULD be validated against
    the local database.
 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.

9. Security Considerations

 This section discusses security considerations surrounding the use of
 EAP channel bindings.

9.1. Trust Model

 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:
 o  The server trusts that the channel-binding information received
    from the peer is the information that the peer received from the
    authenticator.
 o  The peer 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 peer and server
 o  derivation of keying material including a key for integrity
    protection of channel-binding messages known to the peer and EAP
    server but not the authenticator

Hartman, et al. Standards Track [Page 21] RFC 6677 EAP Channel Binding July 2012

 o  transmission of the channel-binding request from peer to server
    over an integrity-protected channel
 o  transmission of the channel-binding result from server to peer
    over an integrity-protected channel
 This trust model is a significant departure from the standard EAP
 model.  In many EAP deployments today, attacks where one
 authenticator can impersonate another are not a significant concern
 because all authenticators provide the same service.  A authenticator
 does not gain significant advantage by impersonating another
 authenticator.  The use of EAP in situations where different
 authenticators provide different services may give an attacker who
 can impersonate a authenticator greater advantage.  The system as a
 whole needs to be analyzed to evaluate cases where one authenticator
 may impersonate another and to evaluate the impact of this
 impersonation.
 One attractive implementation strategy for channel binding is to add
 channel-binding support to a tunnel method that can tunnel an inner
 EAP authentication.  This way, channel binding can be achieved with
 any method that can act as an inner method even if that inner method
 does not have native channel-binding support.  The requirement for
 mutual authentication and key derivation is at the layer of EAP that
 actually performs the channel binding.  Tunnel methods sometimes use
 cryptographic binding, a process where a peer proves that the peer
 for the outer method is the same as the peer for an inner method to
 tie authentication at one layer together with an inner layer.
 Cryptographic binding does not always provide mutual authentication;
 its definition does not require the server to prove that the inner
 server and outer server are the same.  Even when cryptographic
 binding does attempt to confirm that the inner and outer server are
 the same, the Master Session Key (MSK) from the inner method is
 typically used to protect the binding.  An attacker such as an
 authenticator that wishes to subvert channel binding could establish
 an outer tunnel terminating at the authenticator.  If the outer
 method tunnel terminates on the authenticator, the MSK is disclosed
 to the authenticator, which can typically attack cryptographic
 binding.  If the authenticator controls cryptographic binding, then
 it typically controls the channel-binding parameters and results.  If
 the channel-binding process is used to differentiate one
 authenticator from another, then the authenticator can claim to
 support services that it was not authorized to.  This attack was not
 in scope for existing threat models for cryptographic binding because
 differentiated authenticators was not a consideration.  Thus,
 existing cryptographic binding does not typically provide mutual
 authentication of the inner-method server required for channel
 binding.  Other methods besides cryptographic binding are available

Hartman, et al. Standards Track [Page 22] RFC 6677 EAP Channel Binding July 2012

 to provide mutual authentication required by channel binding.  As an
 example, if server certificates are validated and names checked,
 mutual authentication can be provided directly by the tunnel.

9.2. Consequences of Trust Violation

 If any of the trust relationships listed in Section 9.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.
 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.
 If information from i1 does not validate, an EAP server cannot
 generally determine whether the authenticator advertised incorrect
 information or whether the peer is dishonest.  This should be
 considered before using channel-binding validation failures to
 determine the reputation either of the peer or authenticator.
 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 or not
 channel binding is offered.  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 that make 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 cannot manipulate a
 single channel-binding message or the outcome.  On the other hand,
 entities with access to the keying material must be treated like a

Hartman, et al. Standards Track [Page 23] RFC 6677 EAP Channel Binding July 2012

 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.

9.3. Bid-Down Attacks

 EAP methods that add channel binding will typically negotiate its
 use.  Even for entirely new EAP methods designed with channel binding
 from the first version, some deployments may not use it.  It is
 desirable to protect against attacks on the negotiation of channel
 bindings.  An attacker including the NAS SHOULD NOT be able to
 prevent a peer and server who support channel bindings from using
 them.
 Unfortunately, existing EAP methods may make it difficult or
 impossible to protect against attacks on negotiation.  For example,
 many EAP state machines will accept a success message at any point
 after key derivation to terminate authentication.  EAP success
 messages are not integrity protected; an attacker who could insert a
 message can generate one.  The NAS is always in a position to
 generate a success message.  Common EAP servers take advantage of
 state machines accepting success messages even in cases where an EAP
 method might support a protected indication of success.  It may be
 challenging to define channel-binding support for existing EAP
 methods in a manner that permits peers to distinguish an old EAP
 server that sends a success indication and does not support channel
 binding from an attacker injecting a success indication.

9.4. Privacy Violations

 While the channel-binding information exchanged between EAP peer and
 EAP server (i.e., i1 and the 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 Section 6.1.
 Privacy implications of attributes selected for channel binding need
 to be considered.  Consider channel binding the username attribute.
 A peer sends a privacy protecting anonymous identifier in its EAP
 identity message, but sends the full username in the protected i1
 message.  However, the authenticator would like to learn the full

Hartman, et al. Standards Track [Page 24] RFC 6677 EAP Channel Binding July 2012

 username.  It makes a guess and sends that in i2 rather than the
 anonymous identifier.  If the EAP server validates this attribute and
 fails when the username from the peer mismatches i2, then the EAP
 server confirms the authenticator's guess.  Similar privacy exposures
 may result whenever one party is in a position to guess channel-
 binding information provided by another party.

10. Operations and Management Considerations

 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.
 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.
 No changes to the pass-through authenticator would be required.
 The EAP server would need an API between the database storing NAS
 information and the individual EAP server.  The database may 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.

11. IANA Considerations

 A new top-level registry has been created for "Extensible
 Authentication Protocol (EAP) Channel Binding Parameters".  This
 registry consists of several sub-registries.

Hartman, et al. Standards Track [Page 25] RFC 6677 EAP Channel Binding July 2012

 The "EAP Channel-Binding Codes" sub-registry defines values for the
 code field in the channel-binding data and channel-binding response
 packet.  See the table in Section 5.3.1 for initial registrations.
 This registry requires Standards Action [RFC5226] for new
 registrations.  Early allocation [RFC4020] is allowed.  An additional
 reference column has been added to the table for the registry,
 pointing all codes in the initial registration to this specification.
 Valid values in this sub-registry range from 0-255; 0 is reserved.
 The "EAP Channel-Binding Namespaces" sub-registry contains
 registrations for the NSID field in the channel-binding data and
 channel-binding response.  Initial registrations are found in the
 table in Section 5.3.2.  Registrations in this registry require IETF
 Review.  Valid values range from 0-255; 0 is reserved.  As with the
 "EAP Channel-Binding Codes" sub-registry, a reference column has been
 included to point to this document for initial registrations.

11.1. EAP Lower Layers Registry

 A new sub-registry in the EAP Numbers registry at
 http://www.iana.org/assignments/eap-numbers has been created for EAP
 Lower Layers.  Registration requires Expert Review [RFC5226]; the
 primary role of the expert is to prevent multiple registrations for
 the same lower layer.
 The following table gives the initial registrations for this
 registry.
          +-------+----------------------------------------+
          | Value | Lower Layer                            |
          +-------+----------------------------------------+
          | 1     | Wired IEEE 802.1X                      |
          | 2     | IEEE 802.11 (no-pre-auth)              |
          | 3     | IEEE 802.11 (pre-authentication)       |
          | 4     | IEEE 802.16e                           |
          | 5     | IKEv2                                  |
          | 6     | PPP                                    |
          | 7     | PANA (no pre-authentication) [RFC5191] |
          | 8     | GSS-API [GSS-API-EAP]                  |
          | 9     | PANA (pre-authentication) [RFC5873]    |
          +-------+----------------------------------------+

11.2. RADIUS Registration

 A new RADIUS attribute is registered with the name EAP-Lower-Layer;
 163.  The RADIUS attributes are in the registry at
 http://www.iana.org/assignments/radius-types.

Hartman, et al. Standards Track [Page 26] RFC 6677 EAP Channel Binding July 2012

12. Acknowledgments

 The authors and editor would like to thank Bernard Aboba, Glen Zorn,
 Joe Salowey, Stephen Hanna, and Klaas Wierenga for their valuable
 inputs that helped to improve and shape this document over the time.
 Sam Hartman's work on this specification is funded by JANET(UK).
 The EAP-Lower-Layer attribute was taken from "RADIUS Attributes for
 IEEE 802 Networks" [RADIUS-WLAN].

13. References

13.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.
 [RFC4020]      Kompella, K. and A. Zinin, "Early IANA Allocation of
                Standards Track Code Points", BCP 100, RFC 4020,
                February 2005.
 [RFC5226]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                an IANA Considerations Section in RFCs", BCP 26,
                RFC 5226, May 2008.

13.2. Informative References

 [AAA-PAY]      Clancy, T., Lior, A., Ed., Zorn, G., and K. Hoeper,
                "EAP Method Support for Transporting AAA Payloads",
                Work in Progress, May 2010.
 [GSS-API-EAP]  Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism
                for the Extensible Authentication Protocol", Work in
                Progress, June 2012.
 [HC07]         Hoeper, K. and L. Chen, "Where EAP Security Claims
                Fail", Institute for Computer Sciences, Social
                Informatics and Telecommunications Engineering
                (ICST), The Fourth International Conference on
                Heterogeneous Networking for Quality, Reliability,
                Security and Robustness (QShine 2007), August 2007.

Hartman, et al. Standards Track [Page 27] RFC 6677 EAP Channel Binding July 2012

 [RADIUS-WLAN]  Aboba, B., Malinen, J., Congdon, P., and J. Salowey,
                "RADIUS Attributes for IEEE 802 Networks", Work in
                Progress, October 2011.
 [RFC4017]      Stanley, D., Walker, J., and B. Aboba, "Extensible
                Authentication Protocol (EAP) Method Requirements for
                Wireless LANs", RFC 4017, March 2005.
 [RFC5056]      Williams, N., "On the Use of Channel Bindings to
                Secure Channels", RFC 5056, November 2007.
 [RFC5191]      Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and
                A. Yegin, "Protocol for Carrying Authentication for
                Network Access (PANA)", RFC 5191, May 2008.
 [RFC5296]      Narayanan, V. and L. Dondeti, "EAP Extensions for EAP
                Re-authentication Protocol (ERP)", RFC 5296,
                August 2008.
 [RFC5873]      Ohba, Y. and A. Yegin, "Pre-Authentication Support for
                the Protocol for Carrying Authentication for Network
                Access (PANA)", RFC 5873, May 2010.

Hartman, et al. Standards Track [Page 28] RFC 6677 EAP Channel Binding July 2012

Appendix A. Attacks Prevented by Channel Bindings

 In the following appendix, 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).  This document
 only provides part of the solution necessary to realize a defense
 against these attacks.  In addition, lower-layer protocols need to
 describe what attributes should be included in channel-binding
 requests.  EAP methods need to be updated in order to describe how
 the channel-binding request and response are carried.  In addition,
 deployments may need to decide what information is populated in the
 local database.  The following sections describe types of attacks
 that can be prevented by this framework with appropriate lower-layer
 attributes carried in channel bindings, EAP methods with channel-
 binding support, and appropriate local database information at the
 EAP server.

A.1. Enterprise Subnetwork Masquerading

 As outlined in Section 3, 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.

A.2. Forced Roaming

 Mobile phone providers boosting their cell towers' 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 that they are roaming.
 Channel bindings would detect the bogus network identifier because
 the network identifier sent to the authentication server in i1 will
 match neither 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

Hartman, et al. Standards Track [Page 29] RFC 6677 EAP Channel Binding July 2012

 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.

A.3. Downgrading Attacks

 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 the EAP MD5 Challenge Handshake
 Authentication Protocol (EAP-MD5-CHAP), the Flexible Authentication
 via Secure Tunneling EAP (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.  This presumes that all
 acceptable EAP methods support channel binding and that an attacker
 cannot break the EAP method in real-time.

A.4. Bogus Beacons in IEEE 802.11r

 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.
 By implementing channel bindings, as described in this document, 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.

A.5. Forcing False Authorization in IEEE 802.11i

 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 one the
 peer is actually connected to.

Hartman, et al. Standards Track [Page 30] RFC 6677 EAP Channel Binding July 2012

 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.
 Both attacks can be prevented by implementing channel bindings,
 because the server can compare the information sent to the peer, the
 information it received from the authenticator during the AAA
 communication, and the information stored in the policy database.

Authors' Addresses

 Sam Hartman (editor)
 Painless Security
 356 Abbott St.
 North Andover, MA  01845
 USA
 EMail: hartmans-ietf@mit.edu
 T. Charles Clancy
 Virginia Polytechnic Institute and State University
 Electrical and Computer Engineering
 900 North Glebe Road
 Arlington, VA  22203
 USA
 EMail: tcc@vt.edu
 Katrin Hoeper
 Motorola Solutions, Inc.
 1301 E. Algonquin Road
 Schaumburg, IL  60196
 USA
 EMail: khoeper@motorolasolutions.com

Hartman, et al. Standards Track [Page 31]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6677.txt · Last modified: 2012/07/18 23:39 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki