idnits 2.17.1 draft-ietf-emu-chbind-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 24, 2012) is 4345 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) == Outdated reference: A later version (-04) exists of draft-clancy-emu-aaapay-02 == Outdated reference: A later version (-09) exists of draft-ietf-abfab-gss-eap-06 -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMU Working Group S. Hartman, Ed. 3 Internet-Draft Painless Security 4 Intended status: Standards Track T. Clancy 5 Expires: November 25, 2012 Department of Electrical 6 Engineering and Computer Science 7 K. Hoeper 8 Motorola Solutions, Inc. 9 May 24, 2012 11 Channel Binding Support for EAP Methods 12 draft-ietf-emu-chbind-16.txt 14 Abstract 16 This document defines how to implement channel bindings for 17 Extensible Authentication Protocol (EAP) methods to address the lying 18 Network Access Service (NAS) as well as the lying provider problem. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 25, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.1. Types of EAP Channel Bindings . . . . . . . . . . . . . . 8 74 4.2. Channel Bindings in the Secure Association Protocol . . . 10 75 4.3. Channel Bindings Scope . . . . . . . . . . . . . . . . . . 11 77 5. Channel Binding Process . . . . . . . . . . . . . . . . . . . 13 78 5.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 13 79 5.2. Channel Binding Consistency Check . . . . . . . . . . . . 15 80 5.3. EAP Protocol . . . . . . . . . . . . . . . . . . . . . . . 16 81 5.3.1. Channel Binding Codes . . . . . . . . . . . . . . . . 18 82 5.3.2. Namespace Identifiers . . . . . . . . . . . . . . . . 18 83 5.3.3. RADIUS Namespace . . . . . . . . . . . . . . . . . . . 18 85 6. System Requirements . . . . . . . . . . . . . . . . . . . . . 19 86 6.1. General Transport Protocol Requirements . . . . . . . . . 19 87 6.2. EAP Method Requirements . . . . . . . . . . . . . . . . . 20 89 7. Channel Binding TLV . . . . . . . . . . . . . . . . . . . . . 20 90 7.1. Requirements for Lower-Layer Bindings . . . . . . . . . . 20 91 7.2. EAP Lower Layer Attribute . . . . . . . . . . . . . . . . 21 93 8. AAA-Layer Bindings . . . . . . . . . . . . . . . . . . . . . . 21 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 96 9.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 22 97 9.2. Consequences of Trust Violation . . . . . . . . . . . . . 24 98 9.3. Bid-Down Attacks . . . . . . . . . . . . . . . . . . . . . 25 99 9.4. Privacy Violations . . . . . . . . . . . . . . . . . . . . 25 101 10. Operations and Management Considerations . . . . . . . . . . . 26 103 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 104 11.1. EAP Lower Layers Registry . . . . . . . . . . . . . . . . 27 105 11.2. RADIUS Registration . . . . . . . . . . . . . . . . . . . 27 107 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 111 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 113 Appendix A. Attacks Prevented by Channel Bindings . . . . . . . . 29 114 A.1. Enterprise Subnetwork Masquerading . . . . . . . . . . . . 30 115 A.2. Forced Roaming . . . . . . . . . . . . . . . . . . . . . . 30 116 A.3. Downgrading attacks . . . . . . . . . . . . . . . . . . . 30 117 A.4. Bogus Beacons in IEEE 802.11r . . . . . . . . . . . . . . 31 118 A.5. Forcing false authorization in IEEE 802.11i . . . . . . . 31 120 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 31 121 B.1. Changes Since 09 . . . . . . . . . . . . . . . . . . . . . 31 122 B.2. Changes since Version 06 . . . . . . . . . . . . . . . . . 32 123 B.3. Changes since version 04 . . . . . . . . . . . . . . . . . 32 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 127 1. Introduction 129 The so-called "lying NAS" problem is a well-documented problem with 130 the current Extensible Authentication Protocol (EAP) architecture 131 [RFC3748] when used in pass-through authenticator mode. Here, a 132 Network Access Server (NAS), or pass-through authenticator, may 133 represent one set of information (e.g. network identity, 134 capabilities, configuration, etc) to the backend Authentication, 135 Authorization, and Accounting (AAA) infrastructure, while 136 representing contrary information to EAP peers. Another possibility 137 is that the same false information could be provided to both the EAP 138 peer and EAP server by the NAS. A "lying" entity can also be located 139 anywhere on the AAA path between the NAS and the EAP server. 141 This problem results when the same credentials are used to access 142 multiple services that differ in some interesting property. The EAP 143 server learns which client credentials are in use. The client knows 144 which EAP credentials are used, but cannot distinguish between 145 servers that use those credentials. For methods that distinguish 146 between client and server credentials, either using different server 147 credentials for access to the different services or having client 148 credentials with access to a disjoint set of services can potentially 149 defend against the attack. 151 As a concrete example, consider an organization with two different 152 IEEE 802.11 wireless networks. One is a relatively low-security 153 network for accessing the web while the other has access to valuable 154 confidential information. An access point on the web network could 155 act as a lying NAS, sending the SSID of the confidential network in 156 its beacons. This access point could gain an advantage by doing so 157 if it tricks clients intending to connect to the confidential network 158 to connect to it and disclose confidential information. 160 A similar problem can be observed in the context of roaming. Here, 161 the lying entity is located in a visited service provider network, 162 e.g. attempting to lure peers to connect to the network based on 163 false advertized roaming rates. This is referred to as "the lying 164 provider" problem in the remainder of this document. The lying 165 entity's motivation often is financial; the entity may be paid 166 whenever peers roam to its service. However a lying entity in a 167 provider network can also gain access to traffic that it might not 168 otherwise see. 170 This document defines and implements EAP channel bindings to solve 171 the lying NAS and the lying provider problems, using a process in 172 which the EAP peer provides information about the characteristics of 173 the service provided by the authenticator to the AAA server protected 174 within the EAP method. This allows the server to verify the 175 authenticator is providing information to the peer that is consistent 176 with the information received from this authenticator as well as the 177 information stored about this authenticator. "AAA Payloads" defined 178 in [I-D.clancy-emu-aaapay] served as the starting point for the 179 mechanism proposed in this specification to carry this information. 181 2. Terminology 183 In this document, several words are used to signify the requirements 184 of the specification. These words are often capitalized. The key 185 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 186 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 187 are to be interpreted as described in [RFC2119]. 189 3. Problem Statement 191 In a [RFC4017] compliant EAP authentication, the EAP peer and EAP 192 server mutually authenticate each other, and derive keying material. 193 However, when operating in pass-through mode, the EAP server can be 194 far removed from the authenticator both in terms of network distance 195 and number of entities who need to be trusted in order to establish 196 trusted communication. A malicious or compromised authenticator may 197 represent incorrect information about the network to the peer in an 198 effort to affect its operation in some way. Additionally, while an 199 authenticator may not be compromised, other compromised elements in 200 the network (such as proxies) could provide false information to the 201 authenticator that it could simply be relaying to EAP peers. Hence, 202 the goal must be to ensure that the authenticator is providing 203 correct information to the EAP peer during the initial network 204 discovery, selection, and authentication. 206 There are two different types of networks to consider: enterprise 207 networks and service provider networks. In enterprise networks, 208 assuming a single administrative domain, it is feasible for an EAP 209 server to have information about all the authenticators in the 210 network. In service provider networks, global knowledge is 211 infeasible due to indirection via roaming. When a peer is outside 212 its home administrative domain, the goal is to ensure that the level 213 of service received by the peer is consistent with the contractual 214 agreement between the two service providers. The same EAP server may 215 need to support both types of networks. For example an enterprise 216 may have a roaming agreement permitting its users to use the networks 217 of third-party service providers. In these situations, the EAP 218 server may authenticate for an enterprise and provider network. 220 The following are example attacks possible by presenting false 221 network information to peers. 223 o Enterprise Network: A corporate network may have multiple virtual 224 LANs (VLANs) available throughout their campus network, and have 225 IEEE 802.11 access points connected to each VLAN. Assume one VLAN 226 connects users to the firewalled corporate network, while the 227 other connects users to a public guest network. The corporate 228 network is assumed to be free of adversarial elements, while the 229 guest network is assumed to possibly have malicious elements. 230 Access Points on both VLANs are serviced by the same EAP server, 231 but broadcast different SSIDs to differentiate. A compromised 232 access point connected to the guest network but not the corporate 233 network could advertise the SSID of the corporate network in an 234 effort to lure peers to connect to a network with a false sense of 235 security regarding their traffic. Conditions and further details 236 of this attack can be found in the Appendix. 238 o Enterprise network: The EAP GSS-API mechanism 239 [I-D.ietf-abfab-gss-eap] mechanism provides a way to use EAP to 240 authenticate to mail servers, instant messaging servers and other 241 non-network services. Without EAP channel binding, an attacker 242 could trick the user into connecting to a relatively untrusted 243 service instead of a relatively trusted service. For example the 244 instant messaging service could impersonate the mail server. 246 o Service Provider Network: An EAP-enabled mobile phone provider 247 could advertise very competitive flat rates but send per minute 248 rates to the home server, thus, luring peers to connect to their 249 network and overcharging them. In more elaborate attacks, peers 250 can be tricked into roaming without their knowledge. For example, 251 a mobile phone provider operating along a geo-political boundary 252 could boost their cell towers' transmission power and advertise 253 the network identity of the neighboring country's indigenous 254 provider. This would cause unknowing handsets to associate with 255 an unintended operator, and consequently be subject to high 256 roaming fees without realizing they had roamed off their home 257 provider's network. These types of scenarios can be considered as 258 "lying provider" problem, because here the provider configures its 259 NAS to broadcast false information. For the purpose of channel 260 bindings as defined in this draft, it does not matter which local 261 entity (or entities) is "lying" in a service provider network 262 (local NAS, local authentication server and/or local proxies), 263 because the only information received from the visited network 264 that is verified by channel bindings is the information the home 265 authentication server received from the last hop in the 266 communication chain. In other words, channel bindings enable the 267 detection of inconsistencies in the information from a visited 268 network, but cannot determine which entity is lying. Naturally, 269 channel bindings for EAP methods can only verify the endpoints 270 and, if desirable, intermediate hops need to be protected by the 271 employed AAA protocol. 273 o Enterprise and provider networks: In a situation where an 274 enterprise has roaming agreements with providers, a compromised 275 access point in a provider network could masquerade as the 276 enterprise network in an attempt to gain confidential information. 277 Today this could potentially be solved by using different 278 credentials for internal and external access. Depending on the 279 type of credential this may introduce usability or man-in-the- 280 middle security issues. 282 To address these problems, a mechanism is required to validate 283 unauthenticated information advertised by EAP authenticators. 285 4. Channel Bindings 287 EAP channel bindings seek to authenticate previously unauthenticated 288 information provided by the authenticator to the EAP peer, by 289 allowing the peer and server to compare their perception of network 290 properties in a secure channel. 292 It should be noted that the definition of EAP channel bindings 293 differs somewhat from channel bindings documented in [RFC5056], which 294 seek to securely bind together the end points of a multi-layer 295 protocol, allowing lower layers to protect data from higher layers. 296 Unlike [RFC5056], EAP channel bindings do not ensure the binding of 297 different layers of a session but rather the information advertised 298 to EAP peer by an authenticator acting as pass-through device during 299 an EAP execution. The term channel bindings was independently 300 adopted by these two related concepts; by the time the conflict was 301 discovered, a wide body of literature existed for each usage. EAP 302 channel bindings could be used to provide RFC 5056 channel bindings. 303 In particular, an inner EAP method could be bound to an outer method 304 by including the RFC 5056 channel binding data for the outer channel 305 in the inner EAP method's channel bindings. Doing so would provide a 306 facility similar to EAP cryptographic binding, except that a man-in- 307 the-middle could not extract the inner method from the tunnel. This 308 specification does not weigh the advantages of doing so nor specify 309 how to do so; the example is provided only to illustrate how EAP 310 channel binding and RFC 5056 channel binding overlap. 312 4.1. Types of EAP Channel Bindings 314 There are two categories of approach to EAP channel bindings: 316 o After keys have been derived during an EAP execution, the peer and 317 server can, in an integrity-protected channel, exchange plaintext 318 information about the network with each other, and verify 319 consistency and correctness. 321 o The peer and server can both uniquely encode their respective view 322 of the network information without exchanging it, resulting into 323 an opaque blob that can be included directly into the derivation 324 of EAP session keys. 326 Both approaches are only applicable to key deriving EAP methods and 327 both have advantages and disadvantages. Various hybrid approaches 328 are also possible. Advantages of exchanging plaintext information 329 include: 331 o It allows for policy-based comparisons of network properties, 332 rather than requiring precise matches for every field, which 333 achieves a policy-defined consistency, rather than bitwise 334 equality. This allows network operators to define which 335 properties are important and even verifiable in their network. 337 o EAP methods that support extensible, integrity-protected channels 338 can easily include support for exchanging this network 339 information. In contrast, direct inclusion into the key 340 derivation would require more extensive revisions to existing EAP 341 methods or a wrapper EAP method. 343 o Given it doesn't affect the key derivation, this approach 344 facilitates debugging, incremental deployment, backward 345 compatibility and a logging mode in which verification results are 346 recorded but do not have an effect on the remainder of the EAP 347 execution. The exact use of the verification results can be 348 subject to the network policy. Additionally, consistent 349 information canonicalization and formatting for the key derivation 350 approach would likely cause significant deployment problems. 352 The following are advantages of directly including channel binding 353 information in the key derivation: 355 o EAP methods not supporting extensible, integrity-protected 356 channels could still be supported, either by revising their key 357 derivation, revising EAP, or wrapping them in a universal method 358 that supports channel binding. 360 o It can guarantee proper channel information, since subsequent 361 communication would be impossible if differences in channel 362 information yielded different session keys on the EAP peer and 363 server. 365 4.2. Channel Bindings in the Secure Association Protocol 367 This document describes channel bindings performed by transporting 368 channel binding information as part of an integrity-protected 369 exchange within an EAP method. Alternatively, some future document 370 could specify a mechanism for transporting channel bindings within 371 the lower layer's secure association protocol. Such a specification 372 would need to describe how channel bindings are exchanged over the 373 lower layer protocol between the peer and authenticator. In 374 addition, since the EAP exchange concludes before the secure 375 association protocol begins, a mechanism for transporting the channel 376 bindings from the authenticator to the EAP server needs to be 377 specified. A mechanism for transporting a protected result from the 378 EAP server, through the authenticator, back to the peer needs to be 379 specified. 381 The channel bindings MUST be transported with integrity protection 382 based on a key known only to the peer and EAP server. The channel 383 bindings SHOULD be confidentiality protected using a key known only 384 to the peer and EAP server. For the system to function, the EAP 385 server or AAA server needs access to the channel binding information 386 from the peer as well as the AAA attributes and a local database 387 described later in this document. 389 The primary advantage of sending channel bindings as part of the 390 secure association protocol is that EAP methods need not be changed. 391 The disadvantage is that a new AAA exchange is required, and secure 392 association protocols need to be changed. As the result of the 393 secure association protocol change, every NAS needs to be upgraded to 394 support channel bindings within the secure association protocol. 396 For many deployments, changing all the NASes is expensive and adding 397 channel binding support to enough EAP methods to meet the goals of 398 the deployment will be cheaper. However for deployment of new 399 equipment, or especially deployment of a new lower layer technology, 400 changing the NASes may be cheaper than changing EAP methods. 401 Especially if such a deployment needed to support a large number of 402 EAP methods, sending channel bindings in the secure association 403 protocol might make sense. Sending channel bindings in the secure 404 association protocol can work even with ERP [RFC5296] in which 405 previously established EAP key material is used for the secure 406 association protocol without carrying out any EAP method during re- 407 authentication. 409 If channel bindings using a secure association protocol is specified, 410 semantics as well as the set of information that peers exchange can 411 be shared with the mechanism described in this document. 413 4.3. Channel Bindings Scope 415 The scope of EAP channel bindings differs somewhat depending on the 416 type of deployment in which they are being used. In enterprise 417 networks, they can be used to authenticate very specific properties 418 of the authenticator (e.g. MAC address, supported link types and 419 data rates, etc), while in service provider networks they can 420 generally only authenticate broader information about a roaming 421 partner's network (e.g. network name, roaming information, link 422 security requirements, etc). The reason for the difference has to do 423 with the amount of information about the authenticator and/or network 424 to which the peer is connected the home EAP server is expected to 425 have access to. In roaming cases, the home server is likely to only 426 have access to information contained in their roaming agreements. 428 With any multi-hop AAA infrastructure, many of the NAS-specific AAA 429 attributes are obscured by the AAA proxy that's decrypting, 430 reframing, and retransmitting the underlying AAA messages. 431 Especially service provider networks are affected by this and the AAA 432 information received from the last hop may not contain much 433 verifiable information any longer. For example, information carried 434 in AAA attributes such as the NAS IP address may have been lost in 435 transition and are thus not known to the EAP server. Even worse, 436 information may still be available but be useless, for example 437 representing the identity of a device on a private network or a 438 middlebox. This affects the ability of the EAP server to verify 439 specific NAS properties. However, often verification of the MAC or 440 IP address of the NAS is not useful for improving the overall 441 security posture of a network. More often the best approach is to 442 make policy decisions about services being offered to peers. For 443 example, in an IEEE 802.11 network, the EAP server may wish to ensure 444 that peers connecting to the corporate intranet are using secure 445 link-layer encryption, while link-layer security requirements for 446 peers connecting to the guest network could be less stringent. These 447 types of policy decisions can be made without knowing or being able 448 to verify the IP address of the NAS through which the peer is 449 connecting. 451 The properties of the network that the peer wishes to validate depend 452 on the specific deployment. In a mobile phone network, peers 453 generally don't care what the name of the network is, as long as they 454 can make their phone call and are charged the expected amount for the 455 call. However, in an enterprise network the administrators of a peer 456 may be more concerned with specifics of where their network traffic 457 is being routed and what VLAN is in use. To establish policies 458 surrounding these requirements administrators would capture some 459 attribute such as SSID to describe the properties of the network they 460 care about. Channel bindings could validate the SSID. The 461 administrator would need to make sure that the network guarantees 462 that when an authenticator trusted by the AAA infrastructure to offer 463 a particular SSID to clients does offer this SSID, that network has 464 the intended properties. Generally it is not possible for channel 465 bindings to detect lying NAS behavior when the NAS is authorized to 466 claim a particular service. That is, if the same physical 467 authenticator is permitted to advertise two networks, the AAA 468 infrastructure is unlikely to be able to determine when this 469 authenticator lies. 471 As discussed in the next section, some of the most important 472 information to verify cannot come from AAA attributes but instead 473 comes from local configuration. For example in the mobile phone 474 case, the expected roaming rate cannot come from the roaming provider 475 without being verified against the contract between the two 476 providers. Similarly, in an enterprise, the SSID a particular access 477 point is expected to advertise is a matter of configuration rather 478 than something that can be trusted because it is included in an AAA 479 exchange. 481 The peer and authenticator do not initially have a basis for trust. 482 The peer has a credential with the EAP server that forms a basis for 483 trust. The EAP server and authenticator have a potentially indirect 484 trust path using the AAA infrastructure. Channel binding leverages 485 the trust between the peer and EAP server to build trust in certain 486 attributes between the peer and authenticator. 488 Channel bindings can be important for forming areas of trust, 489 especially when provider networks are involved, and exact information 490 is not available to the EAP server. Without channel bindings, all 491 entities in the system need to be held to the standards of the most 492 trusted entity that could be accessed using the EAP credential. 493 Otherwise, a less trusted entity can impersonate a more trusted 494 entity. However when channel bindings are used, the EAP server can 495 use information supplied by the peer, AAA protocols and local 496 database to distinguish less trusted entities from more trusted 497 entities. One possible deployment involves being able to verify a 498 number of characteristics about relatively trusted entities while for 499 other entities simply verifying that they are less trusted. 501 Any deployment of channel bindings should take into consideration 502 both what information the EAP server is likely to know or have access 503 to, and also what type of network information the peer would want and 504 need authenticated. 506 5. Channel Binding Process 508 This section defines the process for verifying channel binding 509 information during an EAP authentication. The protocol uses the 510 approach where plaintext data is exchanged, since it allows channel 511 bindings to be used more flexibly in varied deployment models (see 512 Section 4.1). In the first subsection, the general communication 513 infrastructure is outlined, the messages used for channel binding 514 verifications are specified, and the protocol flows are defined. The 515 second subsection explores the difficulties of checking the different 516 pieces of information that are exchanged during the channel binding 517 protocol for consistency. The third subsection describes the 518 information carried in the EAP exchange. 520 5.1. Protocol Operation 522 Channel bindings are always provided between two communication 523 endpoints, here the EAP peer and the EAP server, who communicate 524 through an authenticator typically in pass-through mode. 525 Specifications treat the AAA server and EAP server as distinct 526 entities. However there is no standardized protocol for the AAA 527 server and EAP server to communicate with each other. For the 528 channel binding protocol presented in this draft to work, the EAP 529 server needs to be able to access information from the AAA server 530 that is utilized during the EAP session (i2 below) and a local 531 database. For example, the EAP server and the local database can be 532 co-located with the AAA server, as illustrated in Figure 1. An 533 alternate architecture would be to provide a mechanism for the EAP 534 server to inform the AAA server what channel binding attributes were 535 supplied and the AAA server to inform the EAP server about what 536 channel binding attributes it considered when making its decision. 538 + -------------------------+ 539 -------- ------------- | ---------- ______ | 540 |EAP peer|<---->|Authenticator|<--> | |EAP Server|___(______) | 541 -------- ------------- | ---------- | DB | | 542 . . |AAA (______) | 543 . i1 . +--------------------------+ 544 .<----------------. i2 . . 545 . .------------> . 546 . i1 . 547 .-------------------------------------->. 548 . CB_success/failure(i1, i2,info) . 549 .<--------------------------------------. 551 Figure 1: Overview of Channel Binding Protocol 553 During network advertisement, selection, and authentication, the 554 authenticator presents unauthenticated information, labeled i1, about 555 the network to the peer. Message i1 could include an authenticator 556 identifier and the identity of the network it represents, in addition 557 to advertised network information such as offered services and 558 roaming information. Information may be communicated implicitly in 559 i1, such as the type of media in use. As there is no established 560 trust relationship between the peer and authenticator, there is no 561 way for the peer to validate this information. 563 Additionally, during the transaction the authenticator presents a 564 number of information properties in form of AAA attributes about 565 itself and the current request to the AAA infrastructure which may or 566 may not be valid. This information is labeled i2. Message i2 is the 567 information the AAA server receives from the last hop in the AAA 568 proxy chain which is not necessarily the authenticator. 570 AAA hops between the authenticator and AAA server can validate some 571 of i2. Whether the AAA server will be able to depend on this depends 572 significantly on the business relationship executed with these 573 proxies and on the structure of the AAA network. 575 The local database is perhaps the most important part of this system. 576 In order for the EAP server or AAA server to know whether i1 and i2 577 are correct, they need access to trustworthy information, since an 578 authenticator could include false information in both i1 and i2. 579 Additional reasons why such a database is necessary for channel 580 bindings to work are discussed in the next subsection. The 581 information contained within the database could involve wildcards. 582 For example, this could be used to check whether WiFi access points 583 on a particular IP subnet all use a specific SSID. The exact IP 584 address is immaterial, provided it is on the correct subnet. 586 During an EAP method execution with channel bindings, the peer sends 587 i1 to the EAP server using the mechanism described in Section 5.3. 588 the EAP server verifies the consistency of i1 provided by the peer, 589 i2 provided by the authenticator, and the information in the local 590 database. Upon the check, the EAP server sends a message to the peer 591 indicating whether the channel binding validation check succeeded or 592 failed and includes the attributes that were used in the check. The 593 message flow is illustrated in Figure 1. 595 Above, the EAP server is described as performing the channel binding 596 validation. In most deployments, this will be a necessary 597 implementation constraint. The EAP exchange needs to include an 598 indication of channel binding success or failure. Most existing 599 implementations do not have a way to have an exchange between the EAP 600 server and another AAA entity during the EAP server's processing of a 601 single EAP message. However another AAA entity can provide 602 information to the EAP server to make its decision. 604 If the compliance of i1 or i2 information with the authoritative 605 policy source is mandatory and a consistency check failed, then after 606 sending a protected indication of failed consistency, the EAP server 607 MUST send an EAP-Failure message to terminate the session. If the 608 EAP server is otherwise configured, it MUST allow the EAP session to 609 complete normally, and leave the decision about network access up to 610 the peer's policy. If i1 or i2 does not comply with policy, the EAP 611 server MUST NOT list information that failed to comply in the set of 612 information used to perform channel binding. In this case the EAP 613 server SHOULD indicate channel binding failure; this requirement may 614 be upgraded to a MUST in the future. 616 5.2. Channel Binding Consistency Check 618 The validation check that is the core of the channel binding protocol 619 described in the previous subsection, consists of two parts in which 620 the server checks whether: 622 1. the authenticator is lying to the peer, i.e. i1 contains false 623 information, 625 2. the authenticator or any entity on the AAA path to the AAA server 626 provides false information in form of AAA attributes, i.e. i2 627 contains false information, 629 These checks enable the EAP server to detect lying NAS/authenticator 630 in enterprise networks and lying providers in service provider 631 networks. 633 Checking the consistency of i1 and i2 is nontrivial, as has been 634 pointed out already in [HC07]. First, i1 can contain any type of 635 information propagated by the authenticator, whereas i2 is restricted 636 to information that can be carried in AAA attributes. Second, 637 because the authenticator typically communicates over different link 638 layers with the peer and the AAA infrastructure, different type of 639 identifiers and addresses may have been presented to both 640 communication endpoints. Whether these different identifiers and 641 addresses belong to the same device cannot be directly checked by the 642 EAP server or AAA server without additional information. Finally, i2 643 may be different from the original information sent by the 644 authenticator because of en route processing or malicious 645 modifications. As a result, in the service provider model, typically 646 the i1 information available to the EAP server can only be verified 647 against the last-hop portion of i2, or values propagated by proxy 648 servers. In addition, checking the consistency of i1 and i2 alone is 649 insufficient because an authenticator could lie to both, the peer and 650 the EAP server, i.e. i1 and i2 may be consistent but both contain 651 false information. 653 A local database is required to leverage the above mentioned 654 shortcomings and support the consistency and validation checks. In 655 particular, information stored for each NAS/authenticator (enterprise 656 scenario) or each roaming partner (service provider scenario) enables 657 a comparison of any information received in i1 with AAA attributes in 658 i2 as well as additionally stored AAA attributes that might have been 659 lost in transition. Furthermore, only such a database enables the 660 EAP server and AAA server to check the received information against 661 trusted information about the network including roaming agreements. 663 Section 7 describes lower-layer specific properties that can be 664 exchanged as a part of i1. Section 8 describes specific AAA 665 attributes that can be included and evaluated in i2. The EAP server 666 reports back the results from the channel binding validation check 667 that compares the consistency of all the values with those in the 668 local database. The challenges of setting up such a local database 669 are discussed in Section 10. 671 5.3. EAP Protocol 673 EAP methods supporting channel binding consistent with this 674 specification provide a mechanism for carrying channel binding data 675 from the peer to the EAP server and a channel binding response from 676 the EAP server to the peer. The specifics of this mechanism are 677 dependent on the method, although the content of the channel binding 678 data and channel binding response are defined by this section. 680 Typically the lower layer will communicate a set of attributes to the 681 EAP implementation on the peer that should be part of channel 682 binding. The EAP implementation may need to indicate to the lower 683 layer that channel binding information cannot be sent. Reasons for 684 failing to send channel binding information include an EAP method 685 that does not support channel binding is selected, or channel binding 686 data is too big for the EAP method selected. Peers SHOULD provide 687 appropriate policy controls to select channel binding or mandate its 688 success. 690 The EAP server receives the channel binding data and performs the 691 validation. The EAP method provides a way to return a response; the 692 channel binding response uses the same basic format as the channel 693 binding data. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Code | Length | NSID | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | NS-Specific... | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Length | NSID | NS-Specific... 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Figure 2: Channel Binding Encoding 709 Both the channel binding data and response use the format illustrated 710 in Figure 2. The protocol starts with a one byte code; see 711 Section 5.3.1. Then for each type of attributes contained in the 712 channel binding data, the following information is encoded: 714 Length: Two octets of length in network byte order, indicating the 715 length of the NS-SPECIFIC data. The NSID and length octets are 716 not included. 718 NSID: One octet describing the namespace from which the attributes 719 are drawn. See Section 5.3.3 for a description of how to encode 720 RADIUS attributes in channel binding data and responses. RADIUS 721 uses a namespace identifier of 1 . 723 NS-SPECIFIC: The encoding of the attributes in a manner specific to 724 the type of attribute. 726 A given NSID MUST NOT appear more than once in a channel binding data 727 or channel binding response. Instead, all NS-SPECIFIC data for a 728 particular NSID must occur inside one (NSID, Length, NS-Specific) 729 field. This set of fields may be repeated if multiple namespaces are 730 included. 732 In channel binding data, the code is set to 1 (channel binding data) 733 and the full attributes and values that the peer wishes the EAP 734 server to validate are included. 736 In a channel binding response, the server selects the code; see 737 Section 5.3.1. For successful channel binding, the server returns 738 code 2. The set of attributes that the EAP server returns depend on 739 the code. For success, the server returns the attributes that were 740 considered by the server in making the determination that channel 741 bindings are successfully validated; attributes that the server is 742 unable to check or that failed to validate against what is sent by 743 the peer MUST NOT be returned in a success response. Generally, 744 servers will not return a success response if any attributes were 745 checked and failed to validate those specified by the peer. Special 746 circumstances such as a new attribute being phased in at a server MAY 747 require servers to return success when such an attribute fails to 748 validate. The server returns the value supplied by the peer when 749 returning an attribute in channel binding responses. 751 For channel binding failure (code 3), the server SHOULD include any 752 attributes that were successfully validated. This code means that 753 server policy indicates that the attributes sent by the client do not 754 accurately describe the authenticator. Servers MAY include no 755 attributes in this response, for example if all the attributes 756 supplied by the peer that the server can check failed to be 757 consistent. 759 Peers MUST treat unknown codes as Channel binding Failure. Peers 760 MUST ignore differences between attribute values sent in the channel 761 binding data and those sent in the response. Peers and servers MUST 762 ignore any attributes contained in a field with an unknown NSID. 763 Peers MUST ignore any attributes in a response not present in the 764 channel binding data. 766 5.3.1. Channel Binding Codes 768 +------+-----------------------------------+ 769 | Code | Meaning | 770 +------+-----------------------------------+ 771 | 1 | Channel Binding data from client | 772 | 2 | Channel binding response: success | 773 | 3 | Channel binding response: failure | 774 +------+-----------------------------------+ 776 5.3.2. Namespace Identifiers 778 +-----+-------------+---------------+ 779 | ID | Namespace | Reference | 780 +-----+-------------+---------------+ 781 | 1 | RADIUS | Section 5.3.3 | 782 | 255 | Private Use | | 783 +-----+-------------+---------------+ 785 5.3.3. RADIUS Namespace 787 RADIUS AVPs are encoded with a one-octet attribute type followed by a 788 one-octet length followed by the value of the RADIUS attribute being 789 encoded. The length includes the type and length octets; the minimum 790 legal length is 3. Attributes are concatenated to form the namespace 791 specific portion of the packet. 793 0 1 2 794 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 796 | Type | Length | Value ... 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 799 Figure 3: RADIUS AVP Encoding 801 The full value of an attribute is included in the channel binding 802 data and response. 804 6. System Requirements 806 This section defines requirements on components used to implement the 807 channel bindings protocol. 809 The channel binding protocol defined in this document must be 810 transported after keying material has been derived between the EAP 811 peer and server, and before the peer would suffer adverse affects 812 from joining an adversarial network. This document describes a 813 protocol for performing channel binding within EAP methods. As 814 discussed in Section 4.2, an alternative approach for meeting this 815 requirement is to perform channel bindings during the secure 816 association protocol of the lower layer. 818 6.1. General Transport Protocol Requirements 820 The transport protocol for carrying channel binding information MUST 821 support end-to-end (i.e. between the EAP peer and server) message 822 integrity protection to prevent the adversarial NAS or AAA device 823 from manipulating the transported data. The transport protocol 824 SHOULD provide confidentiality. The motivation for this is that the 825 channel bindings could contain private information, including peer 826 identities, which SHOULD be protected. If confidentiality cannot be 827 provided, private information MUST NOT be sent as part of the channel 828 binding information. 830 Any transport needs to be careful not to exceed the MTU for its 831 lower-layer medium. In particular, if channel binding information is 832 exchanged within protected EAP method channels, these methods may or 833 may not support fragmentation. In order to work with all methods, 834 the channel binding messages must fit within the available payload. 835 For example, if the EAP MTU is 1020 octets, and EAP-GPSK is used as 836 the authentication method, and maximal-length identities are used, a 837 maximum of 384 octets are available for conveying channel binding 838 information. Other methods, such as EAP-TTLS, support fragmentation 839 and could carry significantly longer payloads. 841 6.2. EAP Method Requirements 843 If transporting data directly within an EAP method, it MUST be able 844 to carry integrity protected data from the EAP peer to server. EAP 845 methods SHOULD provide a mechanism to carry protected data from 846 server to peer. EAP methods MUST exchange channel binding data with 847 the AAA subsystem hosting the EAP server. EAP methods MUST be able 848 to import channel binding data from the lower layer on the EAP peer. 850 7. Channel Binding TLV 852 This section defines some channel binding TLVs. While message i1 is 853 not limited to AAA attributes, for the sake of tangible attributes 854 that are already in place, this section discusses AAA AVPs that are 855 appropriate for carrying channel bindings (i.e. data from i1 in 856 Section 5). 858 For any lower-layer protocol, network information of interest to the 859 peer and server can be encapsulated in AVPs or other defined payload 860 containers. The appropriate AVPs depend on the lower layer protocol 861 as well as on the network type (i.e. enterprise network or service 862 provider network) and its application. 864 7.1. Requirements for Lower-Layer Bindings 866 Lower-layer protocols MUST support EAP in order to support EAP 867 channel bindings. These lower layers MUST support EAP methods that 868 derive keying material, as otherwise no integrity-protected channel 869 would be available to execute the channel bindings protocol. Lower- 870 layer protocols need not support traffic encryption, since this is 871 independent of the authentication phase. 873 The data conveyed within the AVP type MUST NOT conflict with the 874 externally-defined usage of the AVP. Additional TLV types MAY be 875 defined for values that are not communicated within AAA attributes. 877 In general, lower layers will need to specify what information should 878 be included in i1. Existing lower layers will probably require new 879 documents to specify this information. Lower layer specifications 880 need to include sufficient information in i1 to uniquely identify 881 which lower layer is involved. The preferred way to do this is to 882 include the eap-lower-layer attribute defined in the next section. 884 This MUST be included in i1 unless an attribute specific to a 885 particular lower layer is included in i1. 887 7.2. EAP Lower Layer Attribute 889 A new RADIUS attribute is defined to carry information on which EAP 890 lower layer is used for this EAP authentication. This Attribute 891 provides information relating to the lower layer over which EAP is 892 transported. This Attribute MAY be sent by the NAS to the RADIUS 893 server in an Access-Request or an Accounting-Request packet. A 894 summary of the EAP-Lower-Layer Attribute format is shown below. The 895 fields are transmitted from left to right. 897 0 1 2 3 898 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 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Type | Length | Value 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 Value (cont) | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 The code is TBD, the length is 6 and the value is a 32-bit unsigned 906 integer in network byte order. The value specifies the EAP lower 907 layer in use. Values are taken from the IANA registry established in 908 Section 11.1. 910 8. AAA-Layer Bindings 912 This section discusses which AAA attributes in a AAA Access-Request 913 message can and should be validated by a EAP server (i.e. data from 914 i2 in Section 5). As noted before, this data can be manipulated by 915 AAA proxies either to enable functionality (e.g. removing realm 916 information after messages have been proxied) or maliciously (e.g. in 917 the case of a lying provider). As such, this data cannot always be 918 easily validated. However as thorough of a validation as possible 919 should be conducted in an effort to detect possible attacks. 921 NAS-IP-Address: This value is typically the IP address of the 922 authenticator, but in a proxied connection it likely will not 923 match the source IP address of an Access-Request. A consistency 924 check MAY verify the subnet of the IP address was correct based on 925 the last-hop proxy. 927 NAS-IPv6-Address: This value is typically the IPv6 address of the 928 authenticator, but in a proxied connection it likely will not 929 match the source IPv6 address of an Access-Request. A consistency 930 check MAY verify the subnet of the IPv6 address was correct based 931 on the last-hop proxy. 933 NAS-Identifier: This is an identifier populated by the NAS to 934 identify the NAS to the AAA server; it SHOULD be validated against 935 the local database. 937 NAS-Port-Type: This specifies the underlying link technology. It 938 SHOULD be validated against the value received from the peer in 939 the information exchange, and against a database of authorized 940 link-layer technologies. 942 9. Security Considerations 944 This section discusses security considerations surrounding the use of 945 EAP channel bindings. 947 9.1. Trust Model 949 In the considered trust model, EAP peer and authentication server are 950 honest while the authenticator is maliciously sending false 951 information to peer and/or server. In the model, the peer and server 952 trust each other, which is not an unreasonable assumption, 953 considering they already have a trust relationship. The following 954 are the trust relationships: 956 o The server trusts that the channel binding information received 957 from the peer is the information that the peer received from the 958 authenticator. 959 o The peer trusts the channel binding result received from the 960 server. 961 o The server trusts the information contained within its local 962 database. 964 In order to establish the first two trust relationships during an EAP 965 execution, an EAP method MUST provide the following: 967 o mutual authentication between peer and server 968 o derivation of keying material including a key for integrity 969 protection of channel binding messages known to the peer and EAP 970 server but not the authenticator 971 o sending channel binding request from peer to server over an 972 integrity-protected channel 974 o sending the channel binding result from server to peer over an 975 integrity-protected channel 977 This trust model is a significant departure from the standard EAP 978 model. In many EAP deployments today attacks where one authenticator 979 can impersonate another are not a significant concern because all 980 authenticators provide the same service. A authenticator does not 981 gain significant advantage by impersonating another authenticator. 982 The use of EAP in situations where different authenticators provide 983 different services may give an attacker who can impersonate a 984 authenticator greater advantage. The system as a whole needs to be 985 analyzed to evaluate cases where one authenticator may impersonate 986 another and to evaluate the impact of this impersonation. 988 One attractive implementation strategy for channel binding is to add 989 channel binding support to a tunnel method which can tunnel an inner 990 EAP authentication. This way, channel binding can be achieved with 991 any method that can act as an inner method even if that inner method 992 does not have native channel binding support. The requirement for 993 mutual authentication and key derivation is at the layer of EAP that 994 actually performs the channel binding. Tunnel methods sometimes use 995 cryptographic binding, a process where a peer proves that the peer 996 for the outer method is the same as the peer for an inner method to 997 tie authentication at one layer together with an inner layer. 998 Cryptographic binding does not always provide mutual authentication; 999 its definition does not require the server to prove that the inner 1000 server and outer server are the same. Even when cryptographic 1001 binding does attempt to confirm that the inner and outer server are 1002 the same, the Master Session Key (MSK) from the inner method is 1003 typically used to protect the binding. An attacker such as an 1004 authenticator that wishes to subvirt channel binding could establish 1005 an outer tunnel terminating at the authenticator. If the outer 1006 method tunnel terminates on the authenticator, the MSK is disclosed 1007 to the authenticator, which can typically attack cryptographic 1008 binding. If the authenticator controls cryptographic binding then it 1009 typically controls the channel binding parameters and results. If 1010 the channel binding process is used to differentiate one 1011 authenticator from another then the authenticator can claim to 1012 support services that it was not authorized to. This attack was not 1013 in scope for existing threat models for cryptographic binding because 1014 differentiated authenticators was not a consideration. Thus, 1015 existing cryptographic binding does not typically provide mutual 1016 authentication of the inner method server required for channel 1017 binding. Other methods besides cryptographic binding are available 1018 to provide mutual authentication required by channel binding. As an 1019 example, if server certificates are validated and names checked, 1020 mutual authentication can be provided directly by the tunnel. 1022 9.2. Consequences of Trust Violation 1024 If any of the trust relationships listed in Section 9.1 are violated, 1025 channel binding cannot be provided. In other words, if mutual 1026 authentication with key establishment as part of the EAP method as 1027 well as protected database access are not provided, then achieving 1028 channel binding is not feasible. 1030 Dishonest peers can only manipulate the first message i1 of the 1031 channel binding protocol. In this scenario, a peer sends i1' to the 1032 server. If i1' is invalid, the channel binding validation will fail. 1033 On the other hand if i1' passes the validation, either the original 1034 i1 was wrong and i1' corrected the problem or both i1 and i1' 1035 constitute valid information. A peer could potentially gain an 1036 advantage in auditing or charging if both are valid and information 1037 from i1' is used for auditing or charging. Such peers can be 1038 detected by including the information in i2 and checking i1 against 1039 i2. 1041 If information from i1 does not validate, an EAP server cannot 1042 generally determine whether the authenticator advertized incorrect 1043 information or whether the peer is dishonest. This should be 1044 considered before using channel binding validation failures to 1045 determine the reputation either of the peer or authenticator. 1047 Dishonest servers can send EAP-Failure messages and abort the EAP 1048 authentication even if the received i1 is valid. However, servers 1049 can always abort any EAP session independent of whether channel 1050 binding is offered or not. On the other hand, dishonest servers can 1051 claim a successful validation even if i1 contains invalid 1052 information. This can be seen as collaboration of authenticator and 1053 server. Channel binding can neither prevent nor detect such attacks. 1054 In general such attacks cannot be prevented by cryptographic means 1055 and should be addressed using policies making servers liable for 1056 their provided information and services. 1058 Additional network entities (such as proxies) might be on the 1059 communication path between peer and server and may attempt to 1060 manipulate the channel binding protocol. If these entities do not 1061 possess the keying material used for integrity protection of the 1062 channel binding messages, the same threat analysis applies as for the 1063 dishonest authenticators. Hence, such entities can neither 1064 manipulate single channel binding messages nor the outcome. On the 1065 other hand, entities with access to the keying material must be 1066 treated like a server in a threat analysis. Hence such entities are 1067 able to manipulate the channel binding protocol without being 1068 detected. However, the required knowledge of keying material is 1069 unlikely since channel binding is executed before the EAP method is 1070 completed, and thus before keying material is typically transported 1071 to other entities. 1073 9.3. Bid-Down Attacks 1075 EAP methods that add channel binding will typically negotiate its 1076 use. Even for entirely new EAP methods designed with channel binding 1077 from the first version, some deployments may not use it. It is 1078 desirable to protect against attacks on the negotiation of channel 1079 bindings. An attacker including the NAS SHOULD NOT be able to 1080 prevent a peer and server who support channel bindings from using it. 1082 Unfortunately existing EAP methods may make it difficult or 1083 impossible to protect against attacks on negotiation. For example, 1084 many EAP state machines will accept a success message at any point 1085 after key derivation to terminate authentication. EAP success 1086 methods are not integrity protected; an attacker who could insert a 1087 message can generate one. The NAS is always in a position to 1088 generate a success message. Common EAP servers take advantage of 1089 state machines accepting success messages even in cases where an EAP 1090 method might support a protected indication of success. It may be 1091 challenging to define channel binding support for existing EAP 1092 methods in a manner that permits peers to distinguish an old EAP 1093 server that sends a success indication and does not support channel 1094 binding from an attacker injecting a success indication. 1096 9.4. Privacy Violations 1098 While the channel binding information exchanged between EAP peer and 1099 EAP server (i.e. i1 and the result message) must always be integrity- 1100 protected it may not be encrypted. In the case that these messages 1101 contain identifiers of peer and/or network entities, the privacy 1102 property of the executed EAP method may be violated. Hence, in order 1103 to maintain the privacy of an EAP method, the exchanged channel 1104 binding information must be encrypted. If encryption is not 1105 available, private information is not sent as part of the channel 1106 binding information, as described in Section 6.1. 1108 Privacy implications of attributes selected for channel binding need 1109 to be considered. Consider channel binding the username attribute. 1110 A peer sends a privacy protecting anonymous identifier in its EAP 1111 identity message, but sends the full username in the protected i1 1112 message. However the authenticator would like to learn the full 1113 username. It makes a guess and sends that in i2 rather than the 1114 anonymous identifier. If the EAP server validates this attribute and 1115 fails when the username from the peer mismatches i2, then the EAP 1116 server confirms the authenticator's guess. Similar privacy exposures 1117 may result whenever one party is in a position to guess channel 1118 binding information provided by another party. 1120 10. Operations and Management Considerations 1122 As with any extension to existing protocols, there will be an impact 1123 on existing systems. Typically the goal is to develop an extension 1124 that minimizes the impact on both development and deployment of the 1125 new system, subject to the system requirements. This section 1126 discusses the impact on existing devices that currently utilize EAP, 1127 assuming the channel binding information is transported within the 1128 EAP method execution. 1130 The EAP peer will need an API between the EAP lower layer and the EAP 1131 method that exposes the necessary information from the NAS to be 1132 validated to the EAP peer, which can then feed that information into 1133 the EAP methods for transport. For example, an IEEE 802.11 system 1134 would need to make available the various information elements that 1135 require validation to the EAP peer which would properly format them 1136 and pass them to the EAP method. Additionally, the EAP peer will 1137 require updated EAP methods that support transporting channel binding 1138 information. While most method documents are written modularly to 1139 allow incorporating arbitrary protected information, implementations 1140 of those methods would need to be revised to support these 1141 extensions. Driver updates are also required so methods can access 1142 the required information. 1144 No changes to the pass-through authenticator would be required. 1146 The EAP server would need an API between the database storing NAS 1147 information and the individual EAP server. The database may already 1148 exist on the AAA server in which case the EAP server passes the 1149 parameters to the AAA server for validation. The EAP methods need to 1150 be able to export received channel binding information to the EAP 1151 server so it can be validated. 1153 11. IANA Considerations 1155 A new top level registry is created for "EAP Channel Binding 1156 Parameters." This registry consists of several sub registries. 1158 The "Channel Binding Codes" sub-registry defines values for the code 1159 field in the channel binding data and channel binding response 1160 packet. See the table in Section 5.3.1 for initial registrations. 1161 This registry requires standards action [RFC5226] for new 1162 registrations. Early allocation [RFC4020] is allowed. An additional 1163 reference column should be added to the table for the registry, 1164 pointing all codes in the initial registration to this specification. 1165 Valid values in this sub-registry range from 0-255; 0 is reserved. 1167 The "Channel Binding Namespaces" sub-registry contains registrations 1168 for the NSID field in the channel binding data and channel binding 1169 response. Initial registrations are found in the table in 1170 Section 5.3.2. Registrations in this registry require IETF review. 1171 Valid values range from 0-255; 0 is reserved. As with the Channel 1172 Binding Codes sub-registry a reference column should be included and 1173 should point to this document for initial registrations. 1175 11.1. EAP Lower Layers Registry 1177 A new sub registry in the EAP Numbers registry at 1178 http://www.iana.org/assignments/eap-numbers is created for EAP Lower 1179 Layers. Registration requires expert review; the primary role of the 1180 expert is to prevent multiple registrations for the same lower layer. 1182 The following table gives the initial registrations for this 1183 registry. 1185 +-------+----------------------------------------+ 1186 | Value | Lower Layer | 1187 +-------+----------------------------------------+ 1188 | 1 | Wired IEEE 802.1X | 1189 | 2 | IEEE 802.11 (no-pre-auth) | 1190 | 3 | IEEE 802.11 (pre-authentication) | 1191 | 4 | IEEE 802.16e | 1192 | 5 | IKEv2 | 1193 | 6 | PPP | 1194 | 7 | PANA (no pre-authentication) [RFC5191] | 1195 | 8 | GSS-API [I-D.ietf-abfab-gss-eap] | 1196 | 9 | PANA (pre-authentication) [RFC5873] | 1197 +-------+----------------------------------------+ 1199 11.2. RADIUS Registration 1201 A new RADIUS attribute is registered with the name EAP-Lower-Layer; 1202 TBD should be replaced with the number corresponding to this 1203 attribute. The RADIUS attributes are in the registry at 1204 http://www.iana.org/assignments/radius-types/radius-types.xml 1206 12. Acknowledgments 1208 The authors and editor would like to thank Bernard Aboba, Glen Zorn, 1209 Joe Salowey, Stephen Hanna, and Klaas Wierenga for their valuable 1210 inputs that helped to improve and shape this document over the time. 1212 Sam Hartman's work on this specification is funded by JANET(UK). 1214 The EAP-Lower-Layer attribute was taken from draft-aboba-radext-wlan 1215 [I-D.aboba-radext-wlan]. 1217 13. References 1219 13.1. Normative References 1221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1222 Requirement Levels", BCP 14, RFC 2119, March 1997. 1224 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1225 Levkowetz, "Extensible Authentication Protocol (EAP)", 1226 RFC 3748, June 2004. 1228 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1229 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1230 May 2008. 1232 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 1233 Standards Track Code Points", BCP 100, RFC 4020, 1234 February 2005. 1236 13.2. Informative References 1238 [I-D.aboba-radext-wlan] 1239 Aboba, B., Malinen, J., Congdon, P., and J. Salowey, 1240 "RADIUS Attributes for IEEE 802 Networks", 1241 draft-aboba-radext-wlan-15 (work in progress), 1242 October 2011. 1244 [I-D.clancy-emu-aaapay] 1245 Clancy, T., Lior, A., and G. Zorn, Ed., "EAP Method 1246 Support for Transporting AAA Payloads", Internet 1247 Draft draft-clancy-emu-aaapay-02, May 2009. 1249 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1250 Authentication Protocol (EAP) Method Requirements for 1251 Wireless LANs", RFC 4017, March 2005. 1253 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1254 Channels", RFC 5056, November 2007. 1256 [HC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", 1257 ICST QShine, August 2007. 1259 [80211U-D4.01] 1260 "Information technology - Telecommunications and 1261 information exchange between systems - Local and 1262 metropolitan area networks - Specific requirements - Part 1263 11: Wireless LAN Medium Access Control (MAC) and Physical 1264 Layer (PHY) specifications - Amendment 7: Interworking 1265 with External Networks", IEEE Draft Standard 802.11u, 1266 November 2008. 1268 [I-D.ietf-abfab-gss-eap] 1269 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 1270 Extensible Authentication Protocol", 1271 draft-ietf-abfab-gss-eap-06 (work in progress), 1272 April 2012. 1274 [RFC5873] Ohba, Y. and A. Yegin, "Pre-Authentication Support for the 1275 Protocol for Carrying Authentication for Network Access 1276 (PANA)", RFC 5873, May 2010. 1278 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 1279 authentication Protocol (ERP)", RFC 5296, August 2008. 1281 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1282 Yegin, "Protocol for Carrying Authentication for Network 1283 Access (PANA)", RFC 5191, May 2008. 1285 Appendix A. Attacks Prevented by Channel Bindings 1287 In the following it is demonstrated how the presented channel 1288 bindings can prevent attacks by malicious authenticators 1289 (representing the lying NAS problem) as well as malicious visited 1290 networks (representing the lying provider problem). This document 1291 only provides part of the solution necessary to realize a defense 1292 against these attacks. In addition, lower-layer protocols need to 1293 describe what attributes should be included in channel binding 1294 requests. EAP methods need to be updated in order to describe how 1295 the channel binding request and response are carried. In addition, 1296 deployments may need to decide what information is populated in the 1297 local database. The following sections describe types of attacks 1298 that can be prevented by this framework with appropriate lower-layer 1299 attributes carried in channel bindings, EAP methods with channel 1300 binding support and appropriate local database information at the EAP 1301 server. 1303 A.1. Enterprise Subnetwork Masquerading 1305 As outlined in Section 3, an enterprise network may have multiple 1306 VLANs providing different levels of security. In an attack, a 1307 malicious NAS connecting to a guest network with lesser security 1308 protection could broadcast the SSID of a subnetwork with higher 1309 protection. This could lead peers to believe that they are accessing 1310 the network over secure connections, and, e.g., transmit confidential 1311 information that they normally would not send over a weakly protected 1312 connection. This attack works under the conditions that peers use 1313 the same set of credentials to authenticate to the different kinds of 1314 VLANs and that the VLANs support at least one common EAP method. If 1315 these conditions are not met, the EAP server would not authorize the 1316 peers to connect to the guest network, because the peers used 1317 credentials and/or an EAP method that is associated with the 1318 corporate network. 1320 A.2. Forced Roaming 1322 Mobile phone providers boosting their cell tower's transmission power 1323 to get more users to use their networks have occurred in the past. 1324 The increased transmission range combined with a NAS sending a false 1325 network identity lures users to connect to the network without being 1326 aware of that they are roaming. 1328 Channel bindings would detect the bogus network identifier because 1329 the network identifier send to the authentication server in i1 will 1330 neither match information i2 nor the stored data. The verification 1331 fails because the info in i1 claims to come from the peer's home 1332 network while the home authentication server knows that the 1333 connection is through a visited network outside the home domain. In 1334 the same context, channel bindings can be utilized to provide a "home 1335 zone" feature that notifies users every time they are about to 1336 connect to a NAS outside their home domain. 1338 A.3. Downgrading attacks 1340 A malicious authenticator could modify the set of offered EAP methods 1341 in its Beacon to force the peer to choose from only the weakest EAP 1342 method(s) accepted by the authentication server. For instance, 1343 instead of having a choice between EAP-MD5-CHAP, EAP-FAST and some 1344 other methods, the authenticator reduces the choice for the peer to 1345 the weaker EAP-MD5-CHAP method. Assuming that weak EAP methods are 1346 supported by the authentication server, such a downgrading attack can 1347 enable the authenticator to attack the integrity and confidentiality 1348 of the remaining EAP execution and/or break the authentication and 1349 key exchange. The presented channel bindings prevent such 1350 downgrading attacks, because peers submit the offered EAP method 1351 selection that they have received in the beacon as part of i1 to the 1352 authentication server. As a result, the authentication server 1353 recognizes the modification when comparing the information to the 1354 respective information in its policy database. This presumes that 1355 all acceptable EAP methods support channel binding and that an 1356 attacker cannot break the EAP method in real-time. 1358 A.4. Bogus Beacons in IEEE 802.11r 1360 In IEEE 802.11r, the SSID is bound to the TSK calculations, so that 1361 the TSK needs to be consistent with the SSID advertised in an 1362 authenticator's Beacon. While this prevents outsiders from spoofing 1363 a Beacon it does not stop a "lying NAS" from sending a bogus Beacon 1364 and calculating the TSK accordingly. 1366 By implementing channel bindings, as described in this draft, in IEEE 1367 802.11r, the verification by the authentication server would detect 1368 the inconsistencies between the information the authenticator has 1369 sent to the peer and the information the server received from the 1370 authenticator and stores in the policy database. 1372 A.5. Forcing false authorization in IEEE 802.11i 1374 In IEEE 802.11i a malicious NAS can modify the beacon to make the 1375 peer believe it is connected to a network different from the one the 1376 peer is actually connected to. 1378 In addition, a malicious NAS can force an authentication server into 1379 authorizing access by sending an incorrect Called-Station-ID that 1380 belongs to an authorized NAS in the network. This could cause the 1381 authentication server to believe it had granted access to a different 1382 network or even provider than the one the peer got access to. 1384 Both attacks can be prevented by implementing channel bindings, 1385 because the server can compare the information that was sent to the 1386 peer, with information it received from the authenticator during the 1387 AAA communication as well as the information stored in the policy 1388 database. 1390 Appendix B. Change History 1392 RFC editor, remove this section prior to publication. 1394 B.1. Changes Since 09 1396 Based on WG discussion, all assigned numbers start at 1, including 1397 NSIDs and codes. 1399 Based on WG discussion we include the value of attributes in the 1400 RADIUS namespace in channel binding responses. 1402 B.2. Changes since Version 06 1404 The purpose of this revision is to provide a specific candidate 1405 protocol for channel binding data and channel binding responses. 1407 B.3. Changes since version 04 1409 o Clarify examples in introduction. 1410 o In problem statement note that one EAP server may deal with both 1411 enterprise and provider networks. 1412 o Update discussion of the architecture. Talk about channel 1413 bindings as a mechanism to introduce levels of trust. 1414 o Indicate that this document is focusing on EAP channel bindings 1415 within methods while trying to do a better job of describing the 1416 SAP approach in more detail. 1417 o Claim that we're using the encoding from draft-clancy-emu-aaapay. 1418 The WG almost certainly doesn't have consensus on this, but in the 1419 interest of actually describing what the protocol might be like, 1420 it is a good straw-man proposal. 1421 o Update protocol description. 1423 Authors' Addresses 1425 Sam Hartman (editor) 1426 Painless Security 1427 356 Abbott ST 1428 North Andover, MA 01845 1429 USA 1431 Email: hartmans-ietf@mit.edu 1433 T. Charles Clancy 1434 Department of Electrical Engineering and Computer Science 1435 Virginia Tech 1436 Arlington, VA 22203 1437 USA 1439 Email: tcc@vt.edu 1440 Katrin Hoeper 1441 Motorola, Inc. 1442 1301 E. Algonquin Road 1443 Schaumburg, IL 60196 1444 USA 1446 Email: khoeper@motorolasolutions.com