idnits 2.17.1 draft-hartman-emu-mutual-crypto-bind-00.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 ([RFC3748]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 486: '...e is intended) but MUST NOT prevent an...' RFC 2119 keyword, line 488: '...raphic binding. Peers MUST be able to...' RFC 2119 keyword, line 569: '...er peer services MUST track whether mu...' RFC 2119 keyword, line 570: '... happened. They SHOULD default to not...' RFC 2119 keyword, line 571: '...n has happened. They SHOULD support a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2012) is 4434 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 3748' is mentioned on line 18, but not defined ** Obsolete normative reference: RFC 3778 (Obsoleted by RFC 8118) == Outdated reference: A later version (-09) exists of draft-ietf-abfab-gss-eap-04 == Outdated reference: A later version (-16) exists of draft-ietf-emu-chbind-13 == Outdated reference: A later version (-10) exists of draft-ietf-emu-eap-tunnel-method-01 == Outdated reference: A later version (-09) exists of draft-ietf-nea-pt-eap-00 Summary: 4 errors (**), 0 flaws (~~), 6 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: September 6, 2012 D. Zhang 6 Huawei 7 March 5, 2012 9 EAP Mutual Cryptographic Binding 10 draft-hartman-emu-mutual-crypto-bind-00.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. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 6, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. An Example Problem . . . . . . . . . . . . . . . . . . . . . . 6 61 3. The Server insertion Attack . . . . . . . . . . . . . . . . . 8 62 3.1. Conditions for the Attack . . . . . . . . . . . . . . . . 8 63 3.2. Mitigation Strategies . . . . . . . . . . . . . . . . . . 9 64 3.2.1. Server Authentication . . . . . . . . . . . . . . . . 9 65 3.2.2. Server Policy . . . . . . . . . . . . . . . . . . . . 10 66 3.2.3. Existing Cryptographic Binding . . . . . . . . . . . . 12 67 3.2.4. Introducing Mutual Cryptographic Binding . . . . . . . 12 68 3.2.5. Mix Key into Long-Term Credentials . . . . . . . . . . 13 69 3.3. Intended Intermediates . . . . . . . . . . . . . . . . . . 14 70 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.1. Mutual Cryptographic Binding . . . . . . . . . . . . . . . 15 72 4.2. State Tracking . . . . . . . . . . . . . . . . . . . . . . 15 73 4.3. Certificate Naming . . . . . . . . . . . . . . . . . . . . 15 74 4.4. Inner Mixing . . . . . . . . . . . . . . . . . . . . . . . 16 75 5. Survey of Tunnel Methods . . . . . . . . . . . . . . . . . . . 17 76 6. Survey of Inner Methods . . . . . . . . . . . . . . . . . . . 18 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 84 1. Introduction 86 The Extensible Authentication Protocol [RFC3778] provides 87 authentication between a peer (a party accessing some service) and a 88 authentication server. Traditionally, peers have not relied 89 significantly on information received from EAP servers. However 90 facilities such as EAP Channel Binding [I-D.ietf-emu-chbind] provide 91 the peer with confirmation of information about the resource it is 92 accessing. Other facilities such as EAP Posture Transport 93 [I-D.ietf-nea-pt-eap] permit a peer and EAP server to discuss the 94 security properties of accessed networks. Both of these facilities 95 provide peers with information they need to rely on and provide 96 attackers who are able to impersonate an EAP server to a peer with 97 new opportunities for attack. 99 Instead of adding these new facilities to all EAP methods, work has 100 focused on adding support to tunnel methods 101 [I-D.ietf-emu-eaptunnel-req]. There are numerous tunnel methods 102 including [RFC4851], [RFC5281], and work on building a standards 103 track tunnel method [I-D.ietf-emu-eap-tunnel-method]. These tunnel 104 methods are extensible. By adding an extension to support a facility 105 such as channel binding to a tunnel method, it can be used with any 106 inner method carried in the tunnel. 108 Tunnel methods need to be careful about man-in-the-middle attacks. 109 See section 3.2 and 4.6.3 in [I-D.ietf-emu-eaptunnel-req] and 110 [TUNNEL-MITM] for a detailed description of these attacks. An 111 example of the attack can happen when a peer is willing to perform 112 authentication inside and outside a tunnel. An attacker can 113 impersonate the EAP server and offer the inner method to the peer. 114 However, on the other side, the attacker acts as a man-in-the-middle 115 and opens a tunnel to the real EAP server. Figure 1 illustrates this 116 attack. At the end of the attack, the EAP server believes it is 117 talking to the peer. At the inner method level, this is true. At 118 the outer method level, however, the server is talking to the 119 attacker. 121 Please view in a fixed-width font such as Courier. 123 Client Attacker Server Auth Server 124 | | | | 125 | | | | 126 | | Tunnel establishment | 127 | | Server Authentication | 128 | |<================================>| 129 | | | | 130 | (Non-Authenticated | (Authenticated 131 | end of tunnel) | end of tunnel) 132 | | | | 133 | +--------------+ | +--------------+ 134 | | Tunnel | | | Tunnel | 135 | | Keys Derived | | | Keys Derived | 136 | +--------------+ | +--------------+ 137 | |..................................| 138 | | Tunnel | 139 | | | | 140 | | (Encrypted using Tunnel keys) | 141 | Inner | | | 142 | authentication | | | 143 | method | Tunneled authentication method | 144 |<===================>|<================================>| 145 | | | | 146 | |..................................| 147 | | | | 148 | | |<==tunnel keys==| 149 | | Client's session| | 150 | | stolen | | 151 | |<===============>| | 153 A classic tunnel attack where the attacker inserts an extra tunnel 154 between the attacker and EAP server. 156 Classic Tunnel Attack 158 There are several mitigation strategies for this classic attack. 159 First, security policy can be set up so that the same method is not 160 offered by a server both inside and outside a tunnel. 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. One common way to do this is to ask the outer party (the 165 other end of the tunnel) to prove knowledge of the Master Session Key 166 (MSK) of the inner method. As defined in RFC 3748, cryptographic 167 binding may prove to the peer that the inner and outer exchanges are 168 with the same party, but it typically does not make this proof; 169 instead it is typically limited to proving to the server that the 170 inner and outer peer are the same. 172 2. An Example Problem 174 The GSS-EAP mechanism [I-D.ietf-abfab-gss-eap] provides application 175 authentication using EAP. A peer could reasonably trust some 176 applications significantly more than others. If the peer sends 177 confidential information to some applications, an attacker may gain 178 significant value from convincing the peer that the attacker is the 179 trusted application. Channel bindings are used to tell the peer 180 which application service is being connected to. Prior to channel 181 bindings, peers could not distinguish one Network Access Service 182 (NAS) from another, so attacks where one NAS impersonated another 183 were out-of-scope. However channel bindings add this capability and 184 thus expands the threat model of EAP. The GSS-EAP mechanism requires 185 distinguishing one service from another. 187 A relatively untrusted service, say a print server, has been 188 compromised. A user is attempting to connect to a trusted service 189 such as a financial application. Both the print server and the 190 financial application use an Authentication, Authorization and 191 Accounting protocol (AAA) to transport EAP authentication back to the 192 user's EAP server. The print server mounts a man-in-the-middle 193 attack on the user's connection to the financial application and 194 claims to be the application. 196 The print server offers a tunnel method towards the peer. The print 197 server extracts the inner method from the tunnel and sends it on 198 towards the AAA server. Channel binding happens at the tunnel method 199 though. So, the print server is happy to confirm that it is the 200 financial application. After the inner method completes, the EAP 201 server sends the MSK to the print server over the AAA protocol. If 202 only the MSK is needed for cryptographic binding then the print 203 server can successfully perform cryptographic binding and may be able 204 to impersonate the financial application to the peer. 206 Please view in a fixed-width font such as Courier. 208 Client Attacker Server Auth Server 209 | | | | 210 | | | | 211 | Tunnel establishment| | | 212 | | | | 213 |<===================>| | | 214 |.....................| | | 215 | Tunnel | | | 216 | | | | 217 | (Encrypted using | | | 218 | Tunnel keys) | | | 219 | | | | 220 | Tunneled | | | 221 | authentication | | | 222 | method | Inner authentication method | 223 |<===================>|<================================>| 224 |.....................| | | 225 | |<=====MSK keys====================| 226 | Client's session | | | 227 | stolen | | | 228 |<===================>| | | 230 A modified tunnel attack when an extra server rather than extra 231 client is inserted. 233 Channel Binding Requires More than Crypto Binding 235 This attack is not specific to GSS-EAP. The channel bindings 236 specification [I-D.ietf-emu-chbind] describes a number of situations 237 where channel bindings are important for network access. In these 238 situations one NAS could impersonate another by using a similar 239 attack. 241 3. The Server insertion Attack 243 The previous section described an example of the server insertion 244 attack. In this attack, one party adds a layer of tunneling such 245 that from the perspective of the EAP peer, there are more methods 246 than from the perspective of the EAP server. This attack is most 247 beneficial when the party inserting the extra tunnel is a legitimate 248 NAS, so mitigations need to be able to prevent a legitimate NAS from 249 inappropriately adding a layer of tunneling. Some deployments 250 utilize an intentional intermediary that adds an extra level of EAP 251 tunneling between the peer and the EAP server; see Section 3.3 for a 252 discussion. 254 3.1. Conditions for the Attack 256 For an inserted server attack to have value, the attacker needs to 257 gain an advantage from its attack. An advantage to the attacker 258 could come from: 260 o The attacker can send information to a peer that the peer would 261 trust from the EAP server but not the attacker. Examples of this 262 include channel binding responses. 264 o The peer sending information to the attacker that was intended for 265 the EAP server. For example, the inner user identity may disclose 266 privacy-sensitive information. The channel binding request may 267 disclose what service the peer wishes to connect to. 269 o The attacker may influence session parameters. For example, if 270 the attacker can influence the MSK, then the attacker may be able 271 to read or influence session traffic and mount an attack on the 272 confidentiality or integrity of the resulting session. 274 o An attacker may impact availability of the session. In practice 275 though, an attacker that can mount a server insertion attack is 276 likely to be able to impact availability in other ways. 278 For this attack to be possible, the following conditions need to 279 hold: 281 1. The attacker needs to be able to establish a tunnel method with 282 the peer over which the peer will authenticate. 284 2. The attacker needs to be able to respond to any inner 285 authentication. For example an attacker who is a legitimate NAS 286 can forward the inner authentication over AAA towards the EAP 287 server. Note that the inner authentication may not be EAP. 289 3. Typically, the attacker needs to be able to complete the tunnel 290 method after inner authentication. This may not be necessary if 291 the attacker is gaining advantage from information sent by the 292 peer over the tunnel. 294 4. In some cases the attacker may need to complete a Secure 295 Association Protocol (SAP) or otherwise demonstrate knowledge of 296 the MSK after the tunnel method successfully completes. 298 Attackers who are legitimate NASes are the primary focus of this 299 memo. Previous work has provided mitigation against attackers who 300 are not a NAS; these mitigations are briefly discussed. 302 3.2. Mitigation Strategies 304 3.2.1. Server Authentication 306 If the peer confirms the identity of the party that the tunnel method 307 is established with, the peer prevents the first condition (attacker 308 establishing a tunnel method). Many tunnel methods rely on TLS 309 [RFC5281] [I-D.ietf-emu-eap-tunnel-method]. The specifications for 310 these methods tend to encourage or mandate certificate checking. If 311 the TLS certificate is validated back to a trust anchor and the 312 identity of the tunnel method server confirmed, then the first attack 313 condition cannot be met. 315 Many challenges make server authentication difficult. There is not 316 an obvious name by which to identify a tunnel method server. It is 317 not obvious where in the tunnel server certificate the name should be 318 found. One particularly problematic practice is to use a certificate 319 that names the host on which the tunnel server runs. Given such a 320 name it is very difficult for a peer to understand whether that 321 server is intended to be a tunnel method server for the realm. 323 It's not clear what trust anchors to use for tunnel servers. Using 324 commercial Certificate Authorities (CAs) is probably undesirable 325 because tunnel servers often operate in a closed community and are 326 often provisioned with certificates issued by that community. Using 327 commercial CAs can be particularly problematic with peers that 328 support hostnames in certificates. Then anyone who can obtain a 329 certificate for any host in the domain being contacted can 330 impersonate a tunnel server. 332 These difficulties lead to poor deployment of good certificate 333 validation. Many peers make it easy to disable certificate 334 validation. Other peers validate back to trust anchors but do not 335 check names of certificates. What name types are supported and what 336 configuration is easy to perform depends significantly on the peer in 337 question. 339 Specifications also make the problem worse. For example [RFC5281] 340 indicates that the only impact of failing to perform certificate 341 validation is that the inner method can be attacked. Administrators 342 and implementors believing this claim may believe that protection 343 from passive attacks is sufficient. 345 In addition, some deployments such as provisioning or strong inner 346 methods are designed to work without certificate validation. Section 347 3.9 of the tunnel requirements [I-D.ietf-emu-eaptunnel-req] discusses 348 this requirement. 350 3.2.2. Server Policy 352 Server policy can potentially prevent the second condition (attacker 353 being able to respond to inner authentication) from being possible. 354 If the server only performs a particular inner authentication within 355 a tunnel, then the attacker cannot gain a response to the inner 356 authentication without their being such a tunnel. The attacker may 357 be able to add a second layer of tunnels; see Figure 1. The inner 358 tunnel may limit the attacker's capabilities; for example if channel 359 binding is performed over tunnel t2 in the figure, then an attacker 360 cannot observe or influence it. 361 A tunnel t1 from the peer to the attacker contains a tunnel t2 from 362 the peer to the home EAP server. Inside t2 is an inner 363 authentication. 365 Figure 1: Multiple Layered Tunnels 367 Peer policy can be combined with this server policy to help prevent 368 conditions 1 (attacker can establish a tunnel the peer will use) and 369 2 (attacker can respond to inner authentication). If the peer 370 requires exactly one tunnel of a particular type and the EAP server 371 only performs inner authentication over a tunnel of this type, then 372 the attacker cannot establish tunnel t1 in the figure above. 374 An attacker may be able to mount a more traditional man-in-the-middle 375 attack in this instance; see Figure 2. This policy on the peer and 376 EAP server combined with a tunnel method that supports cryptographic 377 binding will allow the EAP server to detect the attacker. This means 378 the attacker cannot act as a legitimate NAS and in particular does 379 not obtain the MSK. So, if the tunnel between the attacker and peer 380 also requires cryptographic binding and if the cryptographic binding 381 requires both the EAP server and peer to prove knowledge of the inner 382 MSK, then the authentication will fail. 384 A tunnel t1 extends from the peer to the attacker. a tunnel t2 385 extends from the attacker to the home EAP server. An inner EAP 386 authentication is forwarded unmodified by the attacker from t1 to t2. 387 The attacker can observe this inner authentication. 389 Figure 2: A Traditional Man-in-the-Middle Attack 391 Cryptographic binding is only a valuable component of a defense if 392 the inner authentication is a key-deriving EAP method. Most tunnel 393 methods also support non-EAP inner authentication such as Microsoft 394 Chap version 2 [RFC2759]. This may undermine cryptographic binding 395 in a number of ways. An attacker may be able to convert an EAP 396 method into a compatible non-EAP form of the same credential to 397 suppress cryptographic binding. In addition, an inner authentication 398 may be available through an entirely different means. For example, a 399 Lightweight Directory Access Protocol [RFC4510] or other directory 400 server may provide an attacker a way to get challenges and provide 401 responses for an authentication mechanism entirely outside of the 402 AAA/EAP context. An attacker with this capability may be able to get 403 around server policy requiring an inner authentication be used only 404 in a given type of tunnel. 405 An attacker can convert an inner authentication using an EAP method 406 to a inner authentication that does not use EAP in some cases. This 407 may avoid cryptographic binding. 409 Converting EAP Inner Authentication 411 An attacker may contact another authentication resource to gain a 412 challenge useful for an inner authentication. 414 Non-EAP Sources of Inner Authentication 416 To Recap, the following policy conditions appear sufficient to 417 prevent a server insertion attack: 419 1. Peer and EAP server require a particular inner EAP method used 420 within a particular tunnel method 422 2. The inner EAP method's authentication is only available within 423 the tunnel and through no other means including non-EAP means 425 3. The inner EAP method produces a key 427 4. The tunnel method supports cryptographic authentication and the 428 peer requires the other end of the tunnel to prove knowledge of 429 the inner MSK. 431 3.2.3. Existing Cryptographic Binding 433 The most advanced examples of cryptographic binding today work at two 434 levels. First, the server and peer prove to each other knowledge of 435 the inner MSK. Then, the inner MSK is combined into some outer key 436 material to form the tunnel's keys. This is sufficient to detect an 437 inserted server or peer provided that the attacker does not learn the 438 inner MSK. This seems sufficient to defend against attackers who 439 cannot act as a legitimate NAS. 441 The definition of cryptographic binding in RFC 3748 does not require 442 these steps. To meet that definition it would be sufficient for a 443 peer to prove knowledge of the inner key to the EAP server. This 444 would open some additional attacks. For example by indicating 445 success an attacker might be able to mask a cryptographic binding 446 failure. Especially if only the tunnel key material is used for the 447 final keys, the peer is unlikely to be able to detect the failure. 449 As discussed in the previous section, cryptographic binding is only 450 effective when the inner method is EAP. 452 3.2.4. Introducing Mutual Cryptographic Binding 454 Cryptographic binding can be strengthened when the inner EAP method 455 supports an Extended Master Session Key (EMSK). The EMSK is never 456 disclosed to any party other than the EAP server or peer, so even a 457 legitimate NAS cannot learn the EMSK. So, if the same techniques 458 currently applied to the inner MSK are applied to the inner EMSK, 459 then condition 3 (completing tunnel authentication) will not hold 460 because the attacker cannot complete this new form of cryptographic 461 binding. This does not prevent the attacker from learning 462 confidential information such as a channel binding request sent over 463 the tunnel prior to cryptographic binding. 465 Obviously as with all forms of cryptographic binding, cryptographic 466 binding only works for key-deriving inner EAP methods. Also, some 467 deployments (see Section 3.3 insert intermediates between the peer 468 and the EAP server. EMSK-based cryptographic binding is incompatible 469 with these deployments because the intermediate cannot learn the 470 EMSK. 472 Formally, mutual cryptographic binding is a security claim for EAP 473 tunnel methods that holds when: 475 1. The peer proves to the server that the peer participating in any 476 inner method is the same as the peer for the tunnel method. 478 2. The server proves to the peer that the server for any inner 479 method is the same as the server for the tunnel method. 481 3. The MSK and EMSK for the tunnel depend on the MSK and EMSK of 482 inner methods. 484 4. A tunnel method may support mutual cryptographic binding 485 optionally and fall back to MSK-based cryptographic binding (for 486 example when an intermediate is intended) but MUST NOT prevent an 487 attacker who is unaware of the inner MSK from forcing a bid-down 488 to MSK-based cryptographic binding. Peers MUST be able to 489 require that if mutual cryptographic binding is unavailable, the 490 authentication will fail. 492 5. Proofs offered need to be secure even against attackers who know 493 the inner method MSK. 495 If mutual cryptographic binding is not an optional facility it 496 provides a strong defense against server insertion attacks and other 497 tunnel MITM attacks for inner methods that provide an EMSK. The 498 strength of the defense is dependent on the strength of the inner 499 method. The value of mutual cryptographic binding is reduced 500 somewhat if it is an optional feature. It permits configurations 501 where a peer requires mutual cryptographic binding if the peer has 502 insufficient information configured to validate the certificate and 503 identity of an EAP server. 505 3.2.5. Mix Key into Long-Term Credentials 507 Another defense against tunnel MITM attacks potentially including 508 server insertion attacks is to use a different credential for 509 tunneled methods from other authentications. This may prevent the 510 second condition (attacker being able to respond to inner 511 authentication) from taking place. For example, if key material from 512 the tunnel is mixed into a shared secret or password that is the 513 basis of the inner authentication, then the second condition will not 514 hold unless the attacker already knows this shared secret. The 515 advantage of this approach is that it seems to be the only way to 516 strengthen non-EAP inner authentications within a tunnel. 518 There are several disadvantages. Choosing a function to mix the 519 tunnel key material into the inner authentication will be very 520 dependent on the inner authentication. In addition, this appears to 521 involve a layering violation. However, exploring the possibility of 522 providing a solution like this seems important because it can 523 function for inner authentications where no other approach will work. 525 3.3. Intended Intermediates 527 Some deployments introduce a tunnel server separate from the EAP 528 server; see [RFC5281] for an example of this style of deployment. 529 The only difference between such an intermediate and an attacker is 530 that the intermediate provides some function valuable to the peer or 531 EAP server and that the intermediate is trusted by the peer. If 532 peers are configured with the necessary information to validate 533 certificates of these intermediates and to confirm their identity, 534 then tunnel MITM and inserted server attacks can be defended against. 535 The intermediates need to be trusted with regard to channel binding 536 and other services that the peer depends on. 538 Support for trusted intermediates is not a requirement according to 539 the tunnel method requirements. 541 It seems reasonable to treat trusted intermediates as a special case 542 if they are supported and to focus on the security of the case where 543 there are not intermediates in the tunnel as the common case. 545 4. Recommendations 547 4.1. Mutual Cryptographic Binding 549 The EAP Tunnel Method [I-D.ietf-emu-eap-tunnel-method] should gain 550 support for mutual cryptographic binding. 552 As channel binding support is added to existing EAP methods, mutual 553 cryptographic binding should also be added to these methods. Mutual 554 cryptographic binding may also be valuable when other services are 555 added to EAP methods that may require a peer trust an EAP server. 557 4.2. State Tracking 559 Today, mutual authentication in EAP is thought of as a security claim 560 about a method. However, in practice it's an attribute of a 561 particular exchange. Mutual authentication can be obtained via 562 checking certificates, through mutual cryptographic binding, or in 563 very controlled cases through carefully crafted peer and server 564 policy combined with existing cryptographic binding. Using services 565 like channel binding that involve the peer trusting the EAP server 566 should require mutual authentication be present in the session. 568 to accomplish this, implementations including channel binding or 569 other peer services MUST track whether mutual authentication has 570 happened. They SHOULD default to not permitting these peer services 571 unless mutual authentication has happened. They SHOULD support a 572 configuration where the peer fails to authenticate unless mutual 573 authentication takes place. Discussion of whether this configuration 574 should be recommended as a default is required. 576 The EAP Tunnel Method should permit peers to force authentication 577 failure if they are unable to perform mutual authentication. The 578 protocol should permit this to be deferred until after mutual 579 cryptographic binding is considered. 581 Services such as channel binding should be deferred until after 582 cryptographic binding/mutual cryptographic binding. 584 4.3. Certificate Naming 586 Work is required to promote interoperable deployment of server 587 certificate validation by peers. A standard way to name EAP servers 588 is required. Recommendations for what name forms peers should 589 implement is required. 591 4.4. Inner Mixing 593 More consideration of the proposal to mix some key material into 594 inner authentications is desired. As stated today, the proposal is 595 under-defined and fairly invasive. Are there versions of this 596 proposal that would be valuable? Is there a way to view it as 597 something more abstract so that it does not involve tunnel and inner 598 method specific combinatorial explosion? 600 5. Survey of Tunnel Methods 601 6. Survey of Inner Methods 602 7. Security Considerations 603 8. Acknowledgements 605 The authors would like to thank Alan DeKok for helping to explore 606 these attacks. Alan focused the discussion on the importance of 607 inner authentications that are not EAP and proposed mixing in key 608 material as a way to resolve these authentications. 610 Jari Arkko provided a review of the attack and valuable context on 611 past efforts in developing cryptographic binding. 613 Sam Hartman's and margaret Wasserman's work on this memo is funded by 614 Huawei. 616 9. References 618 9.1. Normative References 620 [RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The 621 application/pdf Media Type", RFC 3778, May 2004. 623 9.2. Informative References 625 [I-D.ietf-abfab-gss-eap] 626 Howlett, J. and S. Hartman, "A GSS-API Mechanism for the 627 Extensible Authentication Protocol", 628 draft-ietf-abfab-gss-eap-04 (work in progress), 629 October 2011. 631 [I-D.ietf-emu-chbind] 632 Hartman, S., Clancy, T., and K. Hoeper, "Channel Binding 633 Support for EAP Methods", draft-ietf-emu-chbind-13 (work 634 in progress), January 2012. 636 [I-D.ietf-emu-eap-tunnel-method] 637 Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 638 "Tunnel EAP Method (TEAP) Version 1", 639 draft-ietf-emu-eap-tunnel-method-01 (work in progress), 640 October 2011. 642 [I-D.ietf-emu-eaptunnel-req] 643 Zhou, H., Salowey, J., Hoeper, K., and S. Hanna, 644 "Requirements for a Tunnel Based EAP Method", 645 draft-ietf-emu-eaptunnel-req-09 (work in progress), 646 December 2010. 648 [I-D.ietf-nea-pt-eap] 649 Sangster, P. and N. Cam-Winget, "PT-EAP: Posture Transport 650 (PT) Protocol For EAP Tunnel Methods", 651 draft-ietf-nea-pt-eap-00 (work in progress), August 2011. 653 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 654 RFC 2759, January 2000. 656 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 657 (LDAP): Technical Specification Road Map", RFC 4510, 658 June 2006. 660 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 661 Flexible Authentication via Secure Tunneling Extensible 662 Authentication Protocol Method (EAP-FAST)", RFC 4851, 663 May 2007. 665 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 666 Protocol Tunneled Transport Layer Security Authenticated 667 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 669 [TUNNEL-MITM] 670 "". 672 Authors' Addresses 674 Sam Hartman 675 Painless Security 677 Email: hartmans-ietf@mit.edu 679 Margaret Wasserman 680 Painless Security 682 Email: mrw@painless-security.com 683 URI: http://www.painless-security.com/ 685 Dacheng Zhang 686 Huawei 688 Email: zhangdacheng@huawei.com