idnits 2.17.1 draft-puthenkulam-eap-binding-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** There are 83 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 316 has weird spacing: '...ication metho...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DHCPIPsec' is mentioned on line 210, but not defined -- Looks like a reference, but probably isn't: '1' on line 610 -- Looks like a reference, but probably isn't: '2' on line 616 -- Looks like a reference, but probably isn't: '3' on line 620 == Unused Reference: 'RFC1661' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'DHCPIpsec' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'IPSRAREQ' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'GETCERT' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 738, but no explicit reference was found in the text == Unused Reference: 'IEEE80211' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'RFC2486' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'RFC2402' is defined on line 766, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'RFC2407' is defined on line 772, but no explicit reference was found in the text == Unused Reference: 'RFC2412' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'RFC2433' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'RFC2716' is defined on line 795, but no explicit reference was found in the text == Unused Reference: 'RFC2866' is defined on line 801, but no explicit reference was found in the text == Unused Reference: 'DECEPTION' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'KRBATTACK' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'KRBLIM' is defined on line 810, but no explicit reference was found in the text == Unused Reference: 'KERB4WEAK' is defined on line 814, but no explicit reference was found in the text == Unused Reference: 'PPTPv1' is defined on line 819, but no explicit reference was found in the text == Unused Reference: 'IEEE8023' is defined on line 824, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1938 (Obsoleted by RFC 2289) ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) -- Unexpected draft version: The latest known version of draft-ietf-ipsec-dhcp is -12, but you're referring to -13. == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-05 == Outdated reference: A later version (-07) exists of draft-ietf-ipsra-pic-06 -- No information found for draft-ietf-ipsra- - is the name correct? == Outdated reference: A later version (-01) exists of draft-ohba-pana-potls-00 -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) Summary: 9 errors (**), 0 flaws (~~), 29 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group Jose Puthenkulam 3 INTERNET-DRAFT Victor Lortz 4 Category: Informational Intel Corporation 5 Ashwin Palekar 6 27 October 2002 Dan Simon 7 Bernard Aboba 8 Microsoft 10 The Compound Authentication Binding Problem 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet- Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2002). All Rights Reserved. 34 Abstract 36 This document describes man-in-the-middle attacks possible when compound 37 authentication methods are used without cryptographically binding the 38 methods together. Several protocols currently being proposed within the 39 IETF are vulnerable to these attacks, including IKE with XAUTH, PIC, 40 PANA over TLS, EAP TTLS, and PEAP. This document reviews potential 41 solutions to the problem, including solutions which can be implemented 42 as extensions to the EAP protocol. 44 Table of Contents 46 1. Introduction .......................................... 3 47 1.1 Specification of Requirements ................... 3 48 1.2 Terminology ..................................... 4 49 2. Overview .............................................. 4 50 3. Attack scenarios ...................................... 7 51 4. Potential solutions ................................... 8 52 4.1 Solution requirements ........................... 10 53 4.2 Solution mechanisms ............................. 11 54 4.3 Solution approaches ............................. 13 55 4.4 Solution scope .................................. 14 56 5. Normative references .................................. 16 57 6. Informative references ................................ 17 58 ACKNOWLEDGMENTS .............................................. 19 59 AUTHORS' ADDRESSES ........................................... 19 60 Full Copyright Statement ..................................... 20 61 1. Introduction 63 This document describes man-in-the-middle attacks against protocols 64 supporting compound authentication methods. Compound authentication 65 methods can occur in sequence, or more commonly, when authentication 66 method(s) are encapsulated within a tunnel which is itself 67 authenticated. 69 The vulnerability arises when the peers are not required to demonstrate 70 that they have participated in all of the authentication methods 71 occurring within the exchange. Where an authentication method sequence 72 is used, it is possible for a man-in-the-middle to intercede between the 73 client and server, fooling the client into believing that a single 74 endpoint acted as the server throughout the exchange. Where one or more 75 authentication methods in the sequence is one-way or is vulnerable to 76 dictionary attack, this can result in disclosure of client credentials 77 to untrusted peers. 79 Where a one-way authenticated tunnel setup is used to derive 80 authentication and/or encryption keys, and subsequent authentication 81 methods are encapsulated inside the tunnel, it is possible to launch 82 another man-in-the-middle attack. By shuttling authentication packets 83 between the client and server, the man-in-the-middle can authenticate 84 itself to the server and obtain the authentication and/or encryption 85 keys needed for subsequent access to the server. For this attack to be 86 successful, it is necessary for the tunneled authentication methods to 87 also be enabled for use outside the tunnel, and for the same credentials 88 to be used for authentication inside and outside the tunnel. 90 A number of protocols currently proposed within the IETF are vulnerable 91 to these attacks. Vulnerable protocols include, but are not limited to 92 [XAUTH], an IKE extension widely deployed with IPsec VPNs; [PIC], a 93 protocol for certificate enrollment, proposed for use with IPsec VPNs; 94 PANA over TLS [PANATLS], a protocol proposed for use within wireless 95 networks; EAP TTLS [EAPTTLS], an EAP method which tunnels other EAP 96 mechanisms within a TLS tunnel; and Protected EAP [PEAP], a protocol 97 similar to EAP TTLS. 99 Given the wide scope of this vulnerability, a solution is desirable, and 100 this document describes the benefits and limitations of potential 101 solution approaches. 103 1.1. Specification of requirements 105 In this document, several words are used to signify the requirements of 106 the specification. These words are often capitalized. The key words 107 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 108 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 109 interpreted as described in [RFC2119]. 111 1.2. Terminology 113 This document frequently uses the following terms: 115 Authenticator 116 The end of the link requiring the authentication. 118 Peer The other end of the point-to-point link (PPP), point-to-point 119 LAN segment (IEEE 802.1x) or 802.11 wireless link, which being 120 authenticated by the Authenticator. In IEEE 802.1X, this end 121 is known as the Supplicant. 123 Authentication Server 124 An Authentication Server is an entity that provides an 125 Authentication Service to an Authenticator. This service 126 verifies from the credentials provided by the Peer, the claim 127 of identity made by the Peer. 129 Silently Discard 130 This means the implementation discards the packet without 131 further processing. The implementation SHOULD provide the 132 capability of logging the error, including the contents of the 133 silently discarded packet, and SHOULD record the event in a 134 statistics counter. 136 Sequenced Methods 137 Authentication methods which are used in sequence one after an 138 another where each completes and the other one starts. The 139 authentication is complete after the final method in the 140 sequence is completed. 142 Tunneled Methods 143 The first method sets up a tunnel and subsequent method(s) run 144 within the tunnel. 146 2. Overview 148 The attacks described in this document can be mounted against a number 149 of protocols currently proposed for authenticated network access, 150 including [XAUTH],[PIC],[PANATLS], [EAPTTLS], and [PEAP]. The attacks 151 are enabled when compound authentication techniques are used, allowing 152 clients and servers to authenticate each other with a sequence of 153 methods, or one or more methods encapsulated within an authenticated 154 tunnel. The most common attacks occur when the tunnel is authenticated 155 only from the server to the client, so that the client does not prove 156 its identity to the server, and where authentication techniques are 157 permitted both inside and outside a tunnel. 159 In order to enable secure access using legacy authentiation methods, 160 protocols such as XAUTH, PIC, PANA over TLS, EAP TTLS and PEAP first 161 create a security association, using well analyzed techniques such as 162 ISAKMP [RFC2408] and TLS [RFC2246]. They then tunnel authentication 163 methods within the security association. The intent is to utilize dual 164 authentication techniques so as to provide mutual authentication, as 165 well as to allow the derivation of keys used to provide subsequent per- 166 packet authentication and encryption. 168 However, because the initial authentication only authenticates the 169 server to the client, or provides only an indication of group membership 170 (where group pre-shared keys are used within IKE), and because the keys 171 derived within ISAKMP and TLS are not subsequently included within the 172 tunneled authentication computations, there is no demonstration that the 173 ISAKMP/TLS endpoints are the same as the tunneled authentication 174 endpoints. Where authentication techniques are enabled both inside and 175 outside the tunnel, such as when they are in use for multiple purposes 176 (e.g. dialup or web authentication) then an attacker can induce an 177 unsuspecting client to authenticate, then tunnel the authentication 178 within [XAUTH],[PIC],[PANATLS],[EAPTTLS] or [PEAP]. 180 Thus it is the lack of client authentication within the initial security 181 association, along with a dependency of key derivation solely on the 182 initial one-way authentication, the deployment of untunneled 183 authentication methods, and the lack of "cryptographic binding" between 184 the security association and the tunneled authentication method, that 185 enables the vulnerability. Note that in addition to these 186 vulnerabilities, authentication tunneling also provides a number of 187 security benefits, including well understood key derivation, replay and 188 dictionary attack protection and privacy support. These benefits explain 189 why tunneling has been so frequently proposed for legacy authentication 190 methods with known security vulnerabilities. 192 For the purposes of the attack, it makes no difference whether the 193 authentication technique used inside the tunnel provides for mutual 194 authentication or not. As long as the tunneled authentication method 195 does not require that both sides demonstrate participation in the 196 previous "tunnel authentication" as well as subsequent authentications, 197 and as long as keys derived during the exchange are not dependent on 198 material from *all* of the authentications, the vulnerability exists. 199 The tunnel client, having not proved its identity, can act as a man-in- 200 the-middle, luring unsuspecting clients to authenticate to it using any 201 authentication method suitable for use inside the tunnel. 203 Despite the prevalence of man-in-the-middle vulnerabilities within IETF 204 protocol proposals, it should be noted that these attacks are not the 205 result of design flaws within IKE [RFC2409] or EAP [RFC2284]. 207 IPsec VPN implementations which require strong mutual authentication 208 within the tunnel prior to permitting subsequent authentication are not 209 vulnerable to this attack. For example, when L2TP over IPsec [RFC3193] 210 or IPsec tunnel mode [DHCPIPsec], are used with certificate 211 authentication or unique pre-shared keys, the attack is not possible. By 212 requiring strong mutual authentication via certificates or a unique pre- 213 shared key, the tunnel server obtains the ability to verify the identity 214 of the tunnel client, and vice versa. The tunnel server may then 215 subsequently apply access control in order to limit authentication 216 within the established tunnel. 218 However, where group pre-shared keys are used (as is common in IKE Main 219 Mode implementations that support clients with dynamically allocated IP 220 addresses), followed by one-way authentication mechanisms such as CHAP 221 [RFC1994], the vulnerability is exposed. Since group pre-shared keys 222 only determine group membership but authenticate neither the client nor 223 the server, it is not possible for the server to enforce access controls 224 on members of the group individually. Since CHAP is a widely used 225 authentication method, an attacker can gain access to a client willing 226 to engage in CHAP authentication in a variety of ways. This allows any 227 client with knowledge of the group pre-shared key to act as a man-in- 228 the-middle for another member of the group. 230 EAP, as defined in [RFC2284], enables a single authentication mechanism 231 to be negotiated and carried out, but does not describe sequences of 232 methods or tunnels. Most existing EAP implementations do not support 233 authentication sequences, and since EAP does not support a version 234 number, a server cannot easily determine whether an EAP client supports 235 sequences. For backward compatibility, it is therefore necessary for the 236 server to assume that authentication sequences are not supported by 237 default. 239 The concept of tunneling has been introduced by recent work-in-progress 240 such as [PIC], [PANATLS], [EAPTTLS], and [PEAP]. However, these 241 proposals have not yet been published as RFCs, and are not yet widely 242 deployed. 244 Note that man-in-the-middle vulnerabilities are not a necessary 245 consequence of "credential reuse". For example, they need not 246 necessarily occur where the same authentication credentials are used in 247 accessing the network via multiple media. For example, L2TP [RFC2661] 248 when used in "compulsory tunneling", assumes that the same credentials 249 are used for both PPP and VPN access, and permits a PPP dialin user to 250 access a VPN by tunneling PPP packets from the network access server 251 (NAS) to the VPN server. 253 Where L2TP over IPsec [RFC3193] is deployed using certificate 254 authentication or a unique pre-shared key, the L2TP Network Server (LNS 255 or VPN server) can choose to authorize an authenticated tunnel client to 256 act as an L2TP Access Concentrator (LAC), tunneling PPP dialin users to 257 the L2TP Network Server (LNS). Alternatively, it can disallow this, 258 permitting only a restricted set of users to authenticate within a 259 tunnel established with given machine credentials. 261 3. Attack scenarios 263 This section describes a how man-in-the-middle vulnerabilities can be 264 exploited, as well as discussing the underlying causes of the attacks. 265 Given the man possible attack variations, we do not attempt to describe 266 every potential variant. 268 The major scenario for the attack is a one-way authenticated tunnel. In 269 this scenario, the client and server first establish a tunnel, then 270 include within the tunnel an authentication method which derives keys 271 and provides strong mutual authentication. The attacker first poses as 272 a valid client to the server and establishes a tunnel that is 273 authenticated only on the server end. Although the attacker that sets up 274 the tunnel has not been authenticated, it obtains the tunnel key derived 275 as part of the tunnel establishment. Since these keys protect a 276 conversation between an attacker and a server, the strength of the key 277 derivation is not relevant. 279 For the purposes of exploiting the vulnerability, it does not matter 280 whether the tunneling protocol is IKE [RFC2409] authenticated via a 281 group pre-shared key; PIC [PIC], which uses ISAKMP [RFC2408] with one- 282 way authentication; or TLS [RFC2246] with server-only authentication, as 283 used with [PANATLS], [EAPTTLS] or [PEAP]. The effect is the same - a 284 tunnel that does not provide unique mutual authentication of the tunnel 285 endpoints. 287 Once the attacker has established a tunnel to the server, it seeks to 288 induce clients to connect to it. This can be accomplished by having the 289 attacker masquerade as a legitimate 802.11 access point (AP) or Ethernet 290 switch implementing [IEEE8021X], a PPP Network Access Server (NAS), a 291 SIP server supporting CHAP, or a VPN server using a protocol such as 292 PPTP [RFC2637]. For the purposes of the attack, the important 293 characteristic is that the protocol used by the client enables an 294 authentication method which is also permitted within the tunneling 295 mechanism, without first requiring that the attacker authenticate 296 itself. For example, an attacker setting up a rogue L2TP over IPsec 297 [RFC3193] server would not be successful since clients would first 298 require mutual authentication within IKE prior to connecting to the 299 rogue server. 301 It is also necessary that the credentials used for the client protocol 302 and the tunneled authentication protocol are the same. Without this, it 303 would not be possible for the authentication conversation between the 304 client and server to conclude successfully. 306 Figure 1 on the next page illustrates the attack, for the case where the 307 attacker acts as a rogue NAS or Access Point. In step 1, the attacker 308 creates a tunnel with the authentication server. This can occur directly 309 in [PIC] or [XAUTH] or through a NAS using EAP [RFC2284]. In step 2, 310 tunnel keys are derived, using server-only authentication using 311 protocols such as ISAKMP [RFC2408], IKE [RFC2409] or TLS [RFC2246]. 312 Since the tunnel is between the attacker and the authentication server, 313 both the authentication server and attacker possess the keys. 315 In the third step, the client connects to the rogue NAS or AP, and the 316 attacker tunnels the authentication method between the client and 317 authentication server. The method may or may not derive keys, but if it 318 does, then in the fourth step, the method keys are derived on the client 319 and the authentication server. Since the attacker does not obtain the 320 method keys, it is not able to decrypt traffic sent between client and 321 authentication server. However, while the client may use the method 322 keys, the authentication server will typically use only tunnel keys, 323 which have been obtained by the attacker. 325 In the last step, this allows the attacker to obtain access to the 326 network, using the successfully tunneled authentication and the tunnel 327 keys. The attacker does not have access to the client data, since it is 328 encrypted with the method keys, so that it will typically discard the 329 data sent by the client, who will eventually disconnect due to a lack of 330 response. However, the attacker has accomplished its mission so that 331 continued interaction with the client is not necessary unless 332 reauthentication is required. 334 4. Potential solutions 336 This section describes potential solutions to the man-in-the-middle 337 attacks described within this document. This includes a description of 338 solution requirements as well as identification of potential solution 339 approaches. 341 Client <-|Rogue NAS | NAS Auth Server 342 | Attacker |-> 343 | | | | 344 | | | | 345 | | Tunnel establishment w/ | 346 | | Server Authentication (1) | 347 | |<========================================>| 348 | | | | 349 | (Non-Authenticated | (Authenticated 350 | end of tunnel) | end of tunnel) 351 | | | | 352 | +--------------+ | +--------------+ 353 | | Tunnel | (2) | | Tunnel | 354 | | Keys Derived | | | Keys Derived | 355 | +--------------+ | +--------------+ 356 | | | | 357 | |..........................................| 358 | | Tunnel | 359 | |..........................................| 360 | | (Encrypted using Tunnel keys) | 361 | | | | 362 | | | | 363 | Tunneled authentication method (3) | 364 |<==============================================================>| 365 | | | | 366 | | | | 367 +--------------+ | | +--------------+ 368 | Method | | | | Method | 369 | Keys Derived | (4) | | | Keys Derived | 370 | and used. | | | | Not Used. | 371 +--------------+ | | +--------------+ 372 | | | | 373 | | |<===tunnel keys=========| 374 | | | | 375 | | Client's session| | 376 | | stolen | | 377 |====================+|<===============>| | 378 | Data || | | 379 | dropped v| | | 381 Figure 1 - Man-in-the-middle attack on one-way authenticated tunnel 382 4.1. Solution Requirements 384 The following are some of the criteria for a potential solution: 386 Backwards compatibility 387 A solution MUST NOT require modification of existing 388 authentication methods. Since tunneling is used in order 389 to prolong the life of legacy authentication techniques, 390 requiring replacement of existing methods across the 391 board is likely to be unacceptable. 393 Simplicity A solution SHOULD add minimal round trips to the 394 authentication exchange and be modest in its 395 computational complexity. 397 Protocol compatibility 398 Given that tunneling techniques are used with well- 399 established security protocols such as IKE [RFC2409], 400 ISAKMP [RFC2408], TLS [RFC2246], and RADIUS [RFC2865], a 401 solution MUST NOT require changes to these protocols. 403 Forward evolution 404 The solution SHOULD be compatible with authentication 405 methods supporting mutual authentication and key 406 derivation. It is acceptable if the solution cannot 407 provide security for tunneling of one-way authentication 408 methods that do not derive keys, such as CHAP, EAP-MD5, 409 OTP, or Generic Token Card. As described earlier, these 410 methods are vulnerable to connection hijacking attacks, 411 and are therefore inherently insecure. 413 Architectural compatibility 414 Solutions MUST NOT require fundamental architectural 415 changes to established technologies such as network 416 access authentication. Since these technologies are 417 already widely deployed, such changes would be likely to 418 be unacceptable. 420 Tunneling protocol independence 421 While a solution MAY introduce changes to tunneling 422 protocols such as [XAUTH],[PIC], [PANATLS], [EAPTTLS], or 423 [PEAP], it is preferable that a single solution be 424 applicable to all of these protocols. This is desirable 425 both because such a solution will require the least 426 effort deploy, as well as to enable the security 427 community to focus on a single proposed solution so as to 428 be able to determine that it is secure. 430 4.2. Solution mechanisms 432 Several mechanisms are available to solving the problem: 434 [1] Compound MACs. This solution uses Message Authentication Codes 435 (MACs) computed using keying material from each of the 436 authentication methods, by adding a final mutual authenticating 437 round-trip. In order to make sure that both sides are aware of the 438 outcome of the authentication, the compound MAC MUST include 439 coverage of the authentication result (success/failure) sent by 440 each side. This ensures that the server cannot be tricked into 441 using the tunnel key in the attacker's posession in order to 442 authenticate and encrypt data. 444 [2] Compound keys. this solution combines keying material from all the 445 methods in order to derive the keys used for encrypting and 446 authenticating data. 448 Option 1 prevents a man-in-the-middle from gaining authenticated access, 449 and therefore prevents false authenticated states which could result in 450 a Denial of Service attack (possible in Option 2). This makes this 451 approach relatively straightforward to implement, although it does 452 require an additional round-trip. While it is believed that this 453 approach may be sufficient in some cases, further study is required in 454 order confirm this. 456 Option 2 does not require additional round trips, but it enables the 457 man-in-the-middle to authenticate, although not to obtain keys used for 458 subsequent authentication and encryption of data. This implies that the 459 client will only discover an attack when it discovers that it is unable 460 to decipher the incoming data stream. This enables a form of Denial of 461 Service attack. As a result, Option 2 is probably not sufficient by 462 itself. 464 In order to provide the highest level of assurance against man-in-the- 465 middle attacks it is recommended that a potential solution utilize both 466 options 1 and 2, so that a man-in-the-middle will not be able to 467 authenticate, spoof an authentication result or derive keys used to 468 authenticate and encrypt traffic between the legitimate client and 469 server. When both solution options applied, potential man-in-the-middle 470 attacks are thwarted, as shown in Figure 2 on the next page. 472 Client <-|Rogue NAS | NAS Auth Server 473 | Attacker |-> 474 | | | | 475 | | | | 476 | | Tunnel establishment w/ | 477 | | Server Authentication (1) | 478 | |<========================================>| 479 | | | | 480 | (Non-Authenticated | (Authenticated 481 | end of tunnel) | end of tunnel) 482 | | | | 483 | +--------------+ | +--------------+ 484 | | Tunnel | (2) | | Tunnel | 485 | | Keys Derived | | | Keys Derived | 486 | +--------------+ | +--------------+ 487 | | | | 488 | |..........................................| 489 | | Tunnel | 490 | |..........................................| 491 | | (Encrypted using Tunnel keys) | 492 | | | | 493 | | | | 494 | Tunneled mutual authentication method (3) | 495 | | w/key derivation| | 496 |<==============================================================>| 497 | | | | 498 | | | | 499 +--------------+ | | +--------------+ 500 | Compound | | | | Compound | 501 | Keys Derived | (4) | | | Keys Derived | 502 +--------------+ | | +--------------+ 503 | | | | 504 | | Compound MAC(5)/| | 505 | | Success | | 506 |<===============================================================| 507 | | | | 508 | | Compound MAC(6)/| | 509 | | Failure | | 510 |===============================================================>| 511 | | | | 512 | | | Attack detected | 513 | | | No keys sent | 514 | | | | 515 | | | Failure | 516 | | | <======================| 517 | | | | 519 Figure 2 - Man-in-the-middle attack thwarted by compound MAC and keys 520 As before, the man-in-the-middle can establish a one-way authenticated 521 tunnel, obtain tunnel keys, lure an unsuspecting client to authenticate 522 with it, and encapsulate the authentication exchange within the tunnel. 523 However, after the authentication method is complete compound keys are 524 derived, requiring knowledge of both the tunnel keys and the keys 525 derived during each of the authentication methods. The compound keys are 526 then used in formulation of a compound MAC covering an acknowledged 527 result indication sent from server to client. Since the server is not 528 aware of the man-in-the-middle attack in progress, it indicates that 529 from its perspective the authentication has been successful. 531 However, since the client did not participate in establishment of the 532 tunnel, it does not possess the tunnel keys, and will not be able to 533 verify the compound MAC sent by the server. As a result, it will compute 534 its own compound key and compound MAC which will include a result 535 indicating authentication failure. On receiving the client's reply, the 536 server will be unable to verify the client's compound MAC, and the 537 authentication will fail. As a result, no compound keys are sent to the 538 NAS, and the attacker is neither authenticated nor gains access to the 539 network. 541 4.3. Solution approaches 543 Options 1 or 2 can be implemented in different ways: 545 EAP In this approach the exchange of a compound MAC is supported 546 within EAP, by implementing the exchange as a new EAP method 547 occuring after authentication is complete. In this approach, 548 the tunneling key material is provided to the EAP layer in 549 order to enable computation of a compound MAC and compound 550 keys. Since existing EAP implementations already enable EAP 551 methods to provide keying material to the EAP layer, such an 552 interface typically already exists. Since this approach 553 applies to any tunneling technique it is the most general 554 approach. 556 Tunneling method 557 In this approach, the tunneling method acquires keying 558 material derived by the underlying authentication methods in 559 order to enable computation of the compound MAC and compound 560 keys. Since existing tunneling techniques typically do not 561 provide an interface for receiving keying material from 562 authentication methods, this approach will typically require 563 some re-architecture of existing implementations. It also has 564 the disadvantage of requiring changes to each tunneling 565 method, and as a result is not as general as an EAP-based 566 solution. Given the prevalence of the attacks described within 567 this document, it would represent a considerable burden on the 568 security community to individually review changes to each 569 tunneling approach. However, such an approach may be able to 570 take advantage of properties of the underlying tunnel 571 technology, such as the ability to have more than one packet 572 in transit at a time. 574 EAP methods 575 In this approach, keys derived from previous EAP methods are 576 incorporated into the authentication calculations of 577 subsequent methods. Since existing interfaces only support the 578 export of keys by EAP methods, not importation, some 579 rearchitecture is required in this approach. In addition, this 580 approach requires modification of existing EAP methods, which 581 will create deployment barriers. However, this approach may 582 be applied even to methods which support only one-way 583 authentication and do not generate keys. 585 Based on the pros and cons of the above techniques, we recommend a 586 solution that applies to all EAP methods. Since EAP is supported within 587 [PIC], [PANATLS], [EAPTTLS] and [PEAP], though not within [XAUTH], this 588 approach covers most of the vulnerable protocols, though not all of 589 them. Assuming that changes to individual EAP methods are not permitted, 590 this approach is only applicable to tunneling of authentication methods 591 that support mutual authentication and derive keys. It is therefore not 592 applicable to CHAP, EAP-MD5, EAP-OTP, EAP-GTC or EAP-SECURID 593 authentication methods. 595 Without requiring changes to established methods, secure use of these 596 protocols within sequences or tunnels is not feasible. If an 597 authentication method does not generate keys, then keying material is 598 not available with which to compute a compound MAC or compound key. As a 599 result, the compound authentication sequence cannot be bound together, 600 enabling the man-in-the-middle vulnerability to remain. 602 4.4. Solution scope 604 While options 1 and 2 address many of the attack scenarios, they do not 605 cope with all of them. If every authentication method within a sequence 606 generates keys, then a compound MAC can be used to verify that each 607 endpoint participated in each of the authentication methods within the 608 compound authentication. There are some exceptions: 610 [1] Anonymous or one-way authentication methods. Some authentication 611 methods use anonymous or one-way authentication. In this case, as 612 long as a combination of authentication methods support mutual 613 authentication, the combined keys could be used to verify both 614 peers. 616 [2] Methods that do not generate keys. If one or more authentication 617 method(s) that do not generate keys are allowed to run with and 618 without tunneling, then a man-in-the-middle attack is enabled. 620 [3] Lack of data integrity/encryption. Where per-packet authentication, 621 integrity and encryption is not used, there is no binding between 622 the results of the authentication and subsequent data traffic. This 623 enables connection hijacking. 625 In order to verify that the peers acted as end-points in a compound 626 authentication, the peers can exchange compound MACs. However, 627 authentication schemes which do not derive keys cannot contribute to 628 calculation of a compound MAC or a compound key. Such mechanisms 629 include popular one-way authentication mechanisms such as CHAP 630 [RFC1994], EAP-MD5 [RFC2284], One-Time-Password [RFC1938], Generic Token 631 Card [RFC2284], and [SECURID]. These mechanisms authenticate the client 632 to the server, but do not authenticate the server to the client. They 633 also do not derive keys which can be used in constructing a compound MAC 634 or providing authentication and/or encryption of a subsequent data 635 stream via a compound key. As a result, without modifications these 636 methods cannot be bound to the underlying tunnel authentiation and also 637 do not provide a binding between the one-way authentication and 638 subsequent data authentication, thereby creating a connection hijacking 639 vulnerability. 641 In order to enable a solution for these methods, existing one-way 642 authentication methods may be modified so as to enable key derivation, 643 or to incorporate key material derived during the initial tunnel 644 authentication. However, since the motivation for continued use of 645 legacy technologies is to minimize the deployment of new technology, 646 such upgrades are typically impractical. In situations where deployment 647 of a modified legacy method would be feasible, it would also typically 648 be feasible to consider a wide range of alternatives, such as deployment 649 of a new method supporting mutual authentication and key derivation, or 650 deployment of alternative technologies such as certificates. 652 Given these constraints, it appears difficult for authentication 653 tunneling to provide a long-term solution to the security 654 vulnerabilities inherent in one-way authentication methods such as CHAP, 655 EAP-MD5, OTP, and Generic Token Card. Where protocols such as [PIC] are 656 used to transition from these technologies to certificate-based 657 authentication, it may be possible to restrict the transition to a short 658 time period, as well as to turn off use of the techniques outside of 659 [PIC]. 661 These counter-measures may reduce the risk sufficiently to enable 662 certificate deployment to proceed. However, where [PIC] is used to 663 provide short- term certificates, and long-term use of password or 664 token-card based authentication technology is contemplated, improved 665 security will not be possible without a willingness to replace legacy 666 authentication methods with more secure technology. 668 If a transition to certificate-based authentication is not possible, 669 then at the least, one-way authentication technology can be replaced by 670 techniques supporting mutual authentication and key derivation. For 671 example, CHAP may be replaced by Kerberos [RFC1510] or MS-CHAP-V2 672 [RFC2759] and Generic Token Card may be replaced by token cards 673 supporting key derivation. 675 5. Normative references 677 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 678 RFC 1661, July 1994. 680 [RFC1938] Haller, N. and C. Metz, "A One-Time Password System", RFC 681 1938, May 1996. 683 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 684 Protocol (CHAP)", RFC 1994, August 1996. 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", RFC 2119, March 1997.] 689 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 690 Protocol (EAP)", RFC 2284, March 1998. 692 [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., 693 "Remote Authentication Dial In User Service (RADIUS)", 694 RFC 2865, June 2000. 696 [RFC3193] Patel, B., et al., "Securing L2TP Using IPsec", RFC 3193, 697 November 2001. 699 [EAPTTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS 700 Authentication Protocol", Internet draft (work in 701 progress), February 2002. 703 [DHCPIpsec] Patel, B., et al., "DHCPv4 Configuration of IPsec Tunnel 704 Mode", Internet draft (work in progress), draft-ietf- 705 ipsec-dhcp-13.txt, June 2001. 707 [PEAP] Andersson, H., et al., "Protected EAP Protocol (PEAP)", 708 Internet draft (work in progress), draft-josefsson- 709 pppext-eap-tls-eap-05.txt, September 2002. 711 [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE 712 Credential Provisioning Protocol", Internet draft (work 713 in progress), draft-ietf-ipsra-pic-06.txt, September 714 2002. 716 [IPSRAREQ] Kelly, S., Ramamoorthi, S., "Requirements for IPsec 717 Remote Access Scenarios", Internet draft (work in 718 progress), draft-ietf-ipsra- reqmts-05.txt, September 719 2002. 721 [GETCERT] Bellovin, S., and Moskowitz, B., "Client Certificate and 722 Key Retrieval for IKE", Internet draft (work in 723 progress), draft-bellovin-ipsra-getcert-00.txt, June 724 2000. 726 [SECURID] Josefsson, S., "The EAP SecurID(r) Mechanism", Internet 727 draft (work in progress), draft-josefsson-eap- 728 securid-01.txt, February 2002. 730 [PANATLS] Ohba, Y., et al., "PANA over TLS", Internet draft (work 731 in progress), draft-ohba-pana-potls-00.txt, September 732 2002. 734 [XAUTH] Pereira, R., Beaulieu, S., "Extended Authentication 735 within ISAKMP/Oakley", Internet-draft (work in progress), 736 draft-beaulieu-ike-xauth-02.txt, September, 2000. 738 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 739 Overview and Architecture, ANSI/IEEE Std 802, 1990. 741 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 742 Port based Network Access Control, IEEE Std 802.1X-2001, 743 June 2001. 745 [IEEE80211] Information technology - Telecommunications and 746 information exchange between systems - Local and 747 metropolitan area networks - Specific Requirements Part 748 11: Wireless LAN Medium Access Control (MAC) and 749 Physical Layer (PHY) Specifications, IEEE Std. 750 802.11-1997, 1997. 752 6. Informative references 754 [RFC1510] Kohl, J., Neuman, C., "The Kerberos Network 755 Authentication Service (V5)", RFC 1510, September 1993. 757 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 758 RFC 2246, November 1998. 760 [RFC2486] Beadles, M., Aboba, B., "The Network Access Identifier", 761 RFC 2486, January 1999. 763 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the 764 Internet Protocol", RFC 2401, November 1998. 766 [RFC2402] Kent,S., Atkinson, R., "IP Authentication Header", RFC 767 2402, November 1998. 769 [RFC2406] Kent,S., Atkinson, R., "IP Encapsulating Security Payload 770 (ESP)", RFC 2406, November 1998. 772 [RFC2407] Piper, D., "The Internet IP Security Domain of 773 Interpretation of ISAKMP", RFC 2407, November 1998. 775 [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and Turner, 776 J., "Internet Security Association and Key Management 777 Protocol (ISAKMP)", RFC 2408, November 1998. 779 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 780 (IKE)", RFC 2409, November 1998. 782 [RFC2412] Orman, H., "The Oakley Key Determination Protocol", RFC 783 2412, Nov. 1998. 785 [RFC2433] Zorn, G., Cobb, S., "Microsoft PPP CHAP Extensions", RFC 786 2433, October 1998. 788 [RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol 789 (PPTP)", RFC 2637, July 1999. 791 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 792 G., and Palter, B., "Layer Two Tunneling Protocol L2TP", 793 RFC 2661, August 1999. 795 [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication 796 Protocol", RFC 2716, October 1999. 798 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 799 2759, January 2000. 801 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 803 [DECEPTION] Slatalla, M., and Quittner, J., "Masters of Deception." 804 HarperCollins, New York, 1995. 806 [KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos Password 807 Security", Stanford University Computer Science 808 Department, http://theory.stanford.edu/~tjw/krbpass.html 810 [KRBLIM] Bellovin, S.M., Merritt, M., "Limitations of the kerberos 811 authentication system", Proceedings of the 1991 Winter 812 USENIX Conference, pp. 253-267, 1991. 814 [KERB4WEAK] Dole, B., Lodin, S., and Spafford, E., "Misplaced trust: 815 Kerberos 4 session keys", Proceedings of the Internet 816 Society Network and Distributed System Security 817 Symposium, pp. 60-70, March 1997. 819 [PPTPv1] Schneier, B, Mudge, "Cryptanalysis of Microsoft's Point- 820 to- Point Tunneling Protocol", Proceedings of the 5th ACM 821 Conference on Communications and Computer Security, ACM 822 Press, November 1998. 824 [IEEE8023] ISO/IEC 8802-3 Information technology - 825 Telecommunications and information exchange between 826 systems - Local and metropolitan area networks - Common 827 specifications - Part 3: Carrier Sense Multiple Access 828 with Collision Detection (CSMA/CD) Access Method and 829 Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 830 1996), 1996. 832 Acknowledgments 834 Thanks to Bernard Aboba for editorial assistance and discussions 835 relevant to this problem space. 837 Authors' Addresses 839 Jose Puthenkulam 840 Intel Corporation 841 2111 NE 25th Avenue, JF2-58 842 Hillsboro, OR 97124 844 EMail: jose.p.puthenkulam@intel.com 845 Phone: +1 503 264 6121 846 Fax: +1 503 264 8154 848 Victor Lortz 849 Intel Corporation 850 2111 NE 25th Avenue, JF3-206 851 Hillsboro, OR 97124 853 EMail: viktor.lortz@intel.com 854 Phone: +1 503 264 3253 855 Fax: +1 503 626 0396 856 Ashwin Palekar 857 Dan Simon 858 Bernard Aboba 859 Microsoft Corporation 860 One Microsoft Way 861 Redmond, WA 98052 863 EMail: {ashwinp, dansimon, bernarda}@microsoft.com 864 Phone: +1 425 882 8080 865 Fax: +1 425 936 7329 867 Full Copyright Statement 869 Copyright (C) The Internet Society (2002). All Rights Reserved. 870 This document and translations of it may be copied and furnished to 871 others, and derivative works that comment on or otherwise explain it or 872 assist in its implementation may be prepared, copied, published and 873 distributed, in whole or in part, without restriction of any kind, 874 provided that the above copyright notice and this paragraph are included 875 on all such copies and derivative works. However, this document itself 876 may not be modified in any way, such as by removing the copyright notice 877 or references to the Internet Society or other Internet organizations, 878 except as needed for the purpose of developing Internet standards in 879 which case the procedures for copyrights defined in the Internet 880 Standards process must be followed, or as required to translate it into 881 languages other than English. The limited permissions granted above are 882 perpetual and will not be revoked by the Internet Society or its 883 successors or assigns. This document and the information contained 884 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 885 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 886 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 887 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 888 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 890 EAP Issues 892 Open issues relating to EAP, including the issues described in this 893 document, are tracked on the following web site: 895 http://www.drizzle.com/~aboba/EAP/eapissues.html 897 Expiration Date 899 This memo is filed as , and 900 expires April 24, 2003.