idnits 2.17.1 draft-clancy-emu-chbind-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 905. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 923. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 929. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5651 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) == Missing Reference: 'TBD' is mentioned on line 729, but not defined == Unused Reference: 'I-D.ietf-dime-rfc3588bis' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'RFC4017' is defined on line 768, but no explicit reference was found in the text == Unused Reference: 'RFC5247' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'HC07' is defined on line 779, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-aboba-radext-wlan-09 -- Possible downref: Normative reference to a draft: ref. 'I-D.aboba-radext-wlan' == Outdated reference: A later version (-34) exists of draft-ietf-dime-rfc3588bis-13 == Outdated reference: A later version (-04) exists of draft-clancy-emu-aaapay-01 -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Clancy 3 Internet-Draft LTS 4 Intended status: Standards Track K. Hoeper 5 Expires: May 7, 2009 NIST 6 November 3, 2008 8 Channel Binding Support for EAP Methods 9 draft-clancy-emu-chbind-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 7, 2009. 36 Abstract 38 This document defines how to implement channel bindings for 39 Extensible Authentication Protocol (EAP) methods to address the lying 40 NAS problem. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 50 4. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 6 52 5. Channel Binding Protocol . . . . . . . . . . . . . . . . . . . 9 54 6. System Requirements . . . . . . . . . . . . . . . . . . . . . 10 56 7. Lower-Layer Bindings . . . . . . . . . . . . . . . . . . . . . 11 57 7.1. General Attributes . . . . . . . . . . . . . . . . . . . . 12 58 7.2. IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 12 59 7.2.1. IEEE 802.11r . . . . . . . . . . . . . . . . . . . . . 12 60 7.2.2. IEEE 802.11s . . . . . . . . . . . . . . . . . . . . . 12 61 7.3. IEEE 802.16 . . . . . . . . . . . . . . . . . . . . . . . 13 62 7.4. Wired 802.1X . . . . . . . . . . . . . . . . . . . . . . . 13 63 7.5. Point to Point Protocol (PPP) . . . . . . . . . . . . . . 13 64 7.6. Internet Key Exchange v2 (IKEv2) . . . . . . . . . . . . . 13 65 7.7. 3GPP2 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 7.8. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 8. AAA-Layer Bindings . . . . . . . . . . . . . . . . . . . . . . 13 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 9.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 14 72 9.2. Consequences of Trust Violation . . . . . . . . . . . . . 15 73 9.3. Privacy Violations . . . . . . . . . . . . . . . . . . . . 16 75 10. Operations and Management Considerations . . . . . . . . . . . 16 76 10.1. System Impact . . . . . . . . . . . . . . . . . . . . . . 16 77 10.2. Cost-Benefit Analysis . . . . . . . . . . . . . . . . . . 17 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 85 Appendix A. Attacks Prevented by Channel Bindings . . . . . . . . 18 86 A.1. Enterprise Subnetwork Masquerading . . . . . . . . . . . . 18 87 A.2. Forced Roaming . . . . . . . . . . . . . . . . . . . . . . 19 88 A.3. Downgrading attacks . . . . . . . . . . . . . . . . . . . 19 89 A.4. Bogus Beacons in IEEE 802.11r . . . . . . . . . . . . . . 20 90 A.5. Forcing false authorization in IEEE 802.11i . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 93 Intellectual Property and Copyright Statements . . . . . . . . . . 22 95 1. Introduction 97 The so-called "lying NAS" problem is a well-documented problem with 98 the current Extensible Authentication Protocol (EAP) architecture 99 [RFC3748] when used in pass-through authenticator mode. Here, a 100 Network Access Server (NAS), or pass-through authenticator, may 101 represent one set of information (e.g. network identity, 102 capabilities, configuration, etc) to the backend Authentication, 103 Authorization, and Accounting (AAA) infrastructure, while 104 representing contrary information to EAP clients. Another 105 possibility is that the same false information could be provided to 106 both the EAP client and EAP server by the NAS. 108 A concrete example of this may be an IEEE 802.11 access point with a 109 security association to a particular AAA server. While there may be 110 some identity tied to that security association, there's no reason 111 the access point needs to advertise a consistent identity to clients. 112 In fact, it may include whatever information in its beacons (e.g. 113 different SSID or security properties) it desires. This could lead 114 to situations where, for example, a client joins one network that is 115 masquerading as another. 117 Another current limitation of EAP is its minimal ability to perform 118 authorization. Currently EAP servers can only make authorization 119 decisions about network access based on information they know about 120 peers. If the same EAP server controls access to multiple networks, 121 it has little information about the NAS to which the peer is 122 connecting, and does not know what information the NAS may be 123 claiming about the network to the peer. A mechanism is needed that 124 allows the EAP server to apply more detailed policies to 125 authorization. 127 This document defines and implements EAP channel bindings to solve 128 these two problems, using a process in which the EAP client provides 129 information about the characteristics of the service provided by the 130 authenticator to the AAA server protected within the EAP method. 131 This allows the server to verify the authenticator is providing 132 information to the peer consistent with the defined network policy, 133 and that the peer is authorized to access the network in the manner 134 described by the NAS. "AAA Payloads" defined in 135 [I-D.clancy-emu-aaapay] proposes a mechanism to carry this 136 information. 138 2. Terminology 140 In this document, several words are used to signify the requirements 141 of the specification. These words are often capitalized. The key 142 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 143 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 144 are to be interpreted as described in [RFC2119]. 146 3. Problem Statement 148 In a [RFC4017]-compliant EAP authentication, the EAP client and EAP 149 server mutually authenticate each other, and derive keying material. 150 However, when operating in pass-through mode, the EAP server can be 151 far removed from the authenticator. A malicious or compromised 152 authenticator may represent incorrect information about the network 153 to the client in an effort to affect its operation in some way. 154 Additionally, while an authenticator may not be compromised, other 155 compromised elements in the network could provide false information 156 to the authenticator that it could simply be relaying to EAP clients. 157 Our goal is to ensure that the authenticator is providing correct 158 information to the EAP client during the initial network discovery, 159 selection, and authentication. 161 There are two different types of networks to consider: enterprise 162 networks and service provider networks. In enterprise networks, we 163 assume a single administrative domain, making it feasible for an EAP 164 server to have information about all the authenticators in the 165 network. In service provider networks, global knowledge is 166 infeasible due to indirection via roaming. When a client is outside 167 its home administrative domain, the goal is to ensure that the level 168 of service received by the client is consistent with the contractual 169 agreement between the two service providers. 171 The following are a couple example attacks possible by presenting 172 false network information to clients. 174 o Enterprise Network: A corporate network may have multiple virtual 175 LANs (VLANs) running throughout their campus network, and have 176 IEEE 802.11 access points connected to each VLAN. Assume one VLAN 177 connects users to the firewalled corporate network, while the 178 other connects users to a public guest network. The corporate 179 network is assumed to be free of adversarial elements, while the 180 guest network is assumed to possibly have malicious elements. 181 Access Points on both VLANs are serviced by the same EAP server, 182 but broadcast different SSIDs to differentiate. A compromised 183 access point connected to the guest network could advertise the 184 SSID of the corporate network in an effort to lure clients to 185 connect to a network with a false sense of security regarding 186 their traffic. Conditions and further details of this attack can 187 be found in the Appendix. 189 o Service Provider Network: An EAP-enabled mobile phone provider 190 operating along a geo-political boundary could boost their cell 191 towers' transmission power and advertise the network identity of 192 the neighboring country's indigenous provider. This would cause 193 unknowing handsets to associate with an unintended operator, and 194 consequently be subject to high roaming fees without realizing 195 they had roamed off their home provider's network. This scenario 196 can be considered as "lying provider" problem, because here the 197 provider tampers with the transmission power and then configures 198 its NAS to broadcast another network's identity. For the purpose 199 of channel bindings as defined in this draft, it does not matter 200 which local entity (or entities) is "lying" in a service provider 201 network (local NAS, local authentication server and/or local 202 proxies), because the only information received from the visited 203 network that is verified by channel bindings is the information 204 the home authentication server received from the last hop in the 205 communication chain. In other words, channel bindings enable the 206 detection of inconsistencies in the information from a visited 207 network, but cannot determine which entity is lying. Naturally, 208 channel bindings for EAP methods can only verify the endpoints 209 and, if desirable, intermediate hops need to be protected by the 210 employed AAA protocol. 212 To address these problems, a mechanism is required to validate 213 unauthenticated information advertised by EAP authenticators. 215 4. Channel Bindings 217 EAP channel bindings seek to authenticate previously unauthenticated 218 information provided by the authenticator to the EAP peer, by 219 allowing the client and server to compare their perception of network 220 properties in a secure channel. 222 It should be noted that the definition of EAP channel bindings 223 differs somewhat from channel bindings documented in [RFC5056], which 224 seek to securely bind together the end points of a multi-layer 225 protocol, allowing lower layers to protect data from higher layers. 226 Unlike [RFC5056], EAP channel bindings do not ensure the binding 227 different layers of a session but rather the information advertised 228 to EAP client by an authenticator acting as pass-through device 229 during an EAP execution. 231 There are two main approaches to EAP channel bindings: 233 o After keys have been derived during an EAP execution, the peer and 234 server can, in an integrity-protected channel, exchange plaintext 235 information about the network with each other, and verify 236 consistency and correctness. 238 o Network information can be uniquely encoded into an opaque blob 239 that can be included directly into the derivation of the EAP 240 session keys. 242 Both approaches are only applicable to key deriving EAP methods and 243 both have advantages and disadvantages. Advantages of exchanging 244 plaintext information include: 246 o It allows for policy-based comparisons of network properties, 247 rather than requiring precise matches for every field, which 248 achieves a policy-defined consistency, rather than bitwise 249 equality. This allows network operators to define which 250 properties are important and even verifiable in their network. 252 o EAP methods that support extensible, integrity-protected channels 253 can easily include support for exchanging this network 254 information. In contrast, direct inclusion into the key 255 derivation would require revisions to existing EAP methods or a 256 wrapper EAP method. 258 o Given it doesn't affect the key derivation, this approach 259 facilitates debugging, incremental deployment, backward 260 compatibility and a logging mode in which verification results are 261 recorded but do not have an affect on the remainder of the EAP 262 execution. The exact use of the verification results can be 263 subject to the network policy. Additionally, consistent 264 information canonicalization and formatting for the key derivation 265 approach would likely cause significant deployment problems. 267 The following are advantages of directly including channel binding 268 information in the key derivation: 270 o EAP methods not supporting extensible, integrity-protected 271 channels could still be supported, either by revising their key 272 derivation, revising EAP, or wrapping them in a universal method 273 that supports channel binding. 275 o It can guarantee proper channel information, since subsequent 276 communication would be impossible if differences in channel 277 information yielded different session keys on the EAP client and 278 server. 280 The scope of EAP channel bindings differs somewhat depending on the 281 type of deployment in which they are being used. In enterprise 282 networks, they can be used to authenticate very specific properties 283 of the authenticator (e.g. MAC address, supported link types and 284 data rates, etc), while in service provider networks they can 285 generally only authenticate broader information about a roaming 286 partner's network (e.g. network name, roaming information, link 287 security requirements, etc). The reason for the difference has to do 288 with the amount of information you expect your home EAP server to 289 know about the authenticator and/or network to which the peer is 290 connected. In roaming cases, the home server is likely to only know 291 information contained in their roaming agreements. 293 With any multi-hop AAA infrastructure, many of the specific NAS 294 properties are obscured by the AAA proxy that's decrypting, 295 reframing, and retransmitting the underlying AAA messages. 296 Especially service provider networks are affected by this and the 297 information received from the last hop may not contain much 298 verifiable information any longer. For example, information such as 299 the NAS IP address may not be known to the EAP server. This affects 300 the ability of the EAP server to verify specific NAS properties. 301 However, often verification of the MAC or IP address of the NAS is 302 not useful for improving the overall security posture of a network. 303 More often it is useful to make policy decisions about services being 304 offered to peers. For example, in an IEEE 802.11 network, the EAP 305 server may wish to ensure that clients connecting to the corporate 306 intranet are using secure link- layer encryption, while link-layer 307 security requirements for clients connecting to the guest network 308 could be less stringent. These types of policy decisions can be made 309 without knowing or being able to verify the IP address of the NAS 310 through which the peer is connecting. Furthermore, as described in 311 the next section, channel bindings also verify the information 312 provided by peer and a local policy database, where both pieces of 313 information are unaffected by the processing of intermediate hops. 314 Consequently, even if some information got lost in transition and 315 thus may not be known to the EAP server, the server is still able to 316 carry out the channel binding verification. 318 Also, a peer's expectations of a network may also differ. In a 319 mobile phone network, peers generally don't care what the name of the 320 network is, as long as they can make their phone call and are charged 321 the expected amount for the call. However, in an enterprise network 322 a peer may be more concerned with specifics of where their network 323 traffic is being routed. 325 Any deployment of channel bindings should take into consideration 326 both what information the EAP server is likely to know, and also what 327 type of network information the peer would want and need 328 authenticated. 330 5. Channel Binding Protocol 332 This section defines a protocol for verifying channel binding 333 information during an EAP authentication. The protocol uses the 334 approach where plaintext data is exchanged, since it allows channel 335 bindings to be used more flexibly in varied deployment models. 337 --- 338 -------- ------------- / \ ---------- 339 |EAP peer|<---->|Authenticator|<-->( AAA )<-->|EAP Server| 340 -------- ------------- \ / ---------- 341 . i1 . --- . | ______ 342 .<-----------------. . | (______) 343 . . i2 . \--| | 344 . .-------------------------->. |Policy| 345 . i1 . | DB | 346 .--------------------------------------------->. (______) 347 . isConsistant(i1, i2, Policy) . 348 .<---------------------------------------------. 350 Figure 1: Overview of Channel Binding 352 Channel bindings are always provided between two communication 353 endpoints, here the EAP client and server, who communicate through an 354 authenticator in pass-trough mode. During network advertisement, 355 selection, and authentication, the authenticator presents 356 unauthenticated information, labeled i1 for convenience, about the 357 network to the peer. This information, i1, could include an 358 authenticator identifier and the identity of the network it 359 represents, in addition to advertised network information such as 360 offered services and roaming information. As there is no established 361 trust relationship between the peer and authenticator, there is no 362 way for the peer to validate this information. 364 Additionally, during the transaction the authenticator presents a 365 number of information properties about itself to the AAA 366 infrastructure which may or may not be valid. We label this 367 information i2. Note that i2 is the information the EAP server 368 receives from the last hop in the communication chain which is not 369 necessarily the authenticator. In those cases i2 may be different 370 from the original information sent by the authenticator because of en 371 route processing or malicious modifications. As a result, in the 372 service provider model, typically the EAP server is able to verify 373 only the last-hop portion of i2, or values propagated by proxy 374 servers. 376 Our goal is to transport i1 from the peer to the server, and allow 377 the server to verify the consistency of i1 from the peer and i2 from 378 the authenticator against the information stored in its local policy 379 database. 381 By doing this, we allow the EAP server the opportunity to make 382 informed decisions about authorization. The EAP server can 383 authenticate the authenticator via the AAA security association, and 384 using this channel bindings mechanism it can now authorize the 385 circumstances under which a peer connects to the authenticator. 387 This information, i1, could include an authenticator identifier and 388 the identity of the network it represents, in addition to advertised 389 network information such as offered services and roaming information. 390 To prevent attacks by a lying NAS or lying provider, the EAP server 391 must be able to verify that i1 either matches its knowledge of the 392 network (enterprise model) or is consistent with the contractual 393 agreement between itself and the roaming partner network to which the 394 client is connected (service provider model). Additionally, it 395 should verify that this information is consistent with i2. 397 The protocol defined in this document is a single round trip between 398 the EAP peer and server that can be piggybacked to the EAP method 399 execution, and formats data elements as Diameter AVPs. We provide 400 requirements for a transport protocol. 402 6. System Requirements 404 The channel binding protocol defined in this document must be 405 transported after keying material has been derived between the EAP 406 peer and server, and before the peer would suffer adverse affects 407 from joining an adversarial network. To satisfy this requirement, it 408 should occur either during the EAP method execution or during the EAP 409 lower layer's secure association protocol. 411 The transport protocol for carrying channel binding information MUST 412 support end-to-end (i.e. between the EAP peer and server) message 413 integrity protection to prevent the adversarial NAS or AAA device 414 from manipulating the transported data. The transport protocol 415 SHOULD provide confidentiality. The motivation for this that the 416 channel bindings could contain private information, including peer 417 identities, which SHOULD be protected. 419 If transporting data directly within an EAP method, it MUST be able 420 to carry integrity protected data from the EAP peer to server. EAP 421 methods SHOULD provide a mechanism to carry protected data from 422 server to peer. EAP methods MUST export channel binding data to the 423 AAA subsystem on the EAP server. EAP methods MUST be able to import 424 channel binding data from the lower layer on the EAP peer. 426 One way to transport the single round-trip exchange is as a series of 427 Diameter AVPs formatted and encapsulated in EAP methods per 428 [I-D.clancy-emu-aaapay]. For each lower layer, this document defines 429 the parameters of interest, and the appropriate Diameter AVPs for 430 transporting them. Additionally, guidance on how to perform 431 consistency checks on those values will be provided. 433 In order to minimize data formatting inconsistencies, parameters 434 useful for channel binding MUST be allocated from the standard RADIUS 435 space. Two AVPs are considered equivalent for the purpose of channel 436 binding if they have the same AVP Code, Vendor-Specific Bit, AVP 437 Length, Vendor-ID (if Vendor-Specific Bit is set), and data. 439 7. Lower-Layer Bindings 441 This section discusses AVPs of some EAP-employing lower layer link 442 protocols that seem appropriate for providing channel bindings (i.e. 443 data from "i1" in Section Section 5). The discussion is limited to 444 protocols that establish fresh authentic keying material because such 445 keying material is necessary to protect the integrity of all AVPs 446 that are exchanged as part of the channel binding. For each 447 protocol, a variety of network information that can be encapsulated 448 in AVPs is of interest for server and peer to ensure channel binding. 449 The respective appropriate AVPs depend on the lower layer protocol as 450 well as on the network type (i.e. enterprise network or service 451 provider network) of an application. 453 For each EAP lower layer, a variety of AAA properties may be of 454 interest to the server. These values may already be known by the 455 server, or may be transported to the server via an existing RADIUS or 456 Diameter connection. 458 As part of the channel binding protocol, the EAP peer sends 459 encapsulated AVPs to the server. The server then validates the 460 received information by comparing it to information stored in a local 461 database. If the received information is unsatisfactory given some 462 validation policy, the server SHOULD respond by halting the EAP 463 authentication and returning an EAP-Failure. 465 If validation is successful, the server SHOULD send a message 466 indicating the success to the client. In addition, the server MAY 467 respond back to the EAP peer with information encapsulated in AVPs 468 that can be of use to the peer, and information the peer may not have 469 any way of otherwise knowing. 471 7.1. General Attributes 473 This section lists AVPs useful to all link-layers. 475 NAS-Port-Type: Indicates the underlying link-layer technology used 476 to connect (e.g. IEEE 802.11, PPP, etc), and MUST be included by 477 the EAP client, and SHOULD be verified against the database and 478 NAS-Port-Type received from the NAS. 480 Cost-Information: AVP from the Diameter Credit-Control Application 481 [RFC4006] to the peer indicating how much peers will be billed for 482 service and MAY be included by the EAP client and verified against 483 roaming profiles stored in the database. 485 7.2. IEEE 802.11 487 The client SHOULD transmit to the server the following fields, 488 encapsulated within the appropriate Diameter AVPs: 490 Called-Station-Id: contains BSSID and SSID and MUST be included by 491 the EAP client, and SHOULD be verified against the database and 492 Called-Station-Id received from the NAS 494 [TODO: Need a way to transport the RSN-IE.] 496 7.2.1. IEEE 802.11r 498 In addition to the AVPs for IEEE 802.11, an IEEE 802.11r client 499 SHOULD transmit the following additional fields: 501 Mobility-Domain-Id: Identity of the mobility domain and MUST be 502 included by the EAP client, and SHOULD be verified against the 503 database and Mobility-Domain-Id received from the NAS 504 [I-D.aboba-radext-wlan] 506 7.2.2. IEEE 802.11s 508 In addition to the AVPs for IEEE 802.11, an IEEE 802.11s client 509 SHOULD transmit the following additional fields: 511 Mesh-Key-Distributor-Domain-Id: Identity of the Mesh Key Distributor 512 Domain and MUST be included by the EAP client, and SHOULD be 513 verified against the database and Mesh-Key-Distributor-Domain-Id 514 received from the NAS [I-D.aboba-radext-wlan] 516 7.3. IEEE 802.16 518 TBD 520 7.4. Wired 802.1X 522 TBD 524 7.5. Point to Point Protocol (PPP) 526 TBD 528 7.6. Internet Key Exchange v2 (IKEv2) 530 TBD 532 7.7. 3GPP2 534 TBD 536 7.8. PANA 538 TBD 540 8. AAA-Layer Bindings 542 This section discusses which AAA attributes in RADIUS Accept-Request 543 messages can and should be validated by a AAA server (i.e. data from 544 "i2" in Section Section 5). As noted before, this data can be 545 manipulated by AAA proxies either to enable functionality (e.g. 546 removing realm information after messages have been proxied) or 547 maliciously (e.g. in the case of a lying provider). As such, this 548 data cannot always be easily validated. However as thorough of a 549 validation as possible should be conducted in an effort to detect 550 possible attacks. 552 User-Name: This value should be checked for consistency with the 553 database and any method-specific user information. If EAP method 554 identity protection is employed, this value typically contains a 555 pseudonym or keyword. 557 NAS-IP-Address: This value is typically the IP address of the 558 authenticator, but in a proxied connection it likely will not 559 match the source IP address of an Access-Request. A consistency 560 check MAY verify the subnet of the IP address was correct based on 561 the last-hop proxy. 563 Called-Station-Id: This is typically the MAC address of the NAS. On 564 an enterprise network, it MAY be validated against the MAC address 565 is one that has been provisioned on the network. 567 Calling-Station-Id: This is typically the MAC address of the EAP 568 Client, and verification of this is likely difficult, unless EAP 569 credentials have been provisioned on a per-host basis to specific 570 L2 addresses. It SHOULD be validated against the database in an 571 enterprise deployment. 573 NAS-Identifier: This is an identifier populated by the NAS, and 574 could be related to the MAC address, and should be validated 575 similarly to the Called-Station-Id. 577 NAS-Port-Type: This specifies the underlying link technology. It 578 SHOULD be validated against the value received from the client in 579 the information exchange, and against a database of authorized 580 link-layer technologies. 582 9. Security Considerations 584 9.1. Trust Model 586 We consider a trust model in which the peer and server trust each 587 other. This is not unreasonable, considering they already have a 588 trust relationship. In this trust model, client and authentication 589 server are honest while the authenticator is maliciously sending 590 false information to client and/or server. The following are the 591 trust relationships: 593 o The server trusts that the channel binding information received 594 from the client is the information that the client received from 595 the authenticator. 596 o The client trusts the channel binding result received from the 597 server. 598 o The server trusts the information contained within its local 599 database. 601 In order to establish the first two trust relationships during an EAP 602 execution, an EAP method MUST provide the following: 604 o mutual authentication between client and server 605 o derivation of keying material including a key for integrity 606 protection of channel binding messages 607 o sending i1 from client to server over an integrity-protected 608 channel 610 o sending the result and optionally i2 from server to client over an 611 integrity-protected channel 613 9.2. Consequences of Trust Violation 615 If any of the trust relationships listed in Section 7.1 are violated, 616 channel binding cannot be provided. In other words, if mutual 617 authentication with key establishment as part of the EAP method as 618 well as protected database access are not provided, then achieving 619 channel binding is not feasible. 621 Dishonest peers can only manipulate the first message i1 of the 622 channel binding protocol. In this scenario, a peer sends i1' to the 623 server. If i1' is invalid, the channel binding validation will fail 624 and the server will abort the EAP authentication. On the other hand 625 if i1' passes the validation, either the original i1 was wrong and 626 i1' corrected the problem or both i1 and i1' constitute valid 627 information. All cases do not seem to be of any benefit to a peer 628 and do no pose a security risk. 630 Dishonest servers can send EAP-Failure messages and abort the EAP 631 authentication even if the received i1 is valid. However, servers 632 can always abort any EAP session independent of whether channel 633 binding is offered or not. On the other hand, dishonest servers can 634 claim a successful validation even for an invalid i1. This can be 635 seen as collaboration of authenticator and server. Channel binding 636 can neither prevent nor detect such attacks. In general such attacks 637 cannot be prevented by cryptographic means and should be addressed 638 using policies making servers liable for their provided information 639 and services. 641 Additional network entities (such as proxies) might be on the 642 communication path between peer and server and may attempt to 643 manipulate the channel binding protocol. If these entities do not 644 possess the keying material used for integrity protection of the 645 channel binding messages, the same threat analysis applies as for the 646 dishonest authenticators. Hence, such entities can neither 647 manipulate single channel binding messages nor the outcome. On the 648 other hand, entities with access to the keying material must be 649 treated like a server in a threat analysis. Hence such entities are 650 able to manipulate the channel binding protocol without being 651 detected. However, the required knowledge of keying material is 652 unlikely since channel binding is executed before the EAP method is 653 completed, and thus before keying material is typically transported 654 to other entities. 656 9.3. Privacy Violations 658 While the channel binding information exchanged between EAP peer and 659 EAP server (i.e. i1 and the optional result message) must always be 660 integrity-protected it may not be encrypted. In the case that these 661 messages contain identifiers of peer and/or network entities, the 662 privacy property of the executed EAP method may be violated. Hence, 663 in order to maintain the privacy of an EAP method, the exchanged 664 channel binding information must be encrypted. 666 10. Operations and Management Considerations 668 This section analyzes the impact of channel bindings on existing 669 deployments of EAP. 671 10.1. System Impact 673 As with any extension to existing protocols, there will be an impact 674 on existing systems. Typically the goal is to develop an extension 675 that minimizes the impact on both development and deployment of the 676 new system, subject to the system requirements. In this section we 677 discuss the impact on existing devices that currently utilize EAP, 678 assuming the channel binding information is transported within the 679 EAP method execution. 681 The EAP peer will need an API between the EAP lower layer and the EAP 682 method that exposes the necessary information from the NAS to be 683 validated to the EAP peer, which can then feed that information into 684 the EAP methods for transport. For example, an IEEE 802.11 system 685 would need to make available the various information elements that 686 require validation to the EAP peer which would properly format them 687 and pass them to the EAP method. Additionally, the EAP peer will 688 require updated EAP methods that support transporting channel binding 689 information. While most method documents are written modularly to 690 allow incorporating arbitrary protected information, implementations 691 of those methods would need to be revised to support these 692 extensions. Driver updates are also required so methods can access 693 the required information. 695 No changes to the pass-through authenticator would be required. 697 The EAP server would need an API between the database storing NAS 698 information and the individual EAP server. The EAP methods need to 699 be able to export received channel binding information to the EAP 700 server so it can be validated. 702 Additionally, an interface is necessary for populating the EAP server 703 database with the appropriate parameters. In the enterprise case, 704 when a NAS is provisioned, information about what it should be 705 advertising to peers needs to be entered into the database. In the 706 service provider case, there should be a mechanism for entering 707 contractual information about roaming partners. 709 To ease operator burden it is highly recommended that there be a 710 mechanism for automatically populating the EAP server policy 711 database. Channel bindings could be enabled to allow peers to 712 transmit the NAS information to the EAP server, but the policy could 713 be configured to allow all connections. The obtained information 714 could be used to auto-generate policy information for the database, 715 assuming there are no adversarial elements in the network during the 716 auto-population phase. 718 Channel binding validation can also be implemented incrementally. An 719 initial database may be empty, and all channel bindings are 720 automatically approved. Operators can then incrementally add 721 parameters to the database regarding specific authenticators or 722 groups of authenticators that must be validated. Additionally, a 723 network could also self-form this database by putting the network 724 into a "learning" mode, and could then recognize inconsistencies in 725 the future. 727 10.2. Cost-Benefit Analysis 729 [TBD] 731 11. IANA Considerations 733 This document contains no IANA considerations. 735 12. References 737 12.1. Normative References 739 [I-D.aboba-radext-wlan] 740 Aboba, B., Malinen, J., Congdon, P., and J. Salowey, 741 "RADIUS Attributes for IEEE 802 Networks", 742 draft-aboba-radext-wlan-09 (work in progress), 743 October 2008. 745 [I-D.ietf-dime-rfc3588bis] 746 Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 747 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-13 748 (work in progress), November 2008. 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, March 1997. 753 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 754 Levkowetz, "Extensible Authentication Protocol (EAP)", 755 RFC 3748, June 2004. 757 12.2. Informative References 759 [I-D.clancy-emu-aaapay] 760 Clancy, T., "EAP Method Support for Transporting AAA 761 Payloads", Internet Draft draft-clancy-emu-aaapay-01, 762 July 2008. 764 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 765 Loughney, "Diameter Credit-Control Application", RFC 4006, 766 August 2005. 768 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 769 Authentication Protocol (EAP) Method Requirements for 770 Wireless LANs", RFC 4017, March 2005. 772 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 773 Channels", RFC 5056, November 2007. 775 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 776 Authentication Protocol (EAP) Key Management Framework", 777 RFC 5247, August 2008. 779 [HC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", 780 ICST QShine, August 2007. 782 Appendix A. Attacks Prevented by Channel Bindings 784 In the following it is demonstrated how the presented channel 785 bindings can prevent attacks by malicious authenticators 786 (representing the lying NAS problem) as well as malicious visited 787 networks (representing the lying provider problem). 789 A.1. Enterprise Subnetwork Masquerading 791 As outlined in Section 3, an enterprise network may have multiple 792 VLANs providing different levels of security. In an attack, a 793 malicious NAS connecting to a guest network with lesser security 794 protection could broadcast the SSID of a subnetwork with higher 795 protection. This could lead clients to believe that they are 796 accessing the network over secure connections, and, e.g., transmit 797 confidential information that they normally would not send over a 798 weakly protected connection. This attack works under the conditions 799 that clients use the same set of credentials to authenticate to the 800 different kinds of VLANs and that the VLANs support at least one 801 common EAP method. If these conditions are not met, the EAP server 802 would not authorize the clients to connect to the guest network, 803 because the clients used credentials and/or an EAP method that is 804 associated with the corporate network. 806 A.2. Forced Roaming 808 Mobile phone providers boosting their cell tower's transmission power 809 to get more users to use their networks have occurred in the past. 810 The increased transmission range combined with a NAS sending a false 811 network identity lures users to connect to the network without being 812 aware of that they are roaming. 814 Channel bindings would detect the bogus network identifier because 815 the network identifier send to the authentication server in i1 will 816 neither match information i2 nor the stored data. The verification 817 fails because the info in i1 claims to come from the peer's home 818 network while the home authentication server knows that the 819 connection is through a visited network outside the home domain. In 820 the same context, channel bindings can be utilized to provide a "home 821 zone" feature that notifies users every time they are about to 822 connect to a NAS outside their home domain. 824 A.3. Downgrading attacks 826 A malicious authenticator could modify the set of offered EAP methods 827 in its Beacon to force the peer to choose from only the weakest EAP 828 method(s) accepted by the authentication server. For instance, 829 instead of having a choice between EAP-MD5-CHAP, EAP-FAST and some 830 other methods, the authenticator reduces the choice for the peer to 831 the weaker EAP-MD5-CHAP method. Assuming that weak EAP methods are 832 supported by the authentication server, such a downgrading attack can 833 enable the authenticator to attack the integrity and confidentiality 834 of the remaining EAP execution and/or break the authentication and 835 key exchange. The presented channel bindings prevent such 836 downgrading attacks, because peers submit the offered EAP method 837 selection that they have received in the beacon as part of i1 to the 838 authentication server. As a result, the authentication server 839 recognizes the modification when comparing the information to the 840 respective information in its policy database. 842 A.4. Bogus Beacons in IEEE 802.11r 844 In IEEE 802.11r, the SSID is bound to the TSK calculations, so that 845 the TSK needs to be consistent with the SSID advertised in an 846 authenticator's Beacon. While this prevents outsiders from spoofing 847 a Beacon it does not stop a "lying NAS" from sending a bogus Beacon 848 and calculating the TSK accordingly. 850 By implementing channel bindings, as described in this draft, in IEEE 851 802.11r, the verification by the authentication server would detect 852 the inconsistencies between the information the authenticator has 853 sent to the peer and the information the server received from the 854 authenticator and stores in the policy database. 856 A.5. Forcing false authorization in IEEE 802.11i 858 In IEEE 802.11i a malicious NAS can modify the beacon to make the 859 client believe it is connected to a network different from the on the 860 client is actually connected to. 862 In addition, a malicious NAS can force an authentication server into 863 authorizing access by sending an incorrect Called-Station-ID that 864 belongs to an authorized NAS in the network. This could cause the 865 authentication server to believe it had granted access to a different 866 network or even provider than the one the client got access to. 868 Both attacks can be prevented by implementing channel bindings, 869 because the server can compare the information that was sent to the 870 client, with information it received from the authenticator during 871 the AAA communication as well as the information stored in the policy 872 database. 874 Authors' Addresses 876 T. Charles Clancy 877 Laboratory for Telecommunications Sciences 878 US Department of Defense 879 College Park, MD 880 USA 882 Email: clancy@ltsnet.net 883 Katrin Hoeper 884 National Institute of Standards and Technology 885 100 Bureau Drive, mail stop 8930 886 Gaithersburg, MD 20878 887 USA 889 Email: khoeper@nist.gov 891 Full Copyright Statement 893 Copyright (C) The IETF Trust (2008). 895 This document is subject to the rights, licenses and restrictions 896 contained in BCP 78, and except as set forth therein, the authors 897 retain all their rights. 899 This document and the information contained herein are provided on an 900 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 901 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 902 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 903 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 904 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 905 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 907 Intellectual Property 909 The IETF takes no position regarding the validity or scope of any 910 Intellectual Property Rights or other rights that might be claimed to 911 pertain to the implementation or use of the technology described in 912 this document or the extent to which any license under such rights 913 might or might not be available; nor does it represent that it has 914 made any independent effort to identify any such rights. Information 915 on the procedures with respect to rights in RFC documents can be 916 found in BCP 78 and BCP 79. 918 Copies of IPR disclosures made to the IETF Secretariat and any 919 assurances of licenses to be made available, or the result of an 920 attempt made to obtain a general license or permission for the use of 921 such proprietary rights by implementers or users of this 922 specification can be obtained from the IETF on-line IPR repository at 923 http://www.ietf.org/ipr. 925 The IETF invites any interested party to bring to its attention any 926 copyrights, patents or patent applications, or other proprietary 927 rights that may cover technology that may be required to implement 928 this standard. Please address the information to the IETF at 929 ietf-ipr@ietf.org.