idnits 2.17.1 draft-ietf-emu-crypto-bind-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2013) is 3943 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-emu-eap-tunnel-method-06 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman 3 Internet-Draft M. Wasserman 4 Intended status: Informational Painless Security 5 Expires: January 11, 2014 D. Zhang 6 Huawei 7 July 10, 2013 9 EAP Mutual Cryptographic Binding 10 draft-ietf-emu-crypto-bind-04.txt 12 Abstract 14 As the Extensible Authentication Protocol (EAP) evolves, EAP peers 15 rely increasingly on information received from the EAP server. EAP 16 extensions such as channel binding or network posture information are 17 often carried in tunnel methods; peers are likely to rely on this 18 information. RFC 3748 is a facility that protects tunnel methods 19 against man-in-the-middle attacks. However, cryptographic binding 20 focuses on protecting the server rather than the peer. This memo 21 explores attacks possible when the peer is not protected from man-in- 22 the-middle attacks and recommends mutual cryptographic binding, a new 23 form of cryptographic binding that protects both peer and server 24 along with other mitigations. 26 Keywords for Requirement Levels 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 11, 2014. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. An Example Problem . . . . . . . . . . . . . . . . . . . . . . 6 68 3. The Server insertion Attack . . . . . . . . . . . . . . . . . 8 69 3.1. Conditions for the Attack . . . . . . . . . . . . . . . . 8 70 3.2. Mitigation Strategies . . . . . . . . . . . . . . . . . . 9 71 3.2.1. Server Authentication . . . . . . . . . . . . . . . . 9 72 3.2.2. Server Policy . . . . . . . . . . . . . . . . . . . . 10 73 3.2.3. Existing Cryptographic Binding . . . . . . . . . . . . 13 74 3.2.4. Introducing EMSK-based Cryptographic Binding . . . . . 14 75 3.2.5. Mix Key into Long-Term Credentials . . . . . . . . . . 15 76 3.3. Intended Intermediates . . . . . . . . . . . . . . . . . . 15 77 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17 78 4.1. Mutual Cryptographic Binding . . . . . . . . . . . . . . . 17 79 4.2. State Tracking . . . . . . . . . . . . . . . . . . . . . . 17 80 4.3. Certificate Naming . . . . . . . . . . . . . . . . . . . . 18 81 4.4. Inner Mixing . . . . . . . . . . . . . . . . . . . . . . . 18 82 5. Survey of Tunnel Methods . . . . . . . . . . . . . . . . . . . 19 83 5.1. Tunneled Eap Method (TEAP) . . . . . . . . . . . . . . . . 19 84 5.2. Flexible Authentication through Secure Tunneling (FAST) . 19 85 5.3. Tunneled Transport Layer Security (EAP-TTLS) . . . . . . . 19 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 93 1. Introduction 95 The Extensible Authentication Protocol (EAP) [RFC3748] provides 96 authentication between a peer (a party accessing some service) and a 97 authentication server. Traditionally, peers have not relied 98 significantly on information received from EAP servers. However 99 facilities such as EAP Channel Binding [I-D.ietf-emu-chbind] provide 100 the peer with confirmation of information about the resource it is 101 accessing. Other facilities such as EAP Posture Transport 102 [I-D.ietf-nea-pt-eap] permit a peer and EAP server to discuss the 103 security properties of accessed networks. Both of these facilities 104 provide peers with information they need to rely on and provide 105 attackers who are able to impersonate an EAP server to a peer with 106 new opportunities for attack. 108 Instead of adding these new facilities to all EAP methods, work has 109 focused on adding support to tunnel methods 110 [I-D.ietf-emu-eaptunnel-req]. There are numerous tunnel methods 111 including [RFC4851], [RFC5281], and work on building a standards 112 track tunnel method [I-D.ietf-emu-eap-tunnel-method]. These tunnel 113 methods are extensible. By adding an extension to support a facility 114 such as channel binding to a tunnel method, it can be used with any 115 inner method carried in the tunnel. 117 Tunnel methods need to be careful about man-in-the-middle attacks. 118 See section 3.2 and 4.6.3 in [I-D.ietf-emu-eaptunnel-req] and 119 [TUNNEL-MITM] for a detailed description of these attacks. An 120 example of the attack can happen when a peer is willing to perform 121 authentication inside and outside a tunnel. An attacker can 122 impersonate the EAP server and offer the inner method to the peer. 123 However, on the other side, the attacker acts as a man-in-the-middle 124 and opens a tunnel to the real EAP server. Figure 1 illustrates this 125 attack. At the end of the attack, the EAP server believes it is 126 talking to the peer. At the inner method level, this is true. At 127 the outer method level, however, the server is talking to the 128 attacker. 130 Peer Attacker Service AAA Server 131 | | | | 132 | | | | 133 |Peer Initiates connection to a Service | | 134 |---------------------+-------X-------->| | 135 | (Intercepted by an attacker) | | 136 | | | | 137 | | Tunnel Establishment | 138 | |<-------------------------------->| 139 | | | | 140 | |..................................| 141 | | Tunnel | 142 | Non-Tunneled | | | 143 | method | Tunneled authentication method | 144 |<===================>|<================================>| 145 | | | | 146 | |..................................| 147 | | | | 148 | | Attacker |<--- MSK keys --| 149 | | Connected as | | 150 | | Peer | | 151 | |<--------------->| | 153 A classic tunnel attack where the attacker inserts an extra tunnel 154 between the attacker and EAP server. 156 Figure 1: Classic Tunnel Attack 158 There are two mitigation strategies for this classic attack. First, 159 security policy can be set up so that the same method is not offered 160 by a server both inside and outside a tunnel. Secondly, a technical 161 solution is available if the inner method is sufficiently strong: 162 cryptographic binding is a security property of a tunnel method under 163 which the EAP server confirms that the inner and outer parties are 164 the same. Cryptographic binding is typically implemented by 165 requiring the outer party (the other end of the tunnel) to prove 166 knowledge of the Master Session Key (MSK) of the inner method. This 167 proves to the server that the inner and outer exchanges are with the 168 same party. RFC 3748's definition of cryptographic binding allows 169 for an optional proof to the peer that the inner and outer exchanges 170 are with the same party. As discussed below, proving knowledge of 171 the MSK is insufficient to prove to the peer that the inner and outer 172 exchanges are with the same party. 174 2. An Example Problem 176 The GSS-EAP mechanism [I-D.ietf-abfab-gss-eap] provides application 177 authentication using EAP. A peer could reasonably trust some 178 applications significantly more than others. If the peer sends 179 confidential information to some applications, an attacker may gain 180 significant value from convincing the peer that the attacker is the 181 trusted application. Channel bindings are used to provide 182 information to the peer about the application service to which the 183 peer connects. Prior to channel bindings, peers could not 184 distinguish one Network Access Service (NAS) from another, so attacks 185 where one NAS impersonated another were out-of-scope. However 186 channel bindings add this capability and thus expands the threat 187 model of EAP. The GSS-EAP mechanism requires distinguishing one 188 service from another. 190 Consider the following example. A relatively untrusted service, say 191 a print server, has been compromised. A user is attempting to 192 connect to a trusted service such as a financial application. Both 193 the print server and the financial application use an Authentication, 194 Authorization and Accounting protocol (AAA) to transport EAP 195 authentication back to the user's EAP server. The print server 196 mounts a man-in-the-middle attack on the user's connection to the 197 financial application and claims to be the application. 199 The print server offers a tunnel method towards the peer. The print 200 server extracts the inner method from the tunnel and sends it on 201 towards the AAA server. Channel binding happens at the tunnel method 202 though. So, the print server is happy to confirm that it is the 203 financial application. After the inner method completes, the EAP 204 server sends the MSK to the print server over the AAA protocol. If 205 only the MSK is needed for cryptographic binding then the print 206 server can successfully perform cryptographic binding and may be able 207 to impersonate the financial application to the peer. 209 Peer Attacker Service AAA Server 210 | | | | 211 | | | | 212 |Peer Initiates connection to a Service | | 213 |---------------------+----X----------->| | 214 | (Intercepted by an attacker) | | 215 | | | | 216 | | | | 217 | Tunnel Establishment| | | 218 |<------------------->| | | 219 |.....................| | | 220 | Tunnel | | | 221 | | | 222 | Tunneled | Non-Tunneled | 223 | Method | Authentication Method | 224 |<===================>|<================================>| 225 | |(Same as Inner Method from Tunnel)| 226 |.....................| | | 227 | | | | 228 | Peer | | | 229 | Connected to |<----------------------MSK keys --| 230 | Attacker | | | 231 |<------------------->| | | 232 | | | | 234 A modified tunnel attack when an extra server rather than extra 235 client is inserted. 237 Figure 2: Channel Binding Requires More than Crypto Binding 239 This attack is not specific to GSS-EAP. The channel bindings 240 specification [I-D.ietf-emu-chbind] describes a number of situations 241 where channel bindings are important for network access. In these 242 situations one NAS could impersonate another by using a similar 243 attack. 245 3. The Server insertion Attack 247 The previous section described an example of the server insertion 248 attack. In this attack, one party adds a layer of tunneling such 249 that from the perspective of the EAP peer, there are more methods 250 than from the perspective of the EAP server. This attack is most 251 beneficial when the party inserting the extra tunnel is a legitimate 252 NAS, so mitigations need to be able to prevent a legitimate NAS from 253 inappropriately adding a layer of tunneling. Some deployments 254 utilize an intentional intermediary that adds an extra level of EAP 255 tunneling between the peer and the EAP server; see Section 3.3 for a 256 discussion. 258 3.1. Conditions for the Attack 260 For an inserted server attack to have value, the attacker needs to 261 gain an advantage from its attack. An advantage to the attacker 262 could come from: 264 o The attacker can send information to a peer that the peer would 265 trust from the EAP server but not the attacker. Examples of this 266 include channel binding responses. 268 o The peer sending information to the attacker that was intended for 269 the EAP server. For example, the inner user identity may disclose 270 privacy-sensitive information. The channel binding request may 271 disclose what service the peer wishes to connect to. 273 o The attacker may influence session parameters. For example, if 274 the attacker can influence the MSK, then the attacker may be able 275 to read or influence session traffic and mount an attack on the 276 confidentiality or integrity of the resulting session. 278 o An attacker may impact availability of the session. In practice 279 though, an attacker that can mount a server insertion attack is 280 likely to be able to impact availability in other ways. 282 For this attack to be possible, the following conditions need to 283 hold: 285 1. The attacker needs to be able to establish a tunnel method with 286 the peer over which the peer will authenticate. 288 2. The attacker needs to be able to respond to any inner 289 authentication. For example an attacker who is a legitimate NAS 290 can forward the inner authentication over AAA towards the EAP 291 server. Note that the inner authentication may not be EAP. 293 3. Typically, the attacker needs to be able to complete the tunnel 294 method after inner authentication. This may not be necessary if 295 the attacker is gaining advantage from information sent by the 296 peer over the tunnel. 298 4. In some cases the attacker may need to complete a Secure 299 Association Protocol (SAP) or otherwise demonstrate knowledge of 300 the MSK after the tunnel method successfully completes. 302 Attackers who are legitimate NASes are the primary focus of this 303 memo. Previous work has provided mitigation against attackers who 304 are not a NAS; these mitigations are briefly discussed. 306 3.2. Mitigation Strategies 308 3.2.1. Server Authentication 310 If the peer confirms the identity of the party that the tunnel method 311 is established with, the peer prevents the first condition (attacker 312 establishing a tunnel method). Many tunnel methods rely on TLS 313 [RFC5281] [I-D.ietf-emu-eap-tunnel-method]. The specifications for 314 these methods tend to encourage or mandate certificate checking. If 315 the TLS certificate is validated back to a trust anchor and the 316 identity of the tunnel method server confirmed, then the first attack 317 condition cannot be met. 319 Many challenges make server authentication difficult. There is not 320 an obvious name by which to identify a tunnel method server. It is 321 not obvious where in the tunnel server certificate the name should be 322 found. One particularly problematic practice is to use a certificate 323 that names the host on which the tunnel server runs. Given such a 324 name it is very difficult for a peer to understand whether that 325 server is intended to be a tunnel method server for the realm. 327 It's not clear what trust anchors to use for tunnel servers. Using 328 commercial Certificate Authorities (CAs) is probably undesirable 329 because tunnel servers often operate in a closed community and are 330 often provisioned with certificates issued by that community. Using 331 commercial CAs can be particularly problematic with peers that 332 support hostnames in certificates. Then anyone who can obtain a 333 certificate for any host in the domain being contacted can 334 impersonate a tunnel server. 336 These difficulties lead to poor deployment of good certificate 337 validation. Many peers make it easy to disable certificate 338 validation. Other peers validate back to trust anchors but do not 339 check names of certificates. What name types are supported and what 340 configuration is easy to perform depends significantly on the peer in 341 question. 343 Specifications also make the problem worse. For example [RFC5281] 344 indicates that the only impact of failing to perform certificate 345 validation is that the inner method can be attacked. Administrators 346 and implementors believing this claim may believe that protection 347 from passive attacks is sufficient. 349 In addition, some deployments such as provisioning or strong inner 350 methods are designed to work without certificate validation. Section 351 3.9 of the tunnel requirements [I-D.ietf-emu-eaptunnel-req] discusses 352 this requirement. 354 3.2.2. Server Policy 356 Server policy can potentially prevent the second condition (attacker 357 being able to respond to inner authentication) from being possible. 358 If the server only performs a particular inner authentication within 359 a tunnel, then the attacker cannot gain a response to the inner 360 authentication without their being such a tunnel. The attacker may 361 be able to add a second layer of tunnels; see Figure 3. The inner 362 tunnel may limit the attacker's capabilities; for example if channel 363 binding is performed over tunnel t2 in the figure, then an attacker 364 cannot observe or influence it. 366 Peer Attacker Service AAA Server 367 | | | | 368 | | | | 369 |Peer Initiates connection to a Service | | 370 |---------------------+----X----------->| | 371 | (Intercepted by an attacker) | | 372 | | | | 373 | | | | 374 | Tunnel Establishment| | | 375 |<------------------->| | | 376 |.....................| | | 377 | Tunnel t1 | | | 378 | | | | 379 |.......................................... .............| 380 | Tunnel t2 | 381 | | 382 | | 383 | Inner Method | 384 |<======================================================>| 385 | | 386 |.......................................... .............| 387 | | | | 388 |.....................| | | 389 | | | | 390 | Peer | | | 391 | Connected to |<----------------------MSK keys --| 392 | Attacker | | | 393 |<------------------->| | | 394 | | | | 396 A tunnel t1 from the peer to the attacker contains a tunnel t2 from 397 the peer to the home EAP server. Inside t2 is an inner 398 authentication. 400 Figure 3: Multiple Layered Tunnels 402 Peer policy can be combined with this server policy to help prevent 403 conditions 1 (attacker can establish a tunnel the peer will use) and 404 2 (attacker can respond to inner authentication). If the peer 405 requires exactly one tunnel of a particular type and the EAP server 406 only performs inner authentication over a tunnel of this type, then 407 the attacker cannot establish tunnel t1 in the figure above. 408 Configuring this peer policy may be more challenging than configuring 409 policy on the EAP server. 411 An attacker may be able to mount a more traditional man-in-the-middle 412 attack in this instance; see Figure 4. This policy on the peer and 413 EAP server combined with a tunnel method that supports cryptographic 414 binding will allow the EAP server to detect the attacker. This means 415 the attacker cannot act as a legitimate NAS and in particular does 416 not obtain the MSK. So, if the tunnel between the attacker and peer 417 also requires cryptographic binding and if the cryptographic binding 418 requires both the EAP server and peer to prove knowledge of the inner 419 MSK, then the authentication will fail. If cryptographic binding is 420 not performed, then this attack may succeed. 422 Peer Attacker Service AAA Server 423 | | | | 424 | | | | 425 |Peer Initiates connection to a Service | | 426 |---------------------+----X----------->| | 427 | (Intercepted by an attacker) | | 428 | | | | 429 | | | | 430 | Tunnel Establishment| Tunnel Establishment | 431 |<------------------->|<-------------------------------->| 432 |.....................|.................... .............| 433 | Tunnel 1 | Tunnel 2 | 434 | | | 435 | Tunneled | | 436 | Method | Tunneled Method | 437 |<===================>|<================================>| 438 | | | 439 |.....................|..................................| 440 | | | | 441 | Peer | | | 442 | Connected to | | | 443 | Attacker | | | 444 |<------------------->| | | 445 | | | | 447 A tunnel t1 extends from the peer to the attacker. A tunnel t2 448 extends from the attacker to the home EAP server. An inner EAP 449 authentication is forwarded unmodified by the attacker from t1 to t2. 450 The attacker can observe this inner authentication. 452 Figure 4: A Traditional Man-in-the-Middle Attack 454 Cryptographic binding is only a valuable component of a defense if 455 the inner authentication is a key-deriving EAP method. Most tunnel 456 methods also support non-EAP inner authentication such as Microsoft 457 Chap version 2 [RFC2759]. This may undermine cryptographic binding 458 in a number of ways. An attacker may be able to convert an EAP 459 method into a compatible non-EAP form of the same credential to 460 suppress cryptographic binding. In addition, an inner authentication 461 may be available through an entirely different means. For example, a 462 Lightweight Directory Access Protocol [RFC4510] or other directory 463 server may provide an attacker a way to get challenges and provide 464 responses for an authentication mechanism entirely outside of the 465 AAA/EAP context. An attacker with this capability may be able to get 466 around server policy requiring an inner authentication be used only 467 in a given type of tunnel. 469 To Recap, the following policy conditions appear sufficient to 470 prevent a server insertion attack: 472 1. Peer and EAP server require a particular inner EAP method used 473 within a particular tunnel method 475 2. The inner EAP method's authentication is only available within 476 the tunnel and through no other means including non-EAP means 478 3. The inner EAP method produces a key 480 4. The tunnel method uses cryptographic binding and the peer 481 requires the other end of the tunnel to prove knowledge of the 482 inner MSK. 484 3.2.3. Existing Cryptographic Binding 486 The most advanced examples of cryptographic binding today work at two 487 levels. First, the server and peer prove to each other knowledge of 488 the inner MSK. Then, the inner MSK is combined into some outer key 489 material to form the tunnel's keys. This is sufficient to detect an 490 inserted server or peer provided that the attacker does not learn the 491 inner MSK. This seems sufficient to defend against attackers who 492 cannot act as a legitimate NAS. 494 The definition of cryptographic binding in RFC 3748 does not require 495 these steps. To meet that definition it would be sufficient for a 496 peer to prove knowledge of the inner key to the EAP server. This 497 would open some additional attacks. For example by indicating 498 success an attacker might be able to mask a cryptographic binding 499 failure. Especially if only the tunnel key material is used for the 500 final keys, the peer is unlikely to be able to detect the failure. 502 As discussed in the previous section, cryptographic binding is only 503 effective when the inner method is EAP. 505 3.2.4. Introducing EMSK-based Cryptographic Binding 507 Cryptographic binding can be strengthened when the inner EAP method 508 supports an Extended Master Session Key (EMSK). The EMSK is never 509 disclosed to any party other than the EAP server or peer, so even a 510 legitimate NAS cannot learn the EMSK. So, if the same techniques 511 currently applied to the inner MSK are applied to the inner EMSK, 512 then condition 3 (completing tunnel authentication) will not hold 513 because the attacker cannot complete this new form of cryptographic 514 binding. This does not prevent the attacker from learning 515 confidential information such as a channel binding request sent over 516 the tunnel prior to cryptographic binding. 518 Obviously as with all forms of cryptographic binding, cryptographic 519 binding only works for key-deriving inner EAP methods. Also, some 520 deployments (see Section 3.3) insert intermediates between the peer 521 and the EAP server. EMSK-based cryptographic binding is incompatible 522 with these deployments because the intermediate cannot learn the 523 EMSK. 525 Formally, EMSK-based cryptographic binding is a security claim for 526 EAP tunnel methods that holds when: 528 1. The peer proves to the server that the peer participating in any 529 inner method is the same as the peer for the tunnel method. 531 2. The server proves to the peer that the server for any inner 532 method is the same as the server for the tunnel method. 534 3. The MSK and EMSK for the tunnel depend on the MSK and EMSK of 535 inner methods. 537 4. The peer MUST be able to force the authentication to fail if the 538 peer is unable to confirm the identity of the server. 540 5. Proofs offered need to be secure even against attackers who know 541 the inner method MSK. 543 If EMSK-based cryptographic binding is not an optional facility it 544 provides a strong defense against server insertion attacks and other 545 tunnel MITM attacks for inner methods that provide an EMSK. The 546 strength of the defense is dependent on the strength of the inner 547 method. EMSK-Based cryptographic binding MAY be provided as an 548 optional facility. The value of EMSK-based cryptographic binding is 549 reduced somewhat if it is an optional feature. It permits 550 configurations where a peer uses other means to authenticate the 551 server if the peer has sufficient information configured to validate 552 the certificate and identity of an EAP server while using EMSK-based 553 cryptographic binding for deployments where that is possible. 555 If EMSK-based cryptographic binding is an optional facility, the 556 negotiation of whether to use it MUST be protected by the inner MSK 557 or EMSK. Typically the MSK will be used as the primary advantage of 558 making EMSK-based cryptographic binding an optional facility is to 559 permit intermediates who know only the MSK to decline to use EMSK- 560 based cryptographic binding. The peer MUST have an opportunity to 561 fail the authentication after the server declines to use EMSK-based 562 cryptographic binding. 564 3.2.5. Mix Key into Long-Term Credentials 566 Another defense against tunnel MITM attacks potentially including 567 server insertion attacks is to use a different credential for 568 tunneled methods from other authentications. This may prevent the 569 second condition (attacker being able to respond to inner 570 authentication) from taking place. For example, if key material from 571 the tunnel is mixed into a shared secret or password that is the 572 basis of the inner authentication, then the second condition will not 573 hold unless the attacker already knows this shared secret. The 574 advantage of this approach is that it seems to be the only way to 575 strengthen non-EAP inner authentications within a tunnel. 577 There are several disadvantages. Choosing a function to mix the 578 tunnel key material into the inner authentication will be very 579 dependent on the inner authentication. In addition, this appears to 580 involve a layering violation. However, exploring the possibility of 581 providing a solution like this seems important because it can 582 function for inner authentications where no other approach will work. 584 3.3. Intended Intermediates 586 Some deployments introduce a tunnel server separate from the EAP 587 server; see [RFC5281] for an example of this style of deployment. 588 The tunnel server is between the NAS and the EAP server. The only 589 difference between such an intermediate and an attacker is that the 590 intermediate provides some function valuable to the peer or EAP 591 server and that the intermediate is trusted by the peer. If peers 592 are configured with the necessary information to validate 593 certificates of these intermediates and to confirm their identity, 594 then tunnel MITM and inserted server attacks can be defended against. 595 The intermediates need to be trusted with regard to channel binding 596 and other services that the peer depends on. 598 Support for trusted intermediates is not a requirement according to 599 the tunnel method requirements. 601 It seems reasonable to treat trusted intermediates as a special case 602 if they are supported and to focus on the security of the case where 603 there are not intermediates in the tunnel as the common case. 605 4. Recommendations 607 4.1. Mutual Cryptographic Binding 609 The EAP Tunnel Method [I-D.ietf-emu-eap-tunnel-method] should gain 610 support for EMSK-based cryptographic binding. 612 As channel binding support is added to existing EAP methods, EMSK- 613 based cryptographic binding or some other form of cryptographic 614 binding that protects against server insertion should also be added 615 to these methods. Mutual cryptographic binding may also be valuable 616 when other services are added to EAP methods that may require a peer 617 trust an EAP server. 619 4.2. State Tracking 621 Today, mutual authentication in EAP is thought of as a security claim 622 about a method. However, in practice it's an attribute of a 623 particular exchange. Mutual authentication can be obtained via 624 checking certificates, through mutual cryptographic binding, or in 625 very controlled cases through carefully crafted peer and server 626 policy combined with existing cryptographic binding. Using services 627 like channel binding that involve the peer trusting the EAP server 628 should require mutual authentication be present in the session. 630 to accomplish this, implementations including channel binding or 631 other peer services MUST track whether mutual authentication has 632 happened. They SHOULD default to not permitting these peer services 633 unless mutual authentication has happened. They SHOULD support a 634 configuration where the peer fails to authenticate unless mutual 635 authentication takes place. Discussion of whether this configuration 636 should be recommended as a default is required. 638 The EAP Tunnel Method should permit peers to force authentication 639 failure if they are unable to perform mutual authentication. The 640 protocol should permit this to be deferred until after mutual 641 cryptographic binding is considered. 643 Services such as channel binding should be deferred until after 644 cryptographic binding/mutual cryptographic binding. 646 An additional complication arises when a tunnel method authenticates 647 multiple parties such as authenticating both the peer machine and the 648 peer user to the EAP server. Depending on how mutual authentication 649 is achieved, only some of these parties may have confidence in it. 650 For example if a strong shared secret is used to mutually 651 authenticate the user and the EAP server, the machine may not have 652 confidence that the EAP server is the authenticated party if the 653 machine cannot trust the user not to disclose the shared secret to an 654 attacker. In these cases, the parties who have achieved mutual 655 authentication need to be considered when evaluating whether to use 656 peer services. 658 4.3. Certificate Naming 660 Work is required to promote interoperable deployment of server 661 certificate validation by peers. A standard way to name EAP servers 662 is required. Recommendations for what name forms peers should 663 implement is required. 665 4.4. Inner Mixing 667 More consideration of the proposal to mix some key material into 668 inner authentications is desired. As stated today, the proposal is 669 under-defined and fairly invasive. Are there versions of this 670 proposal that would be valuable? Is there a way to view it as 671 something more abstract so that it does not involve tunnel and inner 672 method specific combinatorial explosion? 674 5. Survey of Tunnel Methods 676 5.1. Tunneled Eap Method (TEAP) 678 The Tunneled EAP Method (TEAP) [I-D.ietf-emu-eap-tunnel-method] 679 provides several features designed to limit man-in-the-middle 680 vulnerabilities and provide a safe platform for peer services. 682 TEAP implementations support checking the Network Access Identifier 683 (NAI) realm portion against a DNS subjectAlternativeName in the 684 certificate of the TEAP server. TEAP supports EMSK-based 685 cryptographic binding as a way to achieve mutual cryptographic 686 binding. TEAP also supports MSK-based cryptographic binding for 687 cases where the EMSK is not available; this cryptographic binding 688 does not provide sufficient assurance for peer services. TEAP 689 provides recommendations on conditions that need to be met prior to 690 using peer services. These recommendations explicitly address when 691 the MSK-based cryptographic binding is sufficient and when EMSK-based 692 cryptographic binding is required. TEAP meets the recommendations 693 for implementations outlined in this memo. 695 5.2. Flexible Authentication through Secure Tunneling (FAST) 697 EAP-FAST [RFC4851] provides MSK-based cryptographic binding. EAp- 698 FAST requires that server certificates be validated. However, no 699 guidance is given on how servers are named, so the specification does 700 not provide enough guidance to interoperably enforce this 701 requirement. 703 EAP-FAST does not support channel binding or other peer services, 704 although the protocol is extensible and TLVs could be defined for 705 peer services. If the certificates are actually validated and names 706 checked, then EAP-FAST would provide security guarantees sufficient 707 to use these peer services. However, the cryptographic binding in 708 EAP-FAST is not strong enough to secure peer services if the server 709 certificate is not validated and name checked. 711 5.3. Tunneled Transport Layer Security (EAP-TTLS) 713 The Tunneled Transport Layer Security Version 0 (EAP-TTLS) [RFC5281] 714 does not support cryptographic binding. It also does not support 715 peer services such as channel binding although they could be added 716 using extensible AVPs. 718 EAP-TTLS recommends that implementations SHOULD validate certificates 719 but gives no guidance on how to handle naming. Even if certificates 720 are validated EAP-TTLS is not generally suited to peer services. As 721 an example, EAP-TTLS does not include protected result indication. 723 So, an unprotected EAP success packet can end the authentication. In 724 addition, it is difficult for a peer to request services such as 725 channel binding because the server ends the authentication as soon as 726 authentication is successful. 728 A variety of extensions including EAP-TTLS version 1 improve some of 729 these concerns. Specification and implementation issues complicate 730 analysis of these extensions. As an example, most implementations 731 can be tricked into using EAP-TTLS version 0. 733 6. Security Considerations 735 This memo examines the security considerations of providing new 736 classes of service within EAP methods. Traditionally, the primary 737 focus of EAP is authenticating the peer to the network. However, as 738 the peer places trust in the EAP server, mutual authentication 739 becomes more important. This memo examines the security of mutual 740 authentication for EAP tunnel methods. 742 7. Acknowledgements 744 The authors would like to thank Alan DeKok for helping to explore 745 these attacks. Alan focused the discussion on the importance of 746 inner authentications that are not EAP and proposed mixing in key 747 material as a way to resolve these authentications. 749 Jari Arkko provided a review of the attack and valuable context on 750 past efforts in developing cryptographic binding. 752 Sam Hartman's and Margaret Wasserman's work on this memo is funded by 753 Huawei. 755 8. References 757 8.1. Normative References 759 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 760 Requirement Levels", BCP 14, RFC 2119, March 1997. 762 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 763 Levkowetz, "Extensible Authentication Protocol (EAP)", 764 RFC 3748, June 2004. 766 8.2. Informative References 768 [I-D.ietf-abfab-gss-eap] 769 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 770 Extensible Authentication Protocol", 771 draft-ietf-abfab-gss-eap-09 (work in progress), 772 August 2012. 774 [I-D.ietf-emu-chbind] 775 Hartman, S., Clancy, T., and K. Hoeper, "Channel Binding 776 Support for EAP Methods", draft-ietf-emu-chbind-16 (work 777 in progress), May 2012. 779 [I-D.ietf-emu-eap-tunnel-method] 780 Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 781 "Tunnel EAP Method (TEAP) Version 1", 782 draft-ietf-emu-eap-tunnel-method-06 (work in progress), 783 March 2013. 785 [I-D.ietf-emu-eaptunnel-req] 786 Zhou, H., Salowey, J., Hoeper, K., and S. Hanna, 787 "Requirements for a Tunnel Based EAP Method", 788 draft-ietf-emu-eaptunnel-req-09 (work in progress), 789 December 2010. 791 [I-D.ietf-nea-pt-eap] 792 Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 793 (PT) Protocol For EAP Tunnel Methods", 794 draft-ietf-nea-pt-eap-09 (work in progress), March 2013. 796 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 797 RFC 2759, January 2000. 799 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 800 (LDAP): Technical Specification Road Map", RFC 4510, 801 June 2006. 803 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 804 Flexible Authentication via Secure Tunneling Extensible 805 Authentication Protocol Method (EAP-FAST)", RFC 4851, 806 May 2007. 808 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 809 Protocol Tunneled Transport Layer Security Authenticated 810 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 812 [TUNNEL-MITM] 813 Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-middle 814 and Tunneled Authentication Methods", Cryptology Eprint 815 Archive Report 2002/163, November 2002. 817 Authors' Addresses 819 Sam Hartman 820 Painless Security 822 Email: hartmans-ietf@mit.edu 824 Margaret Wasserman 825 Painless Security 827 Email: mrw@painless-security.com 828 URI: http://www.painless-security.com/ 830 Dacheng Zhang 831 Huawei 833 Email: zhangdacheng@huawei.com