idnits 2.17.1 draft-puthenkulam-eap-binding-01.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 84 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 344 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: 'RFC1993' is mentioned on line 152, but not defined == Missing Reference: 'DHCPIPsec' is mentioned on line 205, but not defined -- Looks like a reference, but probably isn't: '1' on line 577 -- Looks like a reference, but probably isn't: '2' on line 602 == Unused Reference: 'RFC1661' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'DHCPIpsec' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'IPSRAREQ' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'GETCERT' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'IEEE80211' is defined on line 710, but no explicit reference was found in the text == Unused Reference: 'RFC2486' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'RFC2402' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 734, but no explicit reference was found in the text == Unused Reference: 'RFC2407' is defined on line 737, but no explicit reference was found in the text == Unused Reference: 'RFC2412' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'RFC2433' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'RFC2716' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'RFC2866' is defined on line 766, but no explicit reference was found in the text == Unused Reference: 'DECEPTION' is defined on line 768, but no explicit reference was found in the text == Unused Reference: 'KRBATTACK' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'KRBLIM' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'KERB4WEAK' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'PPTPv1' is defined on line 784, but no explicit reference was found in the text == Unused Reference: 'IEEE8023' is defined on line 789, 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 (~~), 30 warnings (==), 16 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 28 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 ................................... 9 52 4.1 Solution requirements ........................... 9 53 4.2 Solution mechanisms ............................. 10 54 4.3 Solution approaches ............................. 13 55 4.4 Solution scope .................................. 14 56 5. Normative references .................................. 15 57 6. Informative references ................................ 17 58 ACKNOWLEDGMENTS .............................................. 18 59 AUTHORS' ADDRESSES ........................................... 18 60 Full Copyright Statement ..................................... 19 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 also possible to a 82 man-in-the-middle attack. By shuttling authentication packets between 83 the client and server, the man-in-the-middle can authenticate itself to 84 the server and obtain the authentication and/or encryption keys needed 85 for subsequent communication with 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 proposed IETF protocols, including [XAUTH],[PIC],[PANATLS], 150 [EAPTTLS], and [PEAP]. Each of these protocols support authentication 151 tunneling of legacy authentication methods such as CHAP [RFC1994], EAP- 152 MD5 [RFC2284], One-Time-Password (OTP) [RFC1993], Generic Token Card 153 (GTC) [RFC2284], and SecurID [SECURID] in order to provide a number of 154 benefits, including well understood key derivation, replay and 155 dictionary attack protection and privacy support. 157 The attacks are enabled when compound authentication techniques are 158 used, allowing clients and servers to authenticate each other with a 159 sequence of methods, or one or more methods encapsulated within an 160 authenticated tunnel. The most common attacks occur when the tunnel is 161 authenticated only from the server to the client, and where tunneled 162 authentication techniques are permitted both inside and outside a 163 tunnel. The tunnel client, having not proved its identity, can act as a 164 man-in-the-middle, luring unsuspecting clients to authenticate to it, 165 using any authentication method suitable for use inside the tunnel. The 166 attacks are possible, even though the tunnels created within these 167 protocols utilize well analyzed protocols such as ISAKMP [RFC2408] and 168 TLS [RFC2246], because mutual authentication (supported within both 169 protocols) is not used. 171 Since the initial authentication only authenticates the server to the 172 client, or provides only an indication of group membership (where group 173 pre-shared keys are used within IKE), and because the keys derived 174 within ISAKMP and TLS are not subsequently included within the tunneled 175 authentication methods, there is no demonstration that the ISAKMP/TLS 176 endpoints are the same as the tunneled authentication endpoints. Where 177 authentication techniques are enabled both inside and outside the 178 tunnel, such as when they are in use for multiple purposes (e.g. dialup 179 or web authentication) then an attacker can induce an unsuspecting 180 client to authenticate, then tunnel the authentication within 181 [XAUTH],[PIC],[PANATLS],[EAPTTLS] or [PEAP]. 183 For the purposes of the attack, it makes no difference whether the 184 authentication method used inside the tunnel supports mutual 185 authentication or not. The vulnerability exists as long as both sides 186 are not required to demonstrate participation in the previous "tunnel 187 authentication" as well as subsequent authentications, and as long as 188 keys derived during the exchange are not dependent on material from 189 *all* of the authentications. 191 Thus it is the lack of client authentication within the initial security 192 association, combined with key derivation based on a one-way tunnel 193 authentication, and lack of "cryptographic binding" between the security 194 association and the tunneled authentication method that enables the 195 vulnerability. In addition, it is necessary for the same authentication 196 methods to be allowed inside and outside of tunnels. 198 Despite the prevalence of man-in-the-middle vulnerabilities within IETF 199 protocol proposals, it should be noted that these attacks are not the 200 result of design flaws within IKE [RFC2409] or EAP [RFC2284]. 202 IPsec VPN implementations which require strong mutual authentication 203 within the tunnel prior to permitting subsequent authentication are not 204 vulnerable to this attack. For example, when L2TP over IPsec [RFC3193] 205 or IPsec tunnel mode [DHCPIPsec], are used with certificate 206 authentication or unique pre-shared keys, the attack is not possible. By 207 requiring strong mutual authentication via certificates or a unique pre- 208 shared key, the tunnel server obtains the ability to verify the identity 209 of the tunnel client. The tunnel server may then subsequently apply 210 access control in order to limit authentication within the established 211 tunnel. 213 However, where group pre-shared keys are used (as is common in IKE Main 214 Mode implementations that support clients with dynamically allocated IP 215 addresses), followed by one-way authentication mechanisms such as CHAP 216 [RFC1994], the vulnerability is exposed. Since group pre-shared keys 217 only determine group membership but authenticate neither the client nor 218 the server, it is not possible for the server to enforce access controls 219 on individual members of the group. Since CHAP is a widely used 220 authentication method, an attacker can easily gain access to a client 221 willing to engage in CHAP authentication. This allows any client with 222 knowledge of the group pre-shared key to act as a man-in-the-middle for 223 another member of the group. 225 EAP, as defined in [RFC2284], enables a single authentication mechanism 226 to be negotiated and carried out, but does not describe sequences of 227 methods or tunnels. Most existing EAP implementations do not support 228 authentication sequences, and since EAP does not support a version 229 number, a server cannot easily determine whether an EAP client supports 230 sequences. For backward compatibility, it is therefore necessary for the 231 server to assume that authentication sequences are not supported by 232 default. 234 The concept of EAP tunneling has been introduced by recent work-in- 235 progress such as [PIC], [PANATLS], [EAPTTLS], and [PEAP]. However, these 236 proposals have not yet been published as RFCs, and are not yet widely 237 deployed. 239 Note that man-in-the-middle vulnerabilities are not a necessary 240 consequence of "credential reuse". For example, they need not 241 necessarily occur where the same authentication credentials are used in 242 accessing the network via multiple media. For example, L2TP [RFC2661] 243 when used in "compulsory tunneling", assumes that the same credentials 244 are used for both PPP and VPN access. PPP dialin users are then 245 permitted to access a VPN by tunneling PPP packets from the network 246 access server (NAS) to the VPN server. 248 Where L2TP over IPsec [RFC3193] is deployed using certificate 249 authentication or a unique pre-shared key, the L2TP Network Server (LNS 250 or VPN server) can choose to authorize an authenticated tunnel client to 251 act as an L2TP Access Concentrator (LAC), tunneling PPP dialin users to 252 the L2TP Network Server (LNS). Alternatively, it can disallow this, 253 permitting only a restricted set of users to authenticate within a 254 tunnel established with given machine credentials. 256 3. Attack scenarios 258 This section describes how man-in-the-middle vulnerabilities can be 259 exploited, as well as discussing the underlying causes of the attacks. 260 Given the many possible attack variations, we do not attempt to describe 261 every potential variant. 263 The major scenario for the attack is a one-way authenticated tunnel 264 encapsulating subsequent authentication methods. In this scenario, the 265 client and server first establish a tunnel, then include within the 266 tunnel one or more authentication method(s). The attacker first poses 267 as a valid client to the server and establishes a tunnel that is 268 authenticated only on the server end, obtaining tunnel keys. Since 269 these keys protect a conversation between an attacker and a server, the 270 strength of the key derivation is not relevant. 272 For the purposes of exploiting the vulnerability, it does not matter 273 whether the tunneling protocol is IKE [RFC2409] authenticated via a 274 group pre-shared key; PIC [PIC], which uses ISAKMP [RFC2408] with one- 275 way authentication; or TLS [RFC2246] with server-only authentication, as 276 used with [PANATLS], [EAPTTLS] or [PEAP]. The effect is the same - a 277 tunnel that does not provide mutual authentication of the tunnel 278 endpoints. 280 Once the attacker has established a tunnel to the server, it seeks to 281 induce clients to connect to it. This can be accomplished by having the 282 attacker masquerade as a legitimate 802.11 access point (AP) or Ethernet 283 switch implementing [IEEE8021X], a PPP Network Access Server (NAS), a 284 SIP server supporting CHAP, or a VPN server using a protocol such as 285 PPTP [RFC2637]. For the purposes of the attack, it is necessary that 286 the client be induced to authenticate to the attacker using an 287 authentication mechanism permitted within the tunnel. It is also 288 necessary that the credentials within the client protocol and the 289 tunneled authentication protocol are the same, so that the 290 authentication mechanism remains valid when encapsulated within the 291 tunnel. 293 Figure 1 on the next page illustrates the attack, for the case where the 294 attacker acts as a rogue NAS or Access Point. In step 1, the attacker 295 creates a tunnel with the authentication server. This can occur directly 296 in [PIC] or [XAUTH] or through a NAS using EAP [RFC2284]. In step 2, 297 tunnel keys are derived, using server-only authentication via protocols 298 such as ISAKMP [RFC2408], IKE [RFC2409] with group pre-shared keys or 299 TLS [RFC2246]. Since the tunnel is between the attacker and the server, 300 both the server and attacker possess the keys. 302 Client <-|Rogue NAS | NAS Auth Server 303 | Attacker |-> 304 | | | | 305 | | | | 306 | | Tunnel establishment w/ | 307 | | Server Authentication (1) | 308 | |<========================================>| 309 | | | | 310 | (Non-Authenticated | (Authenticated 311 | end of tunnel) | end of tunnel) 312 | | | | 313 | +--------------+ | +--------------+ 314 | | Tunnel | (2) | | Tunnel | 315 | | Keys Derived | | | Keys Derived | 316 | +--------------+ | +--------------+ 317 | | | | 318 | |..........................................| 319 | | Tunnel | 320 | |..........................................| 321 | | (Encrypted using Tunnel keys) | 322 | | | | 323 | | | | 324 | Tunneled authentication method (3) | 325 |<==============================================================>| 326 | | | | 327 | | | | 328 +--------------+ | | +--------------+ 329 | Method | | | | Method | 330 | Keys Derived | (4) | | | Keys Derived | 331 | and used. | | | | Not Used. | 332 +--------------+ | | +--------------+ 333 | | | | 334 | | |<===tunnel keys=========| 335 | | | | 336 | | Client's session| | 337 | | stolen | | 338 |====================+|<===============>| | 339 | Data || | | 340 | dropped v| | | 342 Figure 1 - Man-in-the-middle attack on a one-way authenticated tunnel 343 In the third step, the client connects to the rogue NAS or AP, and the 344 attacker tunnels the authentication method between the client and 345 server. The tunneled authentication method may or may not derive keys, 346 but if it does, then in the fourth step, the method keys are derived on 347 the client and the server. Since the attacker does not obtain the 348 method keys, it is not able to decrypt traffic sent between client and 349 server. However, while the client may use the method keys, the server 350 will typically use only tunnel keys, which have been obtained by the 351 attacker. 353 In the last step, the attacker obtains access to the server, using the 354 successfully tunneled authentication and the tunnel keys. The attacker 355 does not have access to client data, since it is encrypted with the 356 method keys. As a result, it will typically discard the data sent by the 357 client, who will eventually disconnect due to a lack of response. Since 358 the attacker has accomplished its mission, continued interaction with 359 the client is not necessary unless reauthentication is required. 361 4. Potential solutions 363 This section describes potential solutions to the man-in-the-middle 364 attacks prevously described. This includes a discussion of solution 365 requirements as well as identification of potential solution approaches. 367 4.1. Solution Requirements 369 The following are some of the criteria for a potential solution: 371 Backwards compatibility 372 A solution MUST NOT require modification of existing 373 authentication methods. Since tunneling is used in order 374 to prolong the life of legacy authentication techniques, 375 requiring replacement of existing methods across the 376 board is likely to be unacceptable. 378 Simplicity A solution SHOULD add minimal round trips to the 379 authentication exchange and be modest in its 380 computational complexity. 382 Protocol compatibility 383 Given that tunneling techniques are used with well- 384 established security protocols such as IKE [RFC2409], 385 ISAKMP [RFC2408], TLS [RFC2246], and RADIUS [RFC2865], a 386 solution MUST NOT require changes to these protocols. 388 Forward evolution 389 The solution SHOULD be compatible with authentication 390 methods supporting mutual authentication and key 391 derivation. It is acceptable if the solution cannot 392 provide security for tunneling of one-way authentication 393 methods that do not derive keys, such as CHAP, EAP-MD5, 394 OTP, Generic Token Card, or SecurID. As described 395 earlier, these methods are already vulnerable to 396 connection hijacking. 398 Architectural compatibility 399 Solutions MUST NOT require fundamental architectural 400 changes to established technologies such as network 401 access authentication. Since these technologies are 402 already widely deployed, such changes would be likely to 403 be unacceptable. 405 Tunneling protocol independence 406 While a solution MAY introduce changes to tunneling 407 protocols such as [PIC], [PANATLS], [EAPTTLS], or [PEAP], 408 it is preferable that a single solution be applicable to 409 all of these protocols. This is desirable since a single 410 solution will be easiest deploy and also enables the 411 security community to focus efforts on determining 412 whether the proposal is secure. 414 4.2. Solution mechanisms 416 Several mechanisms are available to solving the problem: 418 [1] Compound MACs. This solution uses Message Authentication Codes 419 (MACs) computed using keying material from each of the 420 authentication methods within a final mutual authenticating round- 421 trip. In order to make sure that both sides are aware of the 422 outcome of the authentication, the compound MAC MUST include 423 coverage of the authentication result (success/failure) sent by 424 each side. This ensures that the server cannot be tricked into 425 using the tunnel key (in the attacker's posession) to authenticate 426 and encrypt data. 428 [2] Compound keys. This solution combines keying material from all the 429 methods in order to derive keys used for subsequent encryption and 430 authentication of data. 432 Option 1 prevents a man-in-the-middle from gaining authenticated access, 433 and therefore prevents false authenticated states which could result in 434 a Denial of Service attack (possible in Option 2). This makes this 435 approach relatively straightforward to implement, although it does 436 require an additional round-trip. While it is believed that this 437 approach may be sufficient in some cases, further study is required in 438 order confirm this. 440 Option 2 does not require additional round trips, but it enables the 441 man-in-the-middle to authenticate, although not to obtain keys used for 442 subsequent authentication and encryption of data. This implies that the 443 client will only discover an attack when it discovers that it is unable 444 to decipher the incoming data stream. This enables a form of Denial of 445 Service attack and as a result, Option 2 is probably not sufficient by 446 itself. 448 In order to provide the highest level of assurance against man-in-the- 449 middle attacks, it is recommended that a potential solution utilize both 450 options 1 and 2. This prevents a man-in-the-middle from being able to 451 authenticate, spoof an authentication result or derive keys used to 452 authenticate and encrypt traffic between the legitimate client and 453 server. When both solution options are applied, potential man-in-the- 454 middle attacks are thwarted, as shown in Figure 2 on the next page. 456 As before, the man-in-the-middle can establish a one-way authenticated 457 tunnel, obtain tunnel keys, lure an unsuspecting client to authenticate 458 with it, and encapsulate the authentication exchange within the tunnel. 459 However, after the authentication method is complete, compound keys are 460 derived, requiring knowledge of both the tunnel keys and the keys 461 derived during each of the authentication methods. The compound keys are 462 then used in formulation of a compound MAC covering the authentication 463 result, which is sent from server to client. Since the server is not 464 aware of the man-in-the-middle attack in progress, from its perspective 465 the authentication has been successful. 467 Since the client did not participate in establishment of the tunnel, it 468 does not possess the tunnel keys, and cannot verify the compound MAC 469 sent by the server. The client computes its own compound key and 470 compound MAC, covering an indicated authenticate failure. On receiving 471 the client's reply, the server is unable to verify the client's compound 472 MAC, and the authentication fails. As a result, no compound keys are 473 sent to the NAS, and the attacker is neither authenticated nor gains 474 access to the server. 476 Client <-|Rogue NAS | NAS Auth Server 477 | Attacker |-> 478 | | | | 479 | | | | 480 | | Tunnel establishment w/ | 481 | | Server Authentication (1) | 482 | |<========================================>| 483 | | | | 484 | (Non-Authenticated | (Authenticated 485 | end of tunnel) | end of tunnel) 486 | | | | 487 | +--------------+ | +--------------+ 488 | | Tunnel | (2) | | Tunnel | 489 | | Keys Derived | | | Keys Derived | 490 | +--------------+ | +--------------+ 491 | | | | 492 | |..........................................| 493 | | Tunnel | 494 | |..........................................| 495 | | (Encrypted using Tunnel keys) | 496 | | | | 497 | | | | 498 | Tunneled mutual authentication method (3) | 499 | | w/key derivation| | 500 |<==============================================================>| 501 | | | | 502 | | | | 503 +--------------+ | | +--------------+ 504 | Compound | | | | Compound | 505 | Keys Derived | (4) | | | Keys Derived | 506 +--------------+ | | +--------------+ 507 | | | | 508 | | Compound MAC(5)/| | 509 | | Success | | 510 |<===============================================================| 511 | | | | 512 | | Compound MAC(6)/| | 513 | | Failure | | 514 |===============================================================>| 515 | | | | 516 | | | Attack detected | 517 | | | No keys sent | 518 | | | | 519 | | | Failure | 520 | | | <======================| 521 | | | | 523 Figure 2 - Man-in-the-middle attack thwarted by compound MAC and compound keys 524 4.3. Solution approaches 526 Options 1 or 2 can be implemented in different ways: 528 EAP In this approach, the exchange of a compound MAC is supported 529 within EAP, by implementing the exchange as a new EAP method 530 occuring after authentication is complete. Tunnel keys are 531 provided by the tunneling protocol to the EAP layer in order 532 to enable computation of the compound MAC and compound keys. 533 Since existing EAP implementations already enable EAP methods 534 to provide keying material to the EAP layer, such an interface 535 typically already exists. This approach is general in that it 536 ppplies to any tunneling technique. 538 Tunneling method 539 In this approach, the tunneling method acquires keying 540 material derived by the underlying authentication methods, in 541 order to enable computation of the compound MAC and compound 542 keys. Since existing tunneling techniques typically do not 543 provide an interface for receiving keying material from 544 authentication methods, this approach will typically require 545 some re-architecture of existing implementations. It also has 546 the disadvantage of requiring changes to each tunneling 547 method, and as a result is not as general as an EAP-based 548 solution. Given the prevalence of the attacks described within 549 this document, it would represent a considerable burden on the 550 security community to review changes to each individual 551 tunneling approach. However, such an approach may be able to 552 take advantage of properties of the underlying tunnel 553 technology, such as the ability to have more than one packet 554 in transit at a time. 556 EAP methods 557 In this approach, keys derived from previous EAP methods are 558 incorporated into the authentication calculations of 559 subsequent methods. Since existing interfaces only support the 560 export of keys by EAP methods, not importation, some 561 rearchitecture is required in this approach. In addition, this 562 approach requires modification of existing EAP methods, which 563 will create deployment barriers. However, this approach may 564 be applied even to methods which support only one-way 565 authentication and do not generate keys. 567 Based on the pros and cons of each approach, we recommend a solution 568 that applies to all EAP methods. 570 4.4. Solution scope 572 Since EAP is supported within [PIC], [PANATLS], [EAPTTLS] and [PEAP], 573 though not within [XAUTH], implementation of options 1 and 2 within EAP 574 covers most of the vulnerable protocols. There are some exceptions, 575 however. 577 [1] Methods that do not generate keys. In order to verify that the 578 peers acted as end-points in a compound authentication, the peers 579 can exchange compound MACs and compute compound keys. However, 580 authentication schemes which do not derive keys cannot contribute 581 to calculation of a compound MAC or a compound key. Such 582 mechanisms include popular one-way authentication mechanisms such 583 as CHAP [RFC1994], EAP-MD5 [RFC2284], One-Time-Password [RFC1938], 584 Generic Token Card [RFC2284], and [SECURID]. These mechanisms 585 authenticate the client to the server, but do not authenticate the 586 server to the client. They also do not derive keys which can be 587 used in constructing compound MACs and compound keys or providing 588 keying material for authentication and/or encryption of a 589 subsequent data stream. 591 Without requiring changes to existing methods, secure use of these 592 protocols within sequences or tunnels is not feasible. If an 593 authentication method does not generate keys, then keying material 594 is not available with which to compute a compound MAC or compound 595 key. As a result, the compound authentication sequence cannot be 596 bound together, enabling the man-in-the-middle vulnerability to 597 remain. One workaround is to prohibit use of these methods outside 598 a tunnel; there is some logic to this, since without support for 599 key generation, use of these methods outside the tunnel is 600 vulnerable to connection hijacking. 602 [2] Ciphers without authentication support. Where per-packet 603 authentication and integrity protection is not supported, there is 604 no binding between the results of the authentication and subsequent 605 data traffic. This enables connection hijacking. 607 In order to enable a solution for methods such as CHAP, EAP-MD5, OTP, 608 GTC or SECURID, they may be modified so as to enable key derivation, or 609 to incorporate key material derived during the initial tunnel 610 authentication. However, since the motivation for continued use of 611 legacy technologies is to minimize the deployment of new technology, 612 such upgrades are typically impractical. In situations where deployment 613 of a modified legacy method would be feasible, it would also typically 614 be feasible to consider a wide range of alternatives, such as deployment 615 of a new method supporting mutual authentication and key derivation, or 616 deployment of alternative technologies such as certificates. 618 Given these constraints, it appears difficult for authentication 619 tunneling to provide a long-term solution to the security 620 vulnerabilities inherent in one-way authentication methods such as CHAP, 621 EAP-MD5, OTP, GTC and SecurID. Where protocols such as [PIC] are used to 622 transition from these technologies to certificate-based authentication, 623 it may be possible to restrict the transition to a short time period, as 624 well as to turn off use of the techniques outside of [PIC]. 626 These counter-measures may reduce the risk sufficiently to enable 627 certificate deployment to proceed. However, where [PIC] is used to 628 provide short- term certificates, and long-term use of password or 629 token-card based authentication technology is contemplated, improved 630 security will not be possible without a willingness to replace legacy 631 authentication methods with more secure technology. 633 If a transition to certificate-based authentication is not possible, 634 then at the least, one-way authentication technology can be replaced by 635 techniques supporting mutual authentication and key derivation. For 636 example, CHAP may be replaced by Kerberos [RFC1510] or MS-CHAP-V2 637 [RFC2759] and Generic Token Card may be replaced by token cards 638 supporting key derivation. 640 5. Normative references 642 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 643 RFC 1661, July 1994. 645 [RFC1938] Haller, N. and C. Metz, "A One-Time Password System", RFC 646 1938, May 1996. 648 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 649 Protocol (CHAP)", RFC 1994, August 1996. 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", RFC 2119, March 1997.] 654 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 655 Protocol (EAP)", RFC 2284, March 1998. 657 [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., 658 "Remote Authentication Dial In User Service (RADIUS)", 659 RFC 2865, June 2000. 661 [RFC3193] Patel, B., et al., "Securing L2TP Using IPsec", RFC 3193, 662 November 2001. 664 [EAPTTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS 665 Authentication Protocol", Internet draft (work in 666 progress), February 2002. 668 [DHCPIpsec] Patel, B., et al., "DHCPv4 Configuration of IPsec Tunnel 669 Mode", Internet draft (work in progress), draft-ietf- 670 ipsec-dhcp-13.txt, June 2001. 672 [PEAP] Andersson, H., et al., "Protected EAP Protocol (PEAP)", 673 Internet draft (work in progress), draft-josefsson- 674 pppext-eap-tls-eap-05.txt, September 2002. 676 [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE 677 Credential Provisioning Protocol", Internet draft (work 678 in progress), draft-ietf-ipsra-pic-06.txt, September 679 2002. 681 [IPSRAREQ] Kelly, S., Ramamoorthi, S., "Requirements for IPsec 682 Remote Access Scenarios", Internet draft (work in 683 progress), draft-ietf-ipsra- reqmts-05.txt, September 684 2002. 686 [GETCERT] Bellovin, S., and Moskowitz, B., "Client Certificate and 687 Key Retrieval for IKE", Internet draft (work in 688 progress), draft-bellovin-ipsra-getcert-00.txt, June 689 2000. 691 [SECURID] Josefsson, S., "The EAP SecurID(r) Mechanism", Internet 692 draft (work in progress), draft-josefsson-eap- 693 securid-01.txt, February 2002. 695 [PANATLS] Ohba, Y., et al., "PANA over TLS", Internet draft (work 696 in progress), draft-ohba-pana-potls-00.txt, September 697 2002. 699 [XAUTH] Pereira, R., Beaulieu, S., "Extended Authentication 700 within ISAKMP/Oakley", Internet-draft (work in progress), 701 draft-beaulieu-ike-xauth-02.txt, September, 2000. 703 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 704 Overview and Architecture, ANSI/IEEE Std 802, 1990. 706 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 707 Port based Network Access Control, IEEE Std 802.1X-2001, 708 June 2001. 710 [IEEE80211] Information technology - Telecommunications and 711 information exchange between systems - Local and 712 metropolitan area networks - Specific Requirements Part 713 11: Wireless LAN Medium Access Control (MAC) and 714 Physical Layer (PHY) Specifications, IEEE Std. 715 802.11-1997, 1997. 717 6. Informative references 719 [RFC1510] Kohl, J., Neuman, C., "The Kerberos Network 720 Authentication Service (V5)", RFC 1510, September 1993. 722 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 723 RFC 2246, November 1998. 725 [RFC2486] Beadles, M., Aboba, B., "The Network Access Identifier", 726 RFC 2486, January 1999. 728 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the 729 Internet Protocol", RFC 2401, November 1998. 731 [RFC2402] Kent,S., Atkinson, R., "IP Authentication Header", RFC 732 2402, November 1998. 734 [RFC2406] Kent,S., Atkinson, R., "IP Encapsulating Security Payload 735 (ESP)", RFC 2406, November 1998. 737 [RFC2407] Piper, D., "The Internet IP Security Domain of 738 Interpretation of ISAKMP", RFC 2407, November 1998. 740 [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and Turner, 741 J., "Internet Security Association and Key Management 742 Protocol (ISAKMP)", RFC 2408, November 1998. 744 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 745 (IKE)", RFC 2409, November 1998. 747 [RFC2412] Orman, H., "The Oakley Key Determination Protocol", RFC 748 2412, Nov. 1998. 750 [RFC2433] Zorn, G., Cobb, S., "Microsoft PPP CHAP Extensions", RFC 751 2433, October 1998. 753 [RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol 754 (PPTP)", RFC 2637, July 1999. 756 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 757 G., and Palter, B., "Layer Two Tunneling Protocol L2TP", 758 RFC 2661, August 1999. 760 [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication 761 Protocol", RFC 2716, October 1999. 763 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 764 2759, January 2000. 766 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 768 [DECEPTION] Slatalla, M., and Quittner, J., "Masters of Deception." 769 HarperCollins, New York, 1995. 771 [KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos Password 772 Security", Stanford University Computer Science 773 Department, http://theory.stanford.edu/~tjw/krbpass.html 775 [KRBLIM] Bellovin, S.M., Merritt, M., "Limitations of the kerberos 776 authentication system", Proceedings of the 1991 Winter 777 USENIX Conference, pp. 253-267, 1991. 779 [KERB4WEAK] Dole, B., Lodin, S., and Spafford, E., "Misplaced trust: 780 Kerberos 4 session keys", Proceedings of the Internet 781 Society Network and Distributed System Security 782 Symposium, pp. 60-70, March 1997. 784 [PPTPv1] Schneier, B, Mudge, "Cryptanalysis of Microsoft's Point- 785 to- Point Tunneling Protocol", Proceedings of the 5th ACM 786 Conference on Communications and Computer Security, ACM 787 Press, November 1998. 789 [IEEE8023] ISO/IEC 8802-3 Information technology - 790 Telecommunications and information exchange between 791 systems - Local and metropolitan area networks - Common 792 specifications - Part 3: Carrier Sense Multiple Access 793 with Collision Detection (CSMA/CD) Access Method and 794 Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 795 1996), 1996. 797 Acknowledgments 799 Thanks to Bernard Aboba for editorial assistance and discussions 800 relevant to this problem space. 802 Authors' Addresses 804 Jose Puthenkulam 805 Intel Corporation 806 2111 NE 25th Avenue, JF2-58 807 Hillsboro, OR 97124 809 EMail: jose.p.puthenkulam@intel.com 810 Phone: +1 503 264 6121 811 Fax: +1 503 264 8154 813 Victor Lortz 814 Intel Corporation 815 2111 NE 25th Avenue, JF3-206 816 Hillsboro, OR 97124 818 EMail: viktor.lortz@intel.com 819 Phone: +1 503 264 3253 820 Fax: +1 503 626 0396 822 Ashwin Palekar 823 Dan Simon 824 Bernard Aboba 825 Microsoft Corporation 826 One Microsoft Way 827 Redmond, WA 98052 829 EMail: {ashwinp, dansimon, bernarda}@microsoft.com 830 Phone: +1 425 882 8080 831 Fax: +1 425 936 7329 833 Full Copyright Statement 835 Copyright (C) The Internet Society (2002). All Rights Reserved. 836 This document and translations of it may be copied and furnished to 837 others, and derivative works that comment on or otherwise explain it or 838 assist in its implementation may be prepared, copied, published and 839 distributed, in whole or in part, without restriction of any kind, 840 provided that the above copyright notice and this paragraph are included 841 on all such copies and derivative works. However, this document itself 842 may not be modified in any way, such as by removing the copyright notice 843 or references to the Internet Society or other Internet organizations, 844 except as needed for the purpose of developing Internet standards in 845 which case the procedures for copyrights defined in the Internet 846 Standards process must be followed, or as required to translate it into 847 languages other than English. The limited permissions granted above are 848 perpetual and will not be revoked by the Internet Society or its 849 successors or assigns. This document and the information contained 850 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 851 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 852 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 853 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 854 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 855 EAP Issues 857 Open issues relating to EAP, including the issues described in this 858 document, are tracked on the following web site: 860 http://www.drizzle.com/~aboba/EAP/eapissues.html 862 Expiration Date 864 This memo is filed as , and 865 expires April 24, 2003.