[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-clancy-emu-chbind) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 6677

EMU Working Group                                              T. Clancy
Internet-Draft                                                       LTS
Intended status: Standards Track                               K. Hoeper
Expires: April 25, 2010                                   Motorola, Inc.
                                                        October 22, 2009


                Channel Binding Support for EAP Methods
                        draft-ietf-emu-chbind-04

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  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.

   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 April 25, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Clancy & Hoeper          Expires April 25, 2010                 [Page 1]


Internet-Draft                 EAP-CHBIND                   October 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

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








































Clancy & Hoeper          Expires April 25, 2010                 [Page 2]


Internet-Draft                 EAP-CHBIND                   October 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  6

   4.  Channel Bindings . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Types of EAP Channel Bindings  . . . . . . . . . . . . . .  7
     4.2.  Channel Bindings Architecture  . . . . . . . . . . . . . .  9

   5.  Channel Binding Protocol . . . . . . . . . . . . . . . . . . . 10
     5.1.  Protocol Operation . . . . . . . . . . . . . . . . . . . . 10
     5.2.  Channel Binding Consistency Check  . . . . . . . . . . . . 12

   6.  System Requirements  . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  General Transport Protocol Requirements  . . . . . . . . . 13
     6.2.  EAP Method Requirements  . . . . . . . . . . . . . . . . . 14
     6.3.  SAP Transport Requirements . . . . . . . . . . . . . . . . 14

   7.  Channel Binding TLV  . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Requirements for Lower-Layer Bindings  . . . . . . . . . . 15
     7.2.  General Attributes . . . . . . . . . . . . . . . . . . . . 15
     7.3.  IEEE 802.11  . . . . . . . . . . . . . . . . . . . . . . . 15
       7.3.1.  IEEE 802.11r . . . . . . . . . . . . . . . . . . . . . 15

   8.  AAA-Layer Bindings . . . . . . . . . . . . . . . . . . . . . . 16

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
     9.1.  Trust Model  . . . . . . . . . . . . . . . . . . . . . . . 17
     9.2.  Consequences of Trust Violation  . . . . . . . . . . . . . 17
     9.3.  Privacy Violations . . . . . . . . . . . . . . . . . . . . 18

   10. Operations and Management Considerations . . . . . . . . . . . 18

   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19

   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19

   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     13.2. Informative References . . . . . . . . . . . . . . . . . . 20

   Appendix A.  Attacks Prevented by Channel Bindings . . . . . . . . 20
     A.1.  Enterprise Subnetwork Masquerading . . . . . . . . . . . . 21
     A.2.  Forced Roaming . . . . . . . . . . . . . . . . . . . . . . 21
     A.3.  Downgrading attacks  . . . . . . . . . . . . . . . . . . . 21



Clancy & Hoeper          Expires April 25, 2010                 [Page 3]


Internet-Draft                 EAP-CHBIND                   October 2009


     A.4.  Bogus Beacons in IEEE 802.11r  . . . . . . . . . . . . . . 22
     A.5.  Forcing false authorization in IEEE 802.11i  . . . . . . . 22

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22















































Clancy & Hoeper          Expires April 25, 2010                 [Page 4]


Internet-Draft                 EAP-CHBIND                   October 2009


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.

   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, such as the NAS-
   Identifier, there's no reason the access point needs to advertise a
   consistent identity to peers.  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 peer joins one network that is masquerading as another.

   A similar problem can be observed in the context of roaming.  Here,
   the lying entity is located in a visited service provider network,
   e.g. attempting to lure peers to connect to the network based on
   false advertized roaming rates.  This is referred to as "lying
   provider" problem in the remainder of this document.

   This document defines and implements EAP channel bindings to solve
   the lying NAS and the lying provider problems, using a process in
   which the EAP peer provides information about the characteristics of
   the service provided by the authenticator to the AAA server protected
   within the EAP method.  This allows the server to verify the
   authenticator is providing information to the peer that is consistent
   with the information received from this authenticator as well as the
   information stored about this authenticator.  "AAA Payloads" defined
   in [I-D.clancy-emu-aaapay] proposes a mechanism 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].



Clancy & Hoeper          Expires April 25, 2010                 [Page 5]


Internet-Draft                 EAP-CHBIND                   October 2009


3.  Problem Statement

   In a [RFC4017] compliant EAP authentication, the EAP peer and EAP
   server mutually authenticate each other, and derive keying material.
   However, when operating in pass-through mode, the EAP server can be
   far removed from the authenticator.  A malicious or compromised
   authenticator may represent incorrect information about the network
   to the peer in an effort to affect its operation in some way.
   Additionally, while an authenticator may not be compromised, other
   compromised elements in the network (such as proxies) could provide
   false information to the authenticator that it could simply be
   relaying to EAP peers.  Hence, the goal must be to ensure that the
   authenticator is providing correct information to the EAP peer during
   the initial network discovery, selection, and authentication.

   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 following are example attacks possible by presenting false
   network information to peers.

   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 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  Service Provider Network: An EAP-enabled mobile phone provider
      could advertize very competitive flat rates but send per minute
      rates to the home server, thus, luring peers to connect to their
      network and overcharging them.  In more elaborated attacks, peers
      can be tricked into roaming without their knowledge.  For example,



Clancy & Hoeper          Expires April 25, 2010                 [Page 6]


Internet-Draft                 EAP-CHBIND                   October 2009


      a mobile phone provider operating along a geo-political boundary
      could boost their cell towers' transmission power and advertise
      the network identity of the neighboring country's indigenous
      provider.  This would cause unknowing handsets to associate with
      an unintended operator, and consequently be subject to high
      roaming fees without realizing they had roamed off their home
      provider's network.  These types of scenarios can be considered as
      "lying provider" problem, because here the provider configures its
      NAS to broadcast false information.  For the purpose of channel
      bindings as defined in this draft, it does not matter which local
      entity (or entities) is "lying" in a service provider network
      (local NAS, local authentication server and/or local proxies),
      because the only information received from the visited network
      that is verified by channel bindings is the information the home
      authentication server received from the last hop in the
      communication chain.  In other words, channel bindings enable the
      detection of inconsistencies in the information from a visited
      network, but cannot determine which entity is lying.  Naturally,
      channel bindings for EAP methods can only verify the endpoints
      and, if desirable, intermediate hops need to be protected by the
      employed AAA protocol.

   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 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 of
   different layers of a session but rather the information advertised
   to EAP peer by an authenticator acting as pass-through device during
   an EAP execution.

4.1.  Types of EAP Channel Bindings

   There are two main approaches to EAP channel bindings:






Clancy & Hoeper          Expires April 25, 2010                 [Page 7]


Internet-Draft                 EAP-CHBIND                   October 2009


   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 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 affect on the remainder of the EAP
      execution.  The exact use of the verification results can be
      subject to the network policy.  Additionally, consistent
      information canonicalization and formatting for the key derivation
      approach would likely cause significant deployment problems.

   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 peer and
      server.



Clancy & Hoeper          Expires April 25, 2010                 [Page 8]


Internet-Draft                 EAP-CHBIND                   October 2009


4.2.  Channel Bindings Architecture

   The scope of EAP channel bindings differs somewhat depending on the
   type of deployment in which they are being used.  In enterprise
   networks, they can be used to authenticate very specific properties
   of the authenticator (e.g.  MAC address, supported link types and
   data rates, etc), while in service provider networks they can
   generally only authenticate broader information about a roaming
   partner's network (e.g. network name, roaming information, link
   security requirements, etc).  The reason for the difference has to do
   with the amount of information about the authenticator and/or network
   to which the peer is connected you expect your home EAP server 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 any longer.  For example, information carried
   in AAA attributes such as the NAS IP address may have been lost in
   transition and are thus not known to the EAP server.  This affects
   the ability of the EAP server to verify specific NAS properties.
   However, often verification of the MAC or IP address of the NAS is
   not useful for improving the overall security posture of a network.
   More often it is useful to make policy decisions about services being
   offered to peers.  For example, in an IEEE 802.11 network, the EAP
   server may wish to ensure that peers connecting to the corporate
   intranet are using secure link-layer encryption, while link-layer
   security requirements for peers connecting to the guest network could
   be less stringent.  These types of policy decisions can be made
   without knowing or being able to verify the IP address of the NAS
   through which the peer is connecting.

   Furthermore, as described in the next section, channel bindings also
   verify the information provided by a peer and a local database, where
   both pieces of information are not restricted to AAA attributes and,
   thus, unaffected by the processing of intermediate AAA hops.
   Consequently, even if some information got lost in transition and
   thus may not be known to the EAP server, the server is still able to
   carry out the channel binding verification.

   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



Clancy & Hoeper          Expires April 25, 2010                 [Page 9]


Internet-Draft                 EAP-CHBIND                   October 2009


   traffic is being routed.

   Any deployment of channel bindings should take into consideration
   both what information the EAP server is likely to know or have access
   to, and also what type of network information the peer would want and
   need authenticated.


5.  Channel Binding Protocol

   This section defines a protocol for verifying channel binding
   information during an EAP authentication.  The protocol uses the
   approach where plaintext data is exchanged, since it allows channel
   bindings to be used more flexibly in varied deployment models (see
   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.

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 in pass-trough mode.  For the channel
   binding protocol presented in this draft to work, the EAP server
   needs to be able to access information from the AAA server that is
   utilized during the EAP session and a local database.  For example,
   the EAP server and the local database can be co-located with the AAA
   server, as illustrated in Figure 1.

                                        + -------------------------+
     --------        -------------      |   ----------     ______  |
    |EAP peer|<---->|Authenticator|<--> |  |EAP Server|___(______) |
     --------        -------------      |   ----------    | DB   | |
        .                 .             |AAA              (______) |
        .       i1        .             +--------------------------+
        .<----------------.      i2     .       .
        .                 .------------>        .
        .                  i1                   .
        .-------------------------------------->.
        .     CB_success/failure(i1, i2,info)   .
        .<--------------------------------------.


                   Figure 1: Overview of Channel Binding




Clancy & Hoeper          Expires April 25, 2010                [Page 10]


Internet-Draft                 EAP-CHBIND                   October 2009


   During network advertisement, selection, and authentication, the
   authenticator presents unauthenticated information, labeled i1, about
   the network to the peer.  Message i1 could include an authenticator
   identifier and the identity of the network it represents, in addition
   to advertised network information such as offered services and
   roaming information.  Information may be communicated implicitly in
   i1, such as the type of media in use.  As there is no established
   trust relationship between the peer and authenticator, there is no
   way for the peer to validate this information.

   Additionally, during the transaction the authenticator presents a
   number of information properties in form of AAA attributes about
   itself and the current request to the AAA infrastructure which may or
   may not be valid.  This information is labeled i2.  Message i2 is the
   information the AAA server receives from the last hop in the AAA
   proxy chain which is not necessarily the authenticator.

   The local database is perhaps the most important part of this system.
   In order for the EAP server or AAA server to know whether i1 and i2
   are correct, they need access to trustworthy information, since an
   authenticator could include false information in both i1 and i2.
   Additional reasons why such a database is necessary for channel
   bindings to work are discussed in the next subsection.  The
   information contained within the database could involve wildcards.
   For example, this could be used to check whether WiFi access points
   on a particular IP subnet all use a specific SSID.  The exact IP
   address is immaterial, provided it is on the correct subnet.

   During an EAP method execution with channel bindings, the goal is to
   transport i1 from the peer to the EAP server, and allow the system to
   verify the consistency of i1 provided by the peer, i2 provided by the
   authenticator, and the information in the local database.  Upon the
   check, the EAP server sends a message to the peer indicating whether
   the channel binding validation check succeeded or failed and
   optionally includes all or some of the information that was used in
   the check.  The message flow is illustrated in Figure 1.

   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.







Clancy & Hoeper          Expires April 25, 2010                [Page 11]


Internet-Draft                 EAP-CHBIND                   October 2009


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,

   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 NAS/authenticator
   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 type of
   identifiers and addresses may have been presented to both
   communication endpoints.  Whether these different identifiers and
   addresses belong to the same device cannot be directly checked by the
   EAP server or AAA server without additional information.  Finally, i2
   may be different from the original information sent by the
   authenticator because of en route processing or malicious
   modifications.  As a result, in the service provider model, typically
   the i1 information available to the EAP server can only be verified
   against the last-hop portion of i2, or values propagated by proxy
   servers.  In addition, checking the consistency of i1 and i2 alone is
   insufficient because an authenticator could lie to both, the peer and
   the EAP server, i.e. i1 and i2 may be consistent but both contain
   false information.

   A local database is required to leverage the above mentioned
   shortcomings and support the consistency and validation checks.  In
   particular, information stored for each NAS/authenticator (enterprise
   scenario) or each roaming partner (service provider scenario) enables
   a comparison of any information received in i1 with AAA attributes in
   i2 as well as additionally stored AAA attributes that might have gone
   lost in transition.  Furthermore, only such a database enables the
   EAP server and AAA server to check the received information against
   trusted information about the network including roaming agreements.

   Section 7 describes lower-layer specific properties that can be



Clancy & Hoeper          Expires April 25, 2010                [Page 12]


Internet-Draft                 EAP-CHBIND                   October 2009


   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.


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.  To satisfy this requirement, it
   should occur either during the EAP method execution or during the EAP
   lower layer's secure association protocol (SAP).

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

   One way to transport the single round-trip exchange is as a series of
   TLVs formatted and encapsulated in EAP methods.  These TLVs carry
   different types of data.  Since i2 messages are carried within a AAA
   protocol it is useful to define one type of data carried as AAA AVPs,
   but other types of data may be defined that are not carried in AAA
   attributes and are only compared against the information stored in
   the local database.  This document describes some AAA attributes that
   are useful for channel binding checks.  Additionally, guidance on how
   to perform consistency checks on those values will be provided.
   Since the Diameter namespace contains the RADIUS namespace the TLVs
   of AAA AVP type carry Diameter attributes.

   Any transport needs to be careful not to exceed the MTU for its
   lower-layer medium.  In particular, if channel binding information is
   exchanged within protected EAP method channels, these methods may or
   may not support fragmentation.  In order to work with all methods,



Clancy & Hoeper          Expires April 25, 2010                [Page 13]


Internet-Draft                 EAP-CHBIND                   October 2009


   the channel binding messages must fit within the available payload.
   For example, if the EAP MTU is 1020 octets, and EAP-GPSK is used as
   the authentication method, and maximal-length identities are used, a
   maximum of 384 octets are available for conveying channel binding
   information.  Other methods, such as EAP-TTLS, support fragmentation
   and could carry significantly longer payloads.

6.2.  EAP Method Requirements

   If transporting data directly within an EAP method, it MUST be able
   to carry integrity protected data from the EAP peer to server.  EAP
   methods SHOULD provide a mechanism to carry protected data from
   server to peer.  EAP methods MUST exchange channel binding data with
   the AAA subsystem hosting the EAP server.  EAP methods MUST be able
   to import channel binding data from the lower layer on the EAP peer.

6.3.  SAP Transport Requirements

   If transporting data within a lower-layer's secure association
   protocol (SAP), this protocol MUST support transport of integrity
   protected data using a key known only by the EAP peer and EAP server,
   and not known to the authenticator.  There must be mechanism whereby
   the authenticator can transport the protected payloads to the EAP
   server, either via a AAA protocol or some other means, and receive a
   protected result.

   This protocol MUST support exporting channel binding data to the AAA
   subsystem on the EAP server for validation.  The SAP must have access
   to channel binding data required for transport to the EAP server.


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).  In particular, attributes for IEEE 802.11 are provided,
   which can be used as a template for developing bindings for other EAP
   lower-layer protocols.

   For any lower-layer protocol, network information of interest to the
   peer and server can be encapsulated in AVPs or other defined payload
   containers.  The appropriate AVPs depend on the lower layer protocol
   as well as on the network type (i.e. enterprise network or service
   provider network) and its application.  Additional TLV types can be
   defined beyond AAA AVPs.  For example it may be useful to define TLVs
   that can carry 802.11 information elements.



Clancy & Hoeper          Expires April 25, 2010                [Page 14]


Internet-Draft                 EAP-CHBIND                   October 2009


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.

   Any binding value that is communicated in AAA MUST be encoded as a
   Diameter AVP.  The data conveyed within the AVP type MUST NOT
   conflict with the externally-defined usage of the AVP.  Additional
   TLV types SHOULD be defined for values that are not communicated
   within AAA attributes.

7.2.  General Attributes

   This section lists AAA AVPs useful to all link-layers.  The peer
   SHOULD transmit to the server the following fields, encapsulated
   within the appropriate Diameter AVPs:

   NAS-Port-Type:  Indicates the underlying link-layer technology used
      to connect (e.g.  IEEE 802.11, PPP, etc), and SHOULD be included
      by the EAP peer, and SHOULD be verified against the database and
      NAS-Port-Type received from the NAS.

   Cost-Information:  AVP from the Diameter Credit-Control Application
      [RFC4006] to the peer indicating how much peers will be billed for
      service and MAY be included by the EAP peer and verified against
      roaming profiles stored in the database.

7.3.  IEEE 802.11

   The peer SHOULD transmit to the server the following fields,
   encapsulated within the appropriate Diameter AVPs:

   Called-Station-Id:  contains BSSID and SSID and SHOULD be verified
      against the database and Called-Station-Id received from the NAS


7.3.1.  IEEE 802.11r

   In addition to the AVPs for IEEE 802.11, an IEEE 802.11r client
   SHOULD transmit the following additional field:







Clancy & Hoeper          Expires April 25, 2010                [Page 15]


Internet-Draft                 EAP-CHBIND                   October 2009


   Mobility-Domain-Id:  contains the identity of the mobility domain and
      SHOULD be verified against the database and Mobility-Domain-Id
      received from the NAS [I-D.aboba-radext-wlan]


8.  AAA-Layer Bindings

   This section discusses which AAA attributes in a AAA Accept-Request
   messages can and should be validated by a AAA server (i.e. data from
   i2 in 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 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.

   User-Name:  This value should be checked for consistency with the
      database and any method-specific user information.  If EAP method
      identity protection is employed, this value typically contains a
      pseudonym or keyword.

   NAS-IP-Address:  This value is typically the IP address of the
      authenticator, but in a proxied connection it likely will not
      match the source IP address of an Access-Request.  A consistency
      check MAY verify the subnet of the IP address was correct based on
      the last-hop proxy.

   NAS-IPv6-Address:  This value is typically the IPv6 address of the
      authenticator, but in a proxied connection it likely will not
      match the source IPv6 address of an Access-Request.  A consistency
      check MAY verify the subnet of the IPv6 address was correct based
      on the last-hop proxy.

   Called-Station-Id:  This is typically the MAC address of the NAS.  On
      an enterprise network, it MAY be validated against the MAC address
      is one that has been provisioned on the network.

   Calling-Station-Id:  This is typically the MAC address of the EAP
      peer, and verification of this is likely difficult, unless EAP
      credentials have been provisioned on a per-host basis to specific
      L2 addresses.  It SHOULD be validated against the database in an
      enterprise deployment.

   NAS-Identifier:  This is an identifier populated by the NAS, and
      could be related to the MAC address, and should be validated
      similarly to the Called-Station-Id.





Clancy & Hoeper          Expires April 25, 2010                [Page 16]


Internet-Draft                 EAP-CHBIND                   October 2009


   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 needs to 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
   o  sending i1 from peer to server over an integrity-protected channel
   o  sending the result and optionally i2 from server to peer over an
      integrity-protected channel

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



Clancy & Hoeper          Expires April 25, 2010                [Page 17]


Internet-Draft                 EAP-CHBIND                   October 2009


   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.  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
   binding is offered or not.  On the other hand, dishonest servers can
   claim a successful validation even if i1 contains invalid
   information.  This can be seen as collaboration of authenticator and
   server.  Channel binding can neither prevent nor detect such attacks.
   In general such attacks cannot be prevented by cryptographic means
   and should be addressed using policies making servers liable for
   their provided information and services.

   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.

9.3.  Privacy Violations

   While the channel binding information exchanged between EAP peer and
   EAP server (i.e. i1 and the optional result message) must always be
   integrity-protected it may not be encrypted.  In the case that these
   messages contain identifiers of peer and/or network entities, the
   privacy property of the executed EAP method may be violated.  Hence,
   in order to maintain the privacy of an EAP method, the exchanged
   channel binding information must be encrypted.  If encryption is not
   available, private information is not sent as part of the channel
   binding information, as described in Section 6.1.


10.  Operations and Management Considerations

   As with any extension to existing protocols, there will be an impact



Clancy & Hoeper          Expires April 25, 2010                [Page 18]


Internet-Draft                 EAP-CHBIND                   October 2009


   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 exist
   already exist on the AAA server in which case the EAP server passes
   the parameters to the AAA server for validation.  The EAP methods
   need to be able to export received channel binding information to the
   EAP server so it can be validated.


11.  IANA Considerations

   This document contains no IANA considerations.


12.  Acknowledgements

   The authors would like to thank Bernard Aboba, Joe Salowey, and Klaas
   Wierenga for their valuable inputs that helped to improve and shape
   this document over the time.


13.  References







Clancy & Hoeper          Expires April 25, 2010                [Page 19]


Internet-Draft                 EAP-CHBIND                   October 2009


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.

13.2.  Informative References

   [I-D.aboba-radext-wlan]
              Aboba, B., Malinen, J., Congdon, P., and J. Salowey,
              "RADIUS Attributes for IEEE 802 Networks",
              draft-aboba-radext-wlan-11 (work in progress), April 2009.

   [I-D.clancy-emu-aaapay]
              Clancy, T., Lior, A., and G. Zorn, Ed., "EAP Method
              Support for Transporting AAA Payloads", Internet
              Draft draft-clancy-emu-aaapay-02, May 2009.

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

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, November 2007.

   [HC07]     Hoeper, K. and L. Chen, "Where EAP Security Claims Fail",
              ICST QShine, August 2007.

   [80211U-D4.01]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              11: Wireless LAN Medium Access Control (MAC) and Physical
              Layer (PHY) specifications - Amendment 7: Interworking
              with External Networks", IEEE Draft Standard 802.11u,
              November 2008.


Appendix A.  Attacks Prevented by Channel Bindings

   In the following it is demonstrated how the presented channel



Clancy & Hoeper          Expires April 25, 2010                [Page 20]


Internet-Draft                 EAP-CHBIND                   October 2009


   bindings can prevent attacks by malicious authenticators
   (representing the lying NAS problem) as well as malicious visited
   networks (representing the lying provider problem).

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 tower's transmission power
   to get more users to use their networks have occurred in the past.
   The increased transmission range combined with a NAS sending a false
   network identity lures users to connect to the network without being
   aware of that they are roaming.

   Channel bindings would detect the bogus network identifier because
   the network identifier send to the authentication server in i1 will
   neither match information i2 nor the stored data.  The verification
   fails because the info in i1 claims to come from the peer's home
   network while the home authentication server knows that the
   connection is through a visited network outside the home domain.  In
   the same context, channel bindings can be utilized to provide a "home
   zone" feature that notifies users every time they are about to
   connect to a NAS outside their home domain.

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 EAP-MD5-CHAP, EAP-FAST and some
   other methods, the authenticator reduces the choice for the peer to
   the weaker EAP-MD5-CHAP method.  Assuming that weak EAP methods are
   supported by the authentication server, such a downgrading attack can



Clancy & Hoeper          Expires April 25, 2010                [Page 21]


Internet-Draft                 EAP-CHBIND                   October 2009


   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.

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 draft, in IEEE
   802.11r, the verification by the authentication server would detect
   the inconsistencies between the information the authenticator has
   sent to the peer and the information the server received from the
   authenticator and stores in the policy database.

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

   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 that was sent to the
   peer, with information it received from the authenticator during the
   AAA communication as well as the information stored in the policy
   database.











Clancy & Hoeper          Expires April 25, 2010                [Page 22]


Internet-Draft                 EAP-CHBIND                   October 2009


Authors' Addresses

   T. Charles Clancy
   Laboratory for Telecommunications Sciences
   US Department of Defense
   College Park, MD  20740
   USA

   Email: clancy@LTSnet.net


   Katrin Hoeper
   Motorola, Inc.
   1301 E. Algonquin Road
   Schaumburg, IL  60196
   USA

   Email: khoeper@motorola.com

































Clancy & Hoeper          Expires April 25, 2010                [Page 23]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/