idnits 2.17.1 draft-puthenkulam-eap-binding-04.txt: -(702): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 15) being 77 lines == It seems as if not all pages are separated by form feeds - found 35 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 62 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 236 has weird spacing: '...service verif...' == Line 468 has weird spacing: '...ication metho...' == Line 798 has weird spacing: '...tential man-i...' == Line 947 has weird spacing: '...P-based solut...' -- 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: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'IPSEC' is mentioned on line 95, but not defined == Missing Reference: 'EAPMSCHAPV2' is mentioned on line 109, but not defined -- Looks like a reference, but probably isn't: '1' on line 1126 -- Looks like a reference, but probably isn't: '2' on line 1138 -- Looks like a reference, but probably isn't: '3' on line 1143 -- Looks like a reference, but probably isn't: '4' on line 1150 == Missing Reference: 'RFC1993' is mentioned on line 290, but not defined == Missing Reference: 'RFC 2409' is mentioned on line 341, but not defined ** Obsolete undefined reference: RFC 2409 (Obsoleted by RFC 4306) == Missing Reference: 'RFC 2246' is mentioned on line 342, but not defined ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346) == Missing Reference: 'DHCPIPsec' is mentioned on line 348, but not defined == Missing Reference: 'CC-A' is mentioned on line 499, but not defined == Missing Reference: 'CC-B' is mentioned on line 510, but not defined == Missing Reference: 'CC-C' is mentioned on line 520, but not defined == Missing Reference: 'CC-D' is mentioned on line 529, but not defined == Missing Reference: 'S1' is mentioned on line 626, but not defined == Missing Reference: 'S2' is mentioned on line 602, but not defined == Missing Reference: 'S3' is mentioned on line 613, but not defined == Missing Reference: 'S4' is mentioned on line 622, but not defined == Missing Reference: 'S5' is mentioned on line 631, but not defined == Missing Reference: 'Stage 1' is mentioned on line 699, but not defined == Missing Reference: 'Stage 2' is mentioned on line 834, but not defined == Missing Reference: 'RFC2284bis' is mentioned on line 1231, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) == Unused Reference: 'EAP-MD5' is defined on line 1421, but no explicit reference was found in the text == Unused Reference: 'ISAKMP' is defined on line 1423, but no explicit reference was found in the text == Unused Reference: 'IKE' is defined on line 1425, but no explicit reference was found in the text == Unused Reference: 'PEAPV0' is defined on line 1427, but no explicit reference was found in the text == Unused Reference: 'RFC1661' is defined on line 1431, but no explicit reference was found in the text == Unused Reference: 'RFC1938' is defined on line 1434, but no explicit reference was found in the text == Unused Reference: 'DHCPIpsec' is defined on line 1458, but no explicit reference was found in the text == Unused Reference: 'IPSRAREQ' is defined on line 1471, but no explicit reference was found in the text == Unused Reference: 'GETCERT' is defined on line 1476, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 1493, but no explicit reference was found in the text == Unused Reference: 'IEEE80211' is defined on line 1500, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 1509, but no explicit reference was found in the text == Unused Reference: 'RFC2486' is defined on line 1515, but no explicit reference was found in the text == Unused Reference: 'RFC2486bis' is defined on line 1518, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 1522, but no explicit reference was found in the text == Unused Reference: 'RFC2402' is defined on line 1525, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 1528, but no explicit reference was found in the text == Unused Reference: 'RFC2407' is defined on line 1531, but no explicit reference was found in the text == Unused Reference: 'RFC2412' is defined on line 1541, but no explicit reference was found in the text == Unused Reference: 'RFC2433' is defined on line 1545, but no explicit reference was found in the text == Unused Reference: 'RFC2716' is defined on line 1555, but no explicit reference was found in the text == Unused Reference: 'RFC2759' is defined on line 1558, but no explicit reference was found in the text == Unused Reference: 'RFC2866' is defined on line 1560, but no explicit reference was found in the text == Unused Reference: 'DECEPTION' is defined on line 1562, but no explicit reference was found in the text == Unused Reference: 'KRBATTACK' is defined on line 1565, but no explicit reference was found in the text == Unused Reference: 'KRBLIM' is defined on line 1569, but no explicit reference was found in the text == Unused Reference: 'KERB4WEAK' is defined on line 1573, but no explicit reference was found in the text == Unused Reference: 'PPTPv1' is defined on line 1578, but no explicit reference was found in the text == Unused Reference: 'IEEE8023' is defined on line 1583, but no explicit reference was found in the text == Unused Reference: 'MITM1' is defined on line 1596, but no explicit reference was found in the text == Unused Reference: 'IKEv2' is defined on line 1606, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2284 (ref. 'EAP-MD5') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 1938 (Obsoleted by RFC 2289) -- Duplicate reference: RFC2284, mentioned in 'RFC2284', was also mentioned in 'EAP-MD5'. ** 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-07 == 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) -- Duplicate reference: RFC2246, mentioned in 'RFC2246', was also mentioned in 'TLS'. -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Duplicate reference: RFC2486, mentioned in 'RFC2486bis', was also mentioned in 'RFC2486'. -- 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) -- Duplicate reference: RFC2408, mentioned in 'RFC2408', was also mentioned in 'ISAKMP'. -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Duplicate reference: RFC2409, mentioned in 'RFC2409', was also mentioned in 'IKE'. -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-05 Summary: 14 errors (**), 0 flaws (~~), 61 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EAP Working Group Jose Puthenkulam 2 INTERNET-DRAFT Victor Lortz 3 Category: Experimental Intel Corporation 4 Ashwin Palekar 5 Dan Simon 6 27 October 2003 Microsoft 8 The Compound Authentication Binding Problem 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2003). All Rights Reserved. 32 Abstract 34 There are several motivations for using compound authentication methods 35 using tunnels, but man-in-the-middle attacks have been found in these 36 protocols under certain circumstances. They occur when the inner 37 methods used inside a tunnel method are also used outside it, without 38 cryptographically binding the methods together. At the time of writing 39 this document, several protocols being proposed within the IETF were 40 vulnerable to these attacks, including IKE with XAUTH, PIC, PANA over 41 TLS, EAP TTLS and PEAP. This document studies the problems and suggests 42 potential solutions to mitigate them. We also provide a reference 43 solution for an EAP tunneling protocol like PEAP. 45 Table of Contents 47 1. Introduction .......................................... 3 49 1.1 Scope ........................................... 3 50 1.2 Motivations for Compound Methods ................ 4 51 1.3 Problem Statement ............................... 5 52 1.4 Requirements Language ........................... 5 53 1.5 Terminology ..................................... 6 55 2. Problem Description.................................... 7 57 2.1 Overview ........................................ 7 58 2.2 Attack Scenarios ................................ 9 59 2.3 Conditions for the attack........................ 12 61 3. Potential Solutions ................................... 12 63 3.1 Solution criteria ............................... 13 64 3.2 Solution concepts ............................... 14 65 3.3 Solution mechanisms ............................. 15 66 3.4 Thwarting the attack............................. 19 67 3.5 Solution approaches ............................. 21 68 3.6 Solution scope .................................. 22 70 4. Reference Solution in Tunneling Protocol............... 23 72 4.1 Binding Phase Precepts........................... 23 73 4.2 Binding Phase Handshake.......................... 23 74 4.3 Compound MAC and Session Key derivation.......... 26 75 4.4 Binding Message Formats ......................... 27 76 4.5 IANA Considerations.............................. 31 77 4.6 Security Considerations ......................... 31 79 5. Normative references .................................. 31 81 6. Informative references ................................ 33 83 Acknowledgements.............................................. 35 85 Author's Addresses ........................................... 35 87 Intellectual Property Statement .............................. 36 89 Full Copyright Statement ..................................... 37 90 1. Introduction 92 As authentication protocols evolved over time, weaker ones have 93 either been replaced or modified to meet the increasing security needs 94 in new environments. The development of secure tunneling techniques like 95 [TLS] and [IPSEC] have generated a lot of interest in securing legacy or 96 weaker authentication protocols using tunnels. We call such compositions 97 of multiple authentication protocols that are used in concert to 98 accomplish a specific purpose, Compound Authentication Methods. They may 99 be used for several purposes, including user authentication for granting 100 network access or establishing a security association for 101 confidentiality and integrity protection of data traffic. 103 We highlight certain man-in-the-middle vulnerabilities associated with 104 the composition of compound authentication methods that are being 105 proposed or already in use today. These include authentication methods 106 that are commonly encapsulated within an independently authenticated 107 tunnel that provides additional protective properties. Some examples of 108 compound authentication methods using tunnels include EAPMD5 using 109 [EAPTTLS], [EAPMSCHAPV2] using [PEAP], PANA over TLS [PANATLS], HTTP 110 authentication over TLS, [XAUTH] with ISAKMP as part of IKE, and secure 111 legacy authentication support for IKEv2 [SLA]. These may also include 112 multiple authentication methods used in sequence when multiple 113 credentials are used in different stages of authentication. 115 Editor's Note: Some of the above mentioned protocols and others 116 mentioned in this document have recently been or are being updated with 117 solutions for this problem. This document lays out the general 118 principles for arriving at such solutions. 120 1.1. Scope 122 This document identifies the man-in-the-middle attacks that are possible 123 when one-way authenticated tunnels are used to protect communications of 124 one or a sequence of authentication methods; and characterizes the 125 solution(s) that address the attack. The context studied is the use of 126 compound authentication for granting network access using a client and 127 authentication server setup. 129 Intuitively, certain attacks may also be possible with sequences of 130 authentication methods even if they are not used within tunnels, but we 131 do not address those scenarios here. This is because such authentication 132 sequences are open-ended and unless a protocol method defines the 133 security constructs of the sequence in totality, its difficult to 134 analyze the attack scenarios. Also at the time of writing, the authors 135 are not aware of such open-ended sequences with clearly defined 136 security constructs. 138 constructs. If they do exist further study may be needed to see if the 139 attacks we describe apply to them and also whether the solutions make 140 sense. 142 We study the root causes of the attack and develop solutions using a mix 143 of policy based and cryptographic means. We also describe a reference 144 solution as a logical extension to an EAP based tunneling protocol. 145 However the same principles could be used in other classes of 146 authentication protocols as well. 148 1.2. Motivations for Compound Methods using tunnels 150 They are the following: 152 [1] Support for legacy authentication methods in new environments: 154 These new environments have brought new requirements including identity 155 privacy, mutual authentication, authentication data confidentiality, 156 integrity protection, replay and dictionary attack protection and strong 157 cipher keys for the authenticated link, especially in the context of 158 wireless networks. Secure tunneling techniques like TLS and ISAKMP with 159 strong security properties provide a way to accomplish this in an 160 extensible manner, providing longer life for easy to use legacy methods. 162 ex: Using legacy PAP that has no key derivation in 802.11 WLANs, by 163 running it inside an EAP-TTLS tunnel that provides the additional 164 protection needed. 166 [2] Consistent security properties for authentication methods: 168 Any time a new credential type is introduced, it becomes necessary to 169 construct a complete cryptographic protocol with all the necessary 170 security properties, which is not an easy task to accomplish. The 171 availability of well-reviewed tunneling protocols like TLS and ISAKMP 172 provide the opportunity to construct simpler methods for new credentials 173 that can use the protection of the tunnel to do authentication securely. 174 On a wireless network supporting multiple authentication methods, this 175 enables consistent security for all credential types. This is possible 176 because these protocols allow cipher suites to be selected and 177 configured independent of the authentication methods used inside. 179 ex: EAP-SIM running inside a PEAP tunnel that uses a TLS tunnel for 180 privacy protection. 182 [3] Support for Multiple credentials 184 New system capabilities in certain cases require authentication of more 185 than one credential between two peers. This sometimes requires 186 authentication methods with different security properties to be 187 sequenced. By running the sequence inside a tunnel, it enables providing 188 a protection layer for all the methods. 190 [4] Deployment aspects for securing legacy methods: 192 The ease of deployment of secure tunneling techniques using server 193 authentication alone as in TLS and also IPSec (though they allow 194 mutual authentication), making them even more popular candidates for 195 securing the use of legacy authentication methods. 197 ex: The TLS tunnel in PEAP can be established with server authentication 198 using a server certificate. No client certificates that are unique per 199 user are required. 201 1.3. Problem Statement 203 This document suggests that compound methods have evolved from need, 204 but their composition today as it is practiced, has some 205 man-in-the-middle vulnerabilities in certain circumstances. These 206 were not known at the time these compositions were suggested but have 207 been found recently [MITM]. As compound methods have widespread 208 application, this document studies the problem, its circumstances and 209 and suggests solutions for mitigating them using a mix of protocol 210 extensions and policy based techniques. 212 1.4. Requirements language 214 In this document, several words are used to signify the requirements of 215 the specification. These words are often capitalized. The key words 216 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 217 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 218 interpreted as described in [RFC2119]. 220 1.5. Terminology 222 This document frequently uses the following terms: 224 Authenticator 225 The end of the link initiating authentication. In IEEE 802.1X 226 the term authenticator is defined and it has the same meaning 227 here. It is also referred to as a NAS (Network Access Server). 229 Peer The end of the link, which is being authenticated by the 230 Authenticator. In IEEE 802.1X, this end is known as the 231 Supplicant. We also sometimes refer to the Peer as a Client 232 of the Authentication Server. 234 Authentication Server 235 It is an entity that provides an Authentication Service to an 236 Authenticator. This service verifies from the credentials 237 provided by the Peer, the claim of identity made by the Peer. 238 It is also referred to as the backend authentication server. 240 Legacy Authentication Methods 241 These are mostly one-way authentication methods widely used 242 today that are either based on passwords or secure tokens or 243 challenge-response methods that have no key derivation, 244 no message authenticity or integrity protection, no identity 245 privacy protection, use weak algorithms and are vulnerable to 246 many well known attacks. 247 ex: PAP - Password Authentication Protocol 249 Legacy Credentials 250 Passwords are typically referred to as legacy credentials. 251 They may also include cases where the password is stored in 252 a secure token device and not known to the user. 254 Sequenced Methods 255 Authentication methods which are used in sequence one after 256 another where each one completes and the next one starts. The 257 authentication is complete after the final method in the 258 sequence is completed. 260 Tunneled Methods 261 The first method sets up a tunnel and subsequent method(s) run 262 within the tunnel. 264 Binding Phase 265 The protocol stage where validation of the peers 266 participating in the compound authentication method is carried 267 out after all the methods have completed or one or more 268 successive individual methods have completed. 270 Compound MAC 271 A Message Authentication Code (MAC) computed using keying 272 material from multiple methods used in a compound 273 authentication method. This is computed during the binding 274 phase. 276 Compound Keys 277 Session keys computed using keying material from multiple 278 methods used in a compound authentication method. This is 279 computed during the binding phase and can be used for 280 ciphering at the lower layers or as application specific keys. 282 2. Problem Description 284 2.1. Overview 286 The attack described in this document can be mounted against a number 287 of proposed IETF protocols, including IKE with [XAUTH], [PIC], 288 [PANATLS], [SLA], [EAPTTLS], and [PEAP]. Each of these protocols 289 supports tunneling of legacy authentication methods such as CHAP 290 [RFC1994], EAP-MD5 [RFC2284], One-Time-Password (OTP) [RFC1993], 291 Generic Token Card (GTC) [RFC2284], and SecurID [SECURID] in order to 292 provide a number of benefits, including well-understood key derivation, 293 fast reconnect, mutual authentication, replay and dictionary attack 294 protection and privacy support. 296 The attack is enabled when compound authentication techniques are 297 used, allowing clients and servers to authenticate each other with one 298 or more methods encapsulated within an independently authenticated 299 tunnel. The simplest attacks occur when the tunnel is authenticated 300 only from the server to the client, and where tunneled authentication 301 techniques are permitted both inside and outside a tunnel using the 302 same credential. The tunnel client, having not proved its identity, 303 can act as a man-in-the-middle, luring unsuspecting clients to 304 authenticate to it, using any authentication method suitable for use 305 inside the tunnel. The attacks are possible even though the tunnels 306 created within these protocols utilize well-analyzed protocols such as 307 ISAKMP [RFC2408] and TLS [RFC2246], because mutual authentication 308 (supported within both protocols) is not used. 310 Since the initial authentication only authenticates the server to the 311 client, or provides only an indication of group membership (where group 312 pre-shared keys are used within IKE), and because the keys derived 313 within ISAKMP and TLS are not subsequently included within the tunneled 314 authentication methods, there is no demonstration that the ISAKMP/TLS 315 endpoints are the same as the tunneled authentication endpoints. 317 Where authentication techniques are enabled both inside and outside the 318 tunnel, such as when they are in use for multiple purposes (e.g. dialup 319 or web authentication) then an attacker can induce an unsuspecting 320 client to authenticate, then tunnel the authentication within [XAUTH], 321 [PIC],[PANATLS],[EAPTTLS] or [PEAP]. 323 For the purposes of the attack, it makes no difference whether the 324 authentication method used inside the tunnel supports mutual 325 authentication or not. The vulnerability exists as long as both sides 326 are not required to demonstrate participation in the previous "tunnel 327 authentication" as well as subsequent authentications, and as long as 328 keys derived during the exchange are not dependent on material from 329 *all* of the authentications. 331 Thus it is the lack of client authentication within the initial security 332 association, combined with key derivation based on a one-way tunnel 333 authentication, and lack of "cryptographic binding" between the security 334 association and the tunneled inner authentication method that enables 335 the vulnerability. In addition, it is necessary for the same 336 authentication credentials to be used inside and outside of tunnels. 338 Despite the prevalence of man-in-the-middle vulnerabilities within 339 these compound authentication protocol proposals, it should be 340 noted that these vulnerabilities do not imply any design flaw in 341 (a) either in the tunnel creation protocols (such as IKE [RFC 2409] or 342 TLS [RFC 2246]), or (b) in some cases the authentication methods 343 themselves (such as EAP-AKA or EAP-MSCHAPv2). 345 IPsec VPN implementations which require strong mutual authentication 346 within the tunnel prior to permitting subsequent authentication are not 347 vulnerable to this attack. For example, when L2TP over IPsec [RFC3193], 348 or IPsec tunnel mode [DHCPIPsec], is used with certificate 349 authentication or unique pre-shared keys, the attack is not possible. By 350 requiring strong mutual authentication via certificates or a unique pre- 351 shared key, the tunnel server obtains the ability to verify the identity 352 of the tunnel client. The tunnel server may then subsequently apply 353 access control in order to limit authentication within the established 354 tunnel. 356 However, where group pre-shared keys are used (as is common in IKE Main 357 Mode implementations that support clients with dynamically allocated IP 358 addresses), followed by one-way authentication mechanisms such as CHAP 359 [RFC1994], the vulnerability is exposed. Since group pre-shared keys 360 only determine group membership but authenticate neither the client nor 361 the server, it is not possible for the server to enforce access controls 362 on individual members of the group. Since CHAP is a widely used 363 authentication method, an attacker can easily gain access to a client 364 willing to engage in CHAP authentication. This allows any client with 365 knowledge of the group pre-shared key to act as a man-in-the-middle for 366 another member of the group. 368 The concept of EAP tunneling has been introduced by recent work-in- 369 progress such as [PIC], [PANATLS], [EAPTTLS], and [PEAP]. However, these 370 proposals have not yet been published as RFCs, and are not yet widely 371 deployed. 373 Note that man-in-the-middle vulnerabilities are not a necessary 374 consequence of "credential reuse". For example, they need not 375 necessarily occur where the same authentication credentials are used in 376 accessing the network via multiple media. For example, L2TP [RFC2661], 377 when used in "compulsory tunneling", assumes that the same credentials 378 are used for both PPP and VPN access. PPP dialin users are then 379 permitted to access a VPN by tunneling PPP packets from the network 380 access server (NAS) to the VPN server. This is mainly because, on 381 physically secure networks, unlike wireless networks, its harder to 382 become a man-in-the-middle. 384 2.2. Attack scenario 386 This section describes how man-in-the-middle vulnerabilities can be 387 exploited, as well as discussing the underlying causes of the attacks. 388 We use a single example to highlight the problem. But the weakness of 389 the composition of tunnel-based compound authentication methods should 390 become apparent even in a broader context using this example. 392 The major scenario for the attack is a one-way authenticated tunnel 393 encapsulating subsequent authentication methods. In this scenario, the 394 client and server first establish a tunnel, then include within the 395 tunnel one or more authentication method(s). The attacker first poses 396 as a valid client to the server and establishes a tunnel that is 397 authenticated only on the server end, obtaining tunnel keys. Since 398 these keys protect a conversation between an attacker and a server, the 399 strength of the key derivation is not relevant. For the purposes of 400 exploiting the vulnerability, the tunneling protocol can be any protocol 401 that does not provide mutual authentication. 403 Once the attacker has established a tunnel to the server, it seeks to 404 induce clients to connect to it. This can be accomplished by having the 405 attacker masquerade as a legitimate 802.11 access point (AP) or Ethernet 406 switch implementing [IEEE8021X], a PPP Network Access Server (NAS), a 407 SIP server supporting CHAP, or a VPN server using a protocol such as 409 Client <-|Rogue NAS | NAS Auth Server 410 | Attacker |-> 411 | | | | 412 | | | | 413 | | Tunnel establishment w/ | 414 | | Server Authentication (1)| 415 | |<================================>| 416 | | | | 417 | (Non-Authenticated | (Authenticated 418 | end of tunnel) | end of tunnel) 419 | | | | 420 | +--------------+ | +--------------+ 421 | | Tunnel | (2) | | Tunnel | 422 | | Keys Derived | | | Keys Derived | 423 | +--------------+ | +--------------+ 424 | | | | 425 | |..................................| 426 | | Tunnel | 427 | |..................................| 428 | | (Encrypted using Tunnel keys) | 429 | | | | 430 | | | | 431 | Tunneled authentication method (3) | 432 |<======================================================>| 433 | | | | 434 | | | | 435 +--------------+ | | +--------------+ 436 | Method | | | | Method | 437 | Keys Derived | (4) | | | Keys Derived | 438 | And used. | | | | Not Used. | 439 +--------------+ | | +--------------+ 440 | | | | 441 | | |<==tunnel keys==| 442 | | | | 443 | | Client's session| | 444 | | stolen | | 445 |====================+|<===============>| | 446 | Data || | | 447 | dropped v| | | 449 Figure 1 - Man-in-the-middle attack on a one-way authenticated tunnel 450 PPTP [RFC2637]. For the purposes of the attack, it is necessary that 451 the client be induced to authenticate to the attacker using an 452 authentication mechanism permitted within the tunnel. It is also 453 necessary that the credentials within the client protocol and the 454 tunneled authentication protocol be the same, so that the 455 authentication mechanism remains valid when encapsulated within the 456 tunnel. 458 Figure 1 illustrates the attack, for the case where the attacker acts as 459 a rogue NAS or Access Point. In step 1, the attacker creates a tunnel 460 with the authentication server. This can occur directly in [PIC] or 461 [XAUTH] or through a NAS using EAP [RFC2284]. In step 2, tunnel keys are 462 derived, using server-only authentication via protocols 463 such as ISAKMP [RFC2408], IKE [RFC2409] with group pre-shared keys or 464 TLS [RFC2246]. Since the tunnel is between the attacker and the server, 465 both the server and attacker possess the keys. 467 In the third step, the client connects to the rogue NAS or AP, and the 468 attacker tunnels the authentication method between the client and 469 server. The tunneled authentication method may or may not derive keys, 470 but if it does, then in the fourth step, the method keys are derived on 471 the client and the server. Since the attacker does not obtain the 472 method keys, it is not able to decrypt traffic sent between client and 473 server. However, while the client may use the method keys, the server 474 will typically use only tunnel keys, which have been obtained by the 475 attacker. 477 In the last step, the attacker obtains access to the server, using the 478 successfully tunneled authentication and the tunnel keys. The attacker 479 does not have access to client data, since it is encrypted with the 480 method keys. As a result, it will typically discard the data sent by the 481 client, who will eventually disconnect due to a lack of response. Since 482 the attacker has accomplished its mission, continued interaction with 483 the client is not necessary unless reauthentication is required. 485 The attack described is also possible, if the tunnel server is not the 486 final authentication server. Now in that case the vulnerability is even 487 more serious because the inner method could be running to an untrusted 488 network, and it assumes, that the tunnel server and the final 489 authentication server have a trust relationship which it cannot validate. EAPTTLS typically suggests this model and care must be taken 490 while deploying this intermediate tunnel termination model to prevent 491 such man-in-the-middle attacks. 493 2.3. Conditions for the Attack 495 The following are some causal conditions that are necessary for this 496 attack to be possible. We label these conditions using a prefix CC 497 and refer to them during the solution description. 499 [CC-A] Client and Authentication server policy allowing client 500 credentials to be used both within one-way server-authenticated tunnels 501 and outside them. 503 ex: An authentication server supports EAP-MD5 using EAP-TTLS and also 504 supports the same method with the same credentials when used without 505 EAP-TTLS. This can occur when clients are being upgraded at different 506 times or when upgrades are not universal. If the identities used were 507 different in each case, then the server would be able to detect 508 fraudulent use and prevent the attack. 510 [CC-B] The ability for a man-in-the-middle to pose as a legitimate 511 client to the authentication server as well as a legitimate 512 authenticator to the client and perform both functions simultaneously. 514 ex: A 802.11 WLAN client that also has the capabilities to function as 515 an AP and functions as one entity with malicious intent. This is 516 relatively easy to accomplish given the low cost of equipment and tools. 517 This may be relatively more difficult to accomplish on dial-up RAS 518 servers. 520 [CC-C] The inability of the authentication server to validate that the 521 client authentication occurring inside a tunnel originated at the 522 same endpoint as the tunnel itself. 524 ex: When an EAP method runs inside of EAP-TTLS or PEAP, the tunnel 525 endpoint that is not authenticated really does not prove that it 526 originated the inner EAP conversation as link is protected only by the 527 tunnel keys. 529 [CC-D] The data link being authenticated is always confidentiality- 530 and/or integrity-protected using tunnel keys instead of the keys 531 derived from the client method running inside the tunnel. 533 ex: The keys from any EAP method running inside of EAP-TTLS or PEAP are 534 not used today. 536 3. Potential Solutions 538 This section describes potential solutions to the man-in-the-middle 539 attacks prevously described. This includes a discussion of solution 540 criteria, concepts, mechanisms, approaches and their scope. Some of the 541 limitations of these solutions are also captured. 543 3.1. Solution Criteria 545 The following are some criteria for a potential solution. 547 Backwards compatibility 548 A solution MUST NOT require modification of existing 549 authentication methods. Since tunneling is used in order 550 to prolong the life of legacy authentication techniques, 551 requiring replacement of existing methods across the 552 board is likely to be unacceptable. 554 Simplicity A solution SHOULD add minimal round trips to the 555 authentication exchange and be modest in its 556 computational cost. 558 Protocol compatibility 559 Given that tunneling techniques are used with well- 560 established security protocols such as IKE [RFC2409], 561 ISAKMP [RFC2408], TLS [RFC2246], and RADIUS [RFC2865], a 562 solution MUST NOT require changes to these protocols. 564 Forward evolution 565 The solution SHOULD be compatible with authentication 566 methods supporting mutual authentication and key 567 derivation. It is acceptable if the solution cannot 568 be uniformly applied for providing security for tunneling 569 of one-way authentication methods that do not derive 570 keys, such as CHAP, EAP-MD5,OTP, Generic Token Card, or 571 SecurID. As described earlier, these methods are already 572 vulnerable to connection hijacking. 574 Architectural compatibility 575 Solutions MUST NOT require fundamental architectural 576 changes to established technologies such as network 577 access authentication. Since these technologies are 578 already widely deployed, such changes would be likely to 579 be unacceptable. 581 3.2. Solution Concepts 583 There are several concepts at our disposal for mitigating this attack. 584 As the root problem was missing proof that both peers actually performed 585 all the individual methods in the compound authentication, one solution 586 is to provide just that. The other solutions include restrictions on the 587 implementation of the compound authentication methods so as to avoid 588 the causal conditions described in section 2.3 (CC-A...CC-D). 590 So here we list all the concepts and some of the limitations of each. 592 [S1] Provide proof that the unauthenticated tunnel endpoint is a real 593 peer and not the man-in-the-middle attacker using cryptographic 594 binding. This prevents condition CC-C. 596 This solution works for all key-deriving methods used inside a 597 tunnel. And this is the primary solution described in this 598 document. This will not work for non-key-deriving methods 599 without breaking at least one of our solution criteria. So we 600 only consider this solution for key-deriving methods. 602 [S2] Guarantee that the same peer credential is never usable inside and 603 outside a tunnel using server and client policy. This prevents 604 condition CC-A. 606 This solution actually works for all methods, but is sometimes hard 607 to deploy, due to legacy deployments and since clients and servers 608 need to be synchronized for proper policy enforcement. An 609 additional problem with this solution is the manageability issues 610 due to the multiple credentials that have to be managed by the same 611 client and server. 613 [S3] Prevent an Access Point (or Base station)/Client to be ever 614 manipulated to perform both functions and become an attacker. 615 This prevents condition CC-B. 617 This solution is possible to accomplish in a very limited context, 618 like under the watchful eyes of law enforcement. But due to the 619 wide availability of hacking tools, it is extremely expensive to 620 implement in the real world. 622 [S4] Provide a mechanism for all method secrets in a compound 623 authentication to be used for deriving sessions keys to protect 624 subsequent communication. This prevents condition CC-D. 626 This solution also, just like [S1], will only work for only key- 627 deriving methods. For non-key-deriving methods, this won't work 628 as the only choice is to use tunnel keys to meet the 629 solution criteria. 631 [S5] When using the same credentials inside and outside the tunnel, 632 modify the authentication method inside the tunnel for the 633 server/client to distinguish the authentication inside the tunnel. 634 This also prevents condition CC-C. 636 This solution partially violates the backwards compatibility 637 solution criteria, but is feasible where such a requirement does 638 not exist. Though this is not a general solution, in situations, 639 where the interest is in preserving the legacy credentials as 640 opposed to preserving the legacy authentication method, this 641 solution may make sense. 643 For realizing concepts S1 and S4 we use cryptographic means. S2 is 644 realizable just using policy techniques on the client and server ends. 645 The solution S5 uses modified legacy authentication methods when they 646 are used within the tunnel. Thus they require specification of tunneled 647 variations of legacy authentication methods to distinguish them from the 648 legacy methods. Thus we have solutions that can prevent all the causal 649 conditions except CC-B, as solution S3 is not viable. 651 3.3. Solution Mechanisms 653 The solution mechanisms include a mix of policy based techniques and 654 using cryptographic means. Assuming that compound methods are of 655 interest, the policy based techniques have significant relevance for 656 non-key deriving (possibly legacy) authentication methods where 657 cryptographic binding is not necessarily practical. These involve 658 the following mechanisms: 660 [1] Providing separate credentials for a user identity when using the 661 same authentication method inside and outside tunnels. 663 This enables the server to know when a credential that is not 664 intended for use inside a tunnel is being used. This maybe done 665 by an attacker and appropriate action can be taken. Though this is 666 restrictive and worsens usability, it maybe easy to deploy. 668 [2] Enforce client and server policy to always use authentication 669 methods inside tunnels. 671 This could have more significant deployment issues, but is a better 672 option if possible, as it enables the benefits of compound methods 673 to be realized more effectively. 675 [3] Provide a modified authentication method inside the tunnel for the 676 same credentials associated with a single user identity. 678 This is not a general solution, but can be applied in situations 679 where the authentication method is modifiable for use inside 680 the tunnel and there is significant interest in preserving the 681 credential being used for user convenience. The mechanisms include 682 some form of protected signal to the server from the client 683 indicating the authentication to be running inside a tunnel. It also 684 includes client and server policy of always expecting the modified 685 method to be used only inside a tunnel and not outside it. It is 686 also important that the man-in-the-middle attacker should not be 687 able to accomplish the same modification to the method that is 688 normally run outside the tunnel and thus spoof the server. It should 689 be noted as mentioned earlier this solution violates the backward 690 compatibility criterion in section 3.1, but can be used where such 691 a criterion is not relevant. 693 The mechanisms to provide cryptographic proof involve combining some 694 knowledge derived from each authentication method involved in a compound 695 authentication to prove that both parties are the real peers. This 696 knowledge may be in the form of keying material available to both 697 parties. This information can be used as part of a two-stage solution. 699 [Stage 1] Binding Phase Exchange with Compound Keyed MACs 701 Here we execute an additional 2-way handshake to the tunneling protocol 702 or base protocol, we call it the �Binding Phase Exchange�. This phase is 703 entered only if the server knows that all the individual 704 authentication methods inside the tunnel have completed. (There maybe 705 some situations where binding maybe carried out after each inner method 706 completes. However that is beyond our scope at the moment.) 708 In case of the tunnel server endpoint not being the final 709 authentication server, it has possession of the inner method keys if 710 they are available. The keys from all the inner methods and the tunnel 711 keys are used to compute keyed compound MACs as described in section 4.2. 712 The validation of the compound MACs protects against the 713 man-in-the-middle attack, as the attacker is unable to get any of the 714 inner method keys. Here the server sends a Binding request B1 with 715 a B1_MAC and the client validates it. If the message is valid the client 716 responds with the B2 message that also has a B2_MAC associated with it. 717 If the server successfully validate the B2_MAC, then it can be certain 718 that there was no man-in-the-middle. 720 | Binding Request(B1)[S_NONCE...B1_MAC] | 721 |<===============================================================| 722 | | 723 | | 724 | | 725 | | 726 | Binding Response(B2)[C_NONCE....B2_MAC] | 727 |===============================================================>| 728 | | 730 Figure 2: Binding Phase Message Flows 731 For clarity, we name all the keys and nonce values used in the two 732 stages. The input keys for the binding phase are TSK and the several 733 ISKs, one from each inner method. These keys should be available before 734 the binding phase exchange can be carried out. The details of the 735 derivation of these keys are in section 4.2 737 TSK Tunnel Session Key. This is part of the base keying material 738 available from the tunneling protocol. It should be at least 739 256 bits and derived ensuring key separation for binding, 740 non-binding, transmit and receive encryption and integrity 741 purposes. 743 ISK Inner Session Key for the inner authentication method running 744 inside the tunnel. Each inner method that derives keys will 745 have an non-zero ISK. It could be of variable length depending 746 on the particular method. But should be at least 64 bits. The 747 key derivation process in section 4.2 is capable of handling 748 variable length ISKs as they are input as strings to the PRFs. 750 S_NONCE 256 bit random number used for computing the Compound keyed 751 MAC values for the B1 message (B1_MAC) and the B2 message 752 (B2_MAC). 754 C_NONCE 256 bit random number used for computing the Compound keyed 755 MAC value for the B2 message (B2_MAC). 757 The output keys generated as part of the cryptographic binding process 758 are the MAC keys CMK_B1 and CMK_B2 and the CSK. CMK_B1 and CMK_B2 are 759 needed for computing the B1_MAC and B2_MAC repectively in stage 1. The 760 CSk is needed for stage 2. 762 CMK_B1 Compound MAC key derived for the B1 message MAC (B1_MAC) 763 computation. It is 128 bits in length. This is derived 764 with the S_NONCE which is a 256 bit random number. 766 CMK_B2 Compound MAC key derived for the B2 message MAC (B2_MAC) 767 computation. It is 128 bits in length. It is derived using 768 two nonces the S_NONCE and the C_NONCE both of which are 769 256 bit random numbers and also additional parameters that 770 representative of all the inner methods. 772 CSK Compound Session Key, which is the bound key generated for 773 use as the base keying material for the link layer. It is 774 192 bytes in length. The different portions of the CSK 775 are partitioned into 32 byte chunks and specified for 776 different uses including export as the session key for 777 subsequent protocol layers. 779 Here we descibe the stage 1 message exchange related aspects. 781 B1. Binding Request 783 This message is a request sent from the tunnel server to the 784 tunnel client to perform binding. Among other parameters it 785 includes a 256 bit random number, ie. the S_NONCE and a compound 786 keyed MAC, B1_MAC computed by the server over the entire 787 B1 message. There is a compound MAC server key CMK_B1, derived 788 for computing the B1_MAC on the server and another equivalent one 789 derived on the client for validating it after receiving the 790 message. The S_NONCE is used in the derivation of this CMK_B1 in 791 addition to the bound keying material (ISK1...ISKn) from all the 792 inner methods inside the tunnel and the tunnel keys (TSK). So if 793 the client and server have all the keying material from all the 794 methods, the B1_MAC validation on the client should succeed and 795 the response message B2 will be sent. 797 In the case of invalid B1_MAC, the client need not send a response 798 and can disconnect as a potential man-in-the-middle could be 799 present and be modifying packets. Also this message as it will be 800 enacapsulated in the underlying protocol, the retry policies on 801 the server can be specified as part of that protocol which 802 initiates binding. 804 B2. Binding Response 806 This is only sent as a response to B1 and includes a B2_MAC and 807 also additional parameters including a 256 bit random number 808 called the C_NONCE. The B2_MAC is a compound keyed MAC calculated 809 over the entire B2 message. The derivation of B2_MAC is explained 810 in section 4.2. A client MAC key is derived for computing this 811 B2_MAC. To prevent against replay attacks, the CMK_B2 is derived 812 using the S_NONCE and the C_NONCE and can only be derived after 813 the B1 message is received. 815 If the B1 message has an invalid B1_MAC, this CMK_B2 MAC key 816 derivation is not possible and the B2 message cannot be safely 817 constructed. So no response is sent. The server that does not 818 receive a B2 response can timeout and disconnect or perform a 819 retry. It is expected to use a new S_NONCE for every retry. 821 If the Binding Phase successfully completes with the server validating 822 the B2 message, then the compound authentication is complete. More 823 details this binding phase exchange is described in section 4.1. 824 The CMKs should provide enough strength for the MACs so that it cannot 825 be broken in the time taken to authenticate. ie. seconds. Its important 826 to remember that the binding phase exchange when performed as the 827 final step to to complete authentication should include the protected 828 success/failure indication using the Result TLV. This is described in 829 section 4.1. Also other meta information about the methods exchanged 830 can be used for policy validation or fraud detection purposes. However 831 the protection from the attack is mainly from the MACs and not from 832 the other parameters. 834 [Stage 2] Compound Session Keys Generation 836 In stage 2 we generate combined keys that are session keys for 837 link layer confidentiality and integrity protection needs.These are 838 computed using from all the inner method keys if they are available 839 and the tunnel keys. The resultant keys called Compound Session Keys 840 (CSKs) are provided to the link layer for ciphering and integrity 841 protection. These keys provide the assurance that all packets 842 are being exchanged between the real peers and no man-in-the-middle is 843 actually decrypting the conversation. The Compound Session Key 844 derivation is specified in section 4.2. 846 Though from our analysis, compound MACs used in the Stage 1 Binding 847 Phase Exchange provide the necessary protection, we argue that for 848 additional protection one could also use Stage 2. The main reason for 849 Stage 2 is to allow each tunnel packet privacy protection to also be 850 cryptographically bound to the inner methods it carries. 852 Performing Stage 1 prevents a man-in-the-middle from gaining 853 authenticated access. It also prevents false authenticated states 854 which could result in a Denial-of-Service attack that could result 855 if only Stage 2 is done. 857 Only implementing Stage 2 does not require additional round trips, but 858 it enables the man-in-the-middle to authenticate, although not to 859 obtain keys used for subsequent link-level authentication and encryption 860 of the data. This implies that the client will only discover an attack 861 when it discovers that it is unable to decipher the incoming data 862 stream. As a result, Stage 2 is probably not sufficient by itself. 864 3.4. Thwarting the attack 865 Client <-|Rogue NAS | NAS Auth Server 866 | Attacker |-> 867 | | | | 868 | | | | 869 | | Tunnel establishment w/ | 870 | | Server Authentication (1) | 871 | |<===================================>| 872 | | | | 873 | (Non-Authenticated | (Authenticated 874 | end of tunnel) | end of tunnel) 875 | | | | 876 | +--------------+ | +--------------+ 877 | | Tunnel | (2) | | Tunnel | 878 | | Keys Derived | | | Keys Derived | 879 | +--------------+ | +--------------+ 880 | | | | 881 | |.....................................| 882 | | Tunnel | 883 | |.....................................| 884 | | (Encrypted using Tunnel keys) | 885 | | | | 886 | | | | 887 | Tunneled mutual authentication method (3) | 888 | | w/key derivation| | 889 |<======================================================>| 890 | | | | 891 +--------------+ | | +--------------+ 892 | Compound | | | | Compound | 893 | Keys Derived | (4) | | | Keys Derived | 894 +--------------+ | | +--------------+ 895 | | | | 896 | | Binding Request | | 897 | | (5) (B1_MAC) | | 898 |<=======================================================| 899 | | | | 900 | | Binding Response| | 901 | | (6) (B2_MAC) | | 902 |=======================================================>| 903 | | | Attack detected | 904 | | | No keys(CSK/TSK) | 905 | | | sent | 906 | | | | 907 | | | Failure | 908 | | |<==================| 910 Figure 3 - Man-in-the-middle attack thwarted by compound MAC and 911 compound session keys 913 Figure 3 shows how by adding the Binding Phase Protocol Exchange 914 the attack is prevented as the man-in-the-middle attacker cannot provide 915 the correct B1_MAC that the client will validate against in the B1 916 message in step (5). Also the B2 message cannot be successfully sent 917 by the attacker and the server will fail a false B2 message, that does 918 not possess a valid B2_MAC. Hence the compound session keys (if stage 2 919 is used) or tunnel keys are not sent to the Authenticator by the server. 920 Thus the man-in-the-middle attack is prevented. 922 3.5. Solution approaches 924 Stages 1 or 2 can be implemented in different ways: 926 EAP In this approach, the binding phase exchange of a compound 927 keyed MACs is supported within EAP, by implementing the 928 exchange as a new EAP method occuring after authentication is 929 complete. Tunnel keys are provided by the tunneling protocol 930 to the EAP layer in order to enable computation of the 931 compound keyed MACs and compound session keys. Since existing 932 EAP implementations already enable EAP methods to provide 933 keying material to the EAP layer, such an interface typically 934 already exists. This approach is general in that it applies to 935 any tunneling technique. 937 Tunneling method 938 In this approach, the tunneling method acquires keying 939 material derived by the underlying authentication methods, in 940 order to enable computation of the compound keyed MACs and 941 compound session keys. Since existing tunneling techniques 942 typically do not provide an interface for receiving keying 943 material from authentication methods, this approach will 944 typically require some re-architecture of existing 945 implementations. It also has the disadvantage of requiring 946 changes to each tunneling method, and as a result is not as 947 general as an EAP-based solution. Given the prevalence of the 948 attacks described within this document, it would represent a 949 considerable burden on the security community to review 950 changes to each individual tunneling approach. However, such 951 an approach may be able to take advantage of properties of the 952 underlying tunnel technology, such as the ability to have more 953 than one packet in transit at a time. 955 EAP methods 956 In this approach, keys derived from previous EAP methods are 957 incorporated into the authentication calculations of 958 subsequent methods. Since existing interfaces only support the 959 export of keys by EAP methods, not importation, some 960 rearchitecture is required in this approach. In addition, this 961 approach requires modification of existing EAP methods, which 962 will create deployment barriers. However, this approach may 963 be applied even to methods which support only one-way 964 authentication and do not generate keys. As mentioned 965 earlier the use of signals to indicate the explicit intention 966 to run inside a tunnel can be another approach to mitigating 967 the problem. However the signals have to be protected from 968 spoofing and that is not easy without some keying material 969 being available. 971 Based on the pros and cons of each approach, we recommend a solution 972 that applies to all EAP methods either in the Tunneling method or 973 in the EAP base protocol. 975 3.6. Solution scope 977 The policy based mechanisms we described in the previous section will 978 work for any tunneling protocol, but it can be a bit restrictive. 980 The cryptographic mechanisms work for all key deriving methods and 981 can be implemented in the EAP base protocol or the tunneling protocol 982 as extensions. This is possible because all EAP methods deriving keys 983 will be able to provide keying material required for the binding 984 process. Also the PRF that is used for key derivation in the binding 985 phase can be selected by the tunneling protocol fairly independently. 986 The cryptographic binding process will also provide exportable keying 987 material through the CSKs for subsequent protocol layers or application 988 use in a transparent manner. 990 When a mix of key deriving and non-key deriving methods are used inside 991 the tunnel the nature of protection largely relies on the key deriving 992 methods. If the non-key deriving methods are not properly managed 993 through policy mechanisms as described earlier and if they play a 994 significant role in the compound authentication success/failure 995 condition then the vulnerability still exists. But the attacker may not 996 be able to take control of the network access session. 998 However it important to note that, downgrade attacks are possible 999 with modified EAP or tunneling protocols as attackers can always try 1000 to get the server to connect to a client tunnel that does not support 1001 cryptographic binding or the policy mechanisms. So appropriate server 1002 and client policies are needed to either not support older versions of 1003 the protocols that do not have the enhancements or have counter 1004 measures in place to deal with potential fraud. 1006 4. Reference Solution in Tunneling Protocol 1008 Here we describe a reference solution using cryptographic binding 1009 that can be implemented in a tunneled EAP-based authentication protocol 1010 like PEAP to thwart man-in-the-middle attacks. This involves 1011 incorporating a binding phase handshake after all the inner EAP methods 1012 inside the tunnel complete, to provide cryptographic proof that the 1013 peers indeed took part in all the authentication methods. We use 1014 compound keyed MACs for these messages using keys derived from the 1015 individual methods combined with the tunnel keys. We also derive 1016 cryptographically bound session keys that can be exported by the tunnel 1017 method as Master Session Keys (MSK) for ciphering at the link layer. 1018 Though we limit our discussion to PEAP, the principles used here can be 1019 applied to other compound authentication protocols as well. Here for 1020 simplicity though we assume the tunnel server endpoint is the final 1021 authentication server, the solution works for either case. The only 1022 requirement is that tunnel server get all the inner method session keys 1023 if they are derived, from the final authentication server. 1025 4.1 Binding Phase Precepts 1027 The cryptographic binding MUST take place between the tunnel client and 1028 the tunnel server. The tunnel client and server MUST have access to both 1029 tunnel method and inner authentication method Master Session Keys (MSKs). 1030 (However an attacking tunnel client will not be able to meet this 1031 condition.) The tunnel method and inner method MSKs MUST be fresh to 1032 ensure liveness of the binding phase handshake. Though the binding phase 1033 is intended to be carried out after all the inner authentication 1034 methods complete, some tunneling protocols MAY opt to do it after 1035 every inner authentication method completes. This requires the tunnel 1036 method to distinguish between the final binding and the intermediate 1037 ones, using the RESULT TLV described in section 4.4. 1039 The PRF selected for generating compound keyed MACs and the compound 1040 session keys SHOULD be based on what is supported in the tunneling 1041 protocol. This enables easier implementation of the binding phase 1042 handshake. For the case of PEAP, as TLS is used, the P_SHA-1 PRF is 1043 that is part of TLS is selected. 1045 The tunnel server MUST do proper version negotiation upfront to prevent 1046 downgrade attacks. If the tunnel server wishes cryptographic binding to 1047 be mandatory, then using policy it MUST ensure that it only permits 1048 connections to a tunnel client version that supports cryptographic 1049 binding. At the same time, it MUST ensure that for non-key deriving 1050 methods that MAY be used, separate credentials are provided for use 1051 inside and outside the tunnel. 1053 In the case where the tunnel server is not the final authentication 1054 server, this binding phase MUST be started only after the tunnel server 1055 gets the inner method keys from the final authentication server. This 1056 also assumes that the tunnel server and authentication server have a 1057 security association that enables them to share these keys and the 1058 tunnel server is capable of holding the authentication state till the 1059 binding phase is complete. 1061 4.2 Binding Phase Handshake 1063 This 2-way handshake for cryptographic binding SHOULD be added as a 1064 tunnel protocol extension. This handshake is started when the server 1065 makes a determination that the last inner authentication methods have 1066 completed. The highest version number supported is needed in both the 1067 Binding Request (B1) and Binding Response (B2) messages to provide 1068 additional protection through policy enforcement. 1070 The version number will prevent roll back attacks between tunnel 1071 protocol versions that support cryptographic binding, but not for other 1072 implementations that do not support it. 1074 The server having possession of all the inner method keys and also 1075 the tunnel keys, and including a 256 bit server Nonce (S_NONCE), 1076 computes a compound MAC server key (CMK_B1). This and other 1077 cryptographic derivations are described in the next section. Then the 1078 server sends a Binding Request Message (B1) that has a server-computed 1079 compound keyed MAC (B1_MAC) associated with it. This message body 1080 includes the version number of the protocol extension, 1081 a 256 bit S_NONCE, a RESULT_TLV that provides protected success/failure 1082 indication. The B1_MAC is computed over this entire message body by 1083 setting the MAC field bits to zero. 1085 | Binding Request(B1) | 1086 |<===============================================================| 1087 | [RESULT_TLV, CRYPTO_BINDING_TLV(VERSION,S_NONCE,B1_MAC)] | 1088 | | 1089 | | 1090 | Binding Response(B2) | 1091 |===============================================================>| 1092 | [RESULT_TLV, CRYPTO_BINDING_TLV(VERSION,C_NONCE, B2_MAC)] | 1093 | | 1095 Figure 4: Binding Phase Message Flows (Success Case) 1097 The client on receiving the B1 message will first compute its own CMK_B1 1098 using the S_NONCE and its own knowledge of all the inner method keys and 1099 the tunnel keys. Then it validates the B1_MAC sent from the server by 1100 recomputing it over the B1 message body with MAC bits set to zero. If 1101 the B1 message is valid, it responds with a Binding Response (B2) 1102 message that includes a compound keyed MAC (B2_MAC). Before it responds, 1103 it first computes a MAC key (CMK_B2), for computing the B2_MAC, 1104 using the tunnel keys, all the inner method keys, the S_NONCE received 1105 from the server and a locally derived 256 bit client Nonce (C_NONCE). 1106 The B2 message body is similar to the B1 message, and includes a version 1107 number of the protocol extension, a 256 bit C_NONCE, a RESULT TLV that 1108 provides acknowledgment for the protected success/failure indication. 1110 A client side MAC (B2_MAC) is computed for this message body using the 1111 CMK_B2, with the MAC bits set to zero, and is included in the B2 1112 message. Figure 4 shows both the messages in the success case. 1114 There are several conditions that can cause invalid B1 or B2 messages, 1115 they include the following: 1117 � Invalid B1_MAC or B2_MAC 1118 � Incompatible protocol version 1119 � Invalid RESULT_TLV 1121 A man-in-the-middle attack can cause these conditions to occur. More 1122 details on detecting these conditions are described as part of the 1123 message formats in section 4.3. Here we describe how they are handled 1124 as the failure authentication cases. 1126 [1] Client receiving an invalid B1 message 1128 If the client finds the Binding Request (B1) message to be invalid, it 1129 does not send any response. It can make a decision to drop the connection 1130 at this time, as it is not certain, that its talking to the right server. 1131 Any other Binding Requests (B1) messages if they arrive subsequently, 1132 and if they are valid, are responded to using proper Binding Response 1133 (B2) messages. This is to allow for packet loss during the server retry 1134 time period. The retry of packets is handled by the EAP layer; and is 1135 transparent to the EAP methods. The packets should not be different 1136 because the media is unreliable. 1138 [2] Client never receiving a B1 message 1140 In this case, client having waited for sufficient time (retry time 1141 period) will time out and can drop the connection. 1143 [3] Server receiving an invalid B2 message 1145 If the server receives an invalid Binding Response (B2) message, it can 1146 decide to drop the connection, as its not certain that it is talking to 1147 the right client. Any further Binding Responses are ignored, even if the 1148 server had sent out more than one B1 messages. 1150 [4] Server never receiving a B2 message 1152 In this case, the server will time out and can do a retry, up to 3 times 1153 with new B1 messages. It must use a new S_NONCE every time it sends a 1154 new message. 1156 4.3 Compound MAC and Session Key derivation 1158 The input for the cryptographic binding we use includes the 128-octet 1159 Tunnel Session Key (TSK), the 64-octet Tunnel Initialization Vector 1160 (TIV), and the inner method provided session keys, ISK1, ISK2,..ISKN, 1161 that belong to the N authentication methods used inside the tunnel. 1162 These keys may all be of varying sizes, so a known size in multiples 1163 of 32 bits between 64 and 256 bits is chosen of each of the methods 1164 based on available keying material. 1166 The Compound MAC for the client (the B2_MAC) and the server (the B1_MAC) 1167 are derived from two different MAC keys called CMK_B2 and CMK_B1 1168 respectively. A compound session key (CSK) is also derived on both the 1169 client and server for cryptographic purposes. If the binding phase is 1170 implemented, that alone prevents the man-in-the-middle attacks, so the 1171 CSKs are really not needed and the tunnel session keys can still be used 1172 for ciphering purposes, just as the TSK is in a normal EAP-TLS session. 1174 The CMK_B1, CMK_B2 and CSK are derived as follows for the PEAP protocol. 1175 PEAP tunnel session key (TSK); TSK is calculated using the EAP-TLS 1176 algorithm (RFC2716 section 3.5), and is 128 octets. This includes the 1177 first 64 octets of MSK (Master Session Key) and next 64 octets of EMSK 1178 (Extended Master Session Key). 1180 ISK1..ISKn are the EAP inner session keys (MSK) obtained from methods 1 1181 to n. 1183 In some cases, ISKi, for some i, may be the null string (""), when the 1184 corresponding method does not derive keying material. 1186 We use the P_SHA-1 PRF specified in the TLS specification [RFC2246] 1187 for PEAP, though this PRF selection decision can be made independently 1188 for each tunneling protocol. 1190 Compound MAC Key derivation algorithm: 1192 Take the second 256 bits (32 octets) of MSK portion of the TSK. 1193 output) 1195 IPMK0 = TSK 1197 for j = 1 to n do 1199 IPMKj = PRF(IPMK(j-1),"Intermediate PEAP MAC key", ISKj); 1201 Where j denotes the last inner method that runs inside the tunnel. Each 1202 IPMKj output is 32 octets. IPMKn is the intermediate combined key used 1203 to derive compound session and compound MAC keys. 1205 The Compound MAC Key for the server (the B1_MAC) is derived CMK_B1 1207 CMK_B1 = P_SHA1(IPMKn,"PEAP Server B1 MAC key" | S_NONCE); 1209 The Compound MAC Key for the client (the B2_MAC) is derived from MAC key called CMK B2. 1211 CMK_B2 = P_SHA1(IPMKn,"PEAP Client B2 MAC key" | C_NONCE | S_NONCE); 1213 The compound MAC keys (CMK_B1 and CMK_B2) are each 20 octets long. 1215 ("|" denotes concatenation) 1216 The pseudorandom function PRF(k,label,string) is computed as 1217 P_SHA-1(k,label|string) (or substitute, if necessary, any other PRF that 1218 produces output of sufficient length). Here the outputs are taken to 1219 as many bits as are necessary (typically 256 bits for a key). 1221 Compound Session Key derivation: 1223 The following function provides the necessary keying material. 1225 CSK = PRF(IPMKn, "PEAP compound session key", 1226 C_NONCE|S_NONCE, OutputLength); 1228 where the PRF is the same one used for CMK derivation. The output is 1229 taken to 128 octets. The first 64 octets are taken and the MSK and the 1230 second 64 octets are taken as the EMSK. The MSK and EMSK are described 1231 in [RFC2284bis]. 1233 4.4 Binding Message Formats 1235 The Binding Messages are represented using TLVs defined below. 1236 The generic TLV format is defined in [PEAP] in section 3.1 1237 and duplicated below. 1239 0 1 2 3 1240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 |M|R| Type | Length | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Value... 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 M 1249 0 - Non-mandatory TLV 1250 1 - Mandatory TLV 1252 R 1253 Reserved, set to zero (0) 1255 Type 1257 A 14-bit field, denoting the attribute type. Allocated AVP Types 1258 include: 1259 0 - Reserved 1260 1 - Reserved 1261 2 - Reserved 1262 3 - Result TLV (Acknowledged Result) 1264 Length 1266 The length of the Value field in octets. 1268 Value 1270 The value of the object. 1272 We also use the Result TLV that also defined in [PEAP] to indicate the 1273 final success acknowledgement. The following is the duplicated 1274 definition of the Result TLV. 1276 Result TLV: 1278 This is defined in [PEAP] and is duplicated below. 1280 The Result TLV provides support for acknowledged Success and Failure 1281 messages within EAP. It is defined as follows: 1283 0 1 2 3 1284 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 |M|R| Type | Length | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | Status | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 M 1293 1 bit. Value = 1 - Mandatory TLV 1295 R 1297 1 bit. Reserved, set to zero (0) 1299 TLV Type 1301 14 bits. Value = 3 - Success/Failure 1303 Length 1305 2 octets 1307 Status 1309 The status field is two octets. Values include: 1310 1 - Success 1311 2 - Failure 1313 The Cryptographic Binding is performed using the Binding TLV. It is 1314 described below. Both the Binding Request (B1) and Binding Response (B2) 1315 use the same packet format. However the SubType indicates whether it is 1316 B1 or B2. The Binding TLV and other TLVs are carried in the EAP-TLV 1317 packet defined in [PEAP]. The Binding TLV can be used to perform 1318 cryptographic Binding after each EAP method is complete. If this is the 1319 final method, then the EAP-TLV packet must also include the Result TLV 1320 along with the Binding TLV. 1322 Binding TLV (Also called Tunnel Authenticity/Integrity Check TLV): 1324 This message format is used for the Binding Request (B1) and also the 1325 Binding Response. This uses TLV type CRYPTO_BINDING_TLV. The format is 1326 as given below. 1328 0 1 2 3 1329 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 |M|R| TLV Type | Length | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Version | Recvd. Version| SubType | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | | 1336 + NONCE + 1337 | | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | | 1340 + Compound MAC + 1341 | | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 M 1345 1 bit. Value = 1 - Mandatory TLV 1347 R 1349 1 bit. Reserved, set to zero (0) 1351 TLV Type 1353 14 bits. Value = CRYPTO_BINDING_TLV. See IANA Considerations. 1355 Length 1357 2 octets. Value = 52 (excludes the 16 bit EAP-TLV header) 1359 Version 1361 1 octet. Version of tunnel protocol extension for binding. 1362 Initially set to 0. 1364 Received Version 1366 1 octet. PEAP version number received to prevent downgrade attacks. 1368 SubType 1370 2 octets. 1371 0 - Binding Request 1372 1 - Binding Response 1374 Nonce 1375 32 octets. 256 bit Random number that is never repeated and is 1376 used for compound MAC key derivation at each end. It is a S_NONCE 1377 for the B1 message and a C_NONCE for the B2 message. 1379 MAC 1381 16 octets (128 bits). This can be the Server MAC (B1_MAC) or the 1382 Client MAC (B2_MAC). It is computed over the entire Binding TLV 1383 packet using the HMAC-SHA1-128 that provides 128 bits of output 1384 using the CMK_B1 or CMK_B2 with the MAC field zeroed out. 1386 4.5 IANA Considerations 1388 IANA has assigned the EAP type number 33 for TLVs. 1390 This protocol extension defines a new TLV types for cryptographic 1391 binding that are defined below. 1393 CRYPTO_BINDING_TLV 5 1395 It also uses the Result TLV (RESULT_TLV) defined in the draft[PEAP] 1397 4.6 Security Considerations 1399 This section describes the limitations of the solutions provided in this 1400 document and also provides guidelines for ensuring proper 1401 implementation. 1403 For our cryptographic binding based solution to work, the tunnel session 1404 keys (TSKs) and all the inner methods keys (ISKs) need to be guaranteed 1405 to be fresh and derived for new for every compound authentication 1406 session. 1408 For the case where the tunnel server is not the final authentication 1409 server, the inner method keys must be securely delivered to the tunnel 1410 server from the final authentication server where they are derived. 1412 The key derivation we use always ensures the usage of tunnel keys 1413 and therefore prevents a weak inner method key to be used by itself, 1414 which could have opened up some dictionary attack possibilities on the 1415 compound MAC based on weak inner method keys alone. 1417 5. Normative references 1419 [TLS] [RFC2246] 1421 [EAP-MD5] [RFC2284] 1423 [ISAKMP] [RFC2408] 1425 [IKE] [RFC2409] 1427 [PEAPV0] Kamath, V., Palekar, A., Wodrich,M., "Microsoft's PEAP 1428 version 0 (Implementation in Windows XP SP1)", October 1429 2002 (work in progress) 1431 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1432 RFC 1661, July 1994. 1434 [RFC1938] Haller, N. and C. Metz, "A One-Time Password System", RFC 1435 1938, May 1996. 1437 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1438 Protocol (CHAP)", RFC 1994, August 1996. 1440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1442 Requirement Levels", RFC 2119, March 1997.] 1444 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 1445 Protocol (EAP)", RFC 2284, March 1998. 1447 [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., 1448 "Remote Authentication Dial In User Service (RADIUS)", 1449 RFC 2865, June 2000. 1451 [RFC3193] Patel, B., et al., "Securing L2TP Using IPsec", RFC 3193, 1452 November 2001. 1454 [EAPTTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS 1455 Authentication Protocol", Internet draft (work in 1456 progress), February 2002. 1458 [DHCPIpsec] Patel, B., et al., "DHCPv4 Configuration of IPsec Tunnel 1459 Mode", Internet draft (work in progress), draft-ietf- 1460 ipsec-dhcp-13.txt, June 2001. 1462 [PEAP] Palekar et al., "Protected EAP Protocol (PEAP)", 1463 Internet draft (work in progress), draft-josefsson- 1464 pppext-eap-tls-eap-07.txt, October 2003. 1466 [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE 1467 Credential Provisioning Protocol", Internet draft (work 1468 in progress), draft-ietf-ipsra-pic-06.txt, September 1469 2002. 1471 [IPSRAREQ] Kelly, S., Ramamoorthi, S., "Requirements for IPsec 1472 Remote Access Scenarios", Internet draft (work in 1473 progress), draft-ietf-ipsra- reqmts-05.txt, September 1474 2002. 1476 [GETCERT] Bellovin, S., and Moskowitz, B., "Client Certificate and 1477 Key Retrieval for IKE", Internet draft (work in 1478 progress), draft-bellovin-ipsra-getcert-00.txt, June 1479 2000. 1481 [SECURID] Josefsson, S., "The EAP SecurID(r) Mechanism", Internet 1482 draft (work in progress), draft-josefsson-eap- 1483 securid-01.txt, February 2002. 1485 [PANATLS] Ohba, Y., et al., "PANA over TLS", Internet draft (work 1486 in progress), draft-ohba-pana-potls-00.txt, September 1487 2002. 1489 [XAUTH] Pereira, R., Beaulieu, S., "Extended Authentication 1490 within ISAKMP/Oakley", Internet-draft (work in progress), 1491 draft-beaulieu-ike-xauth-02.txt, September, 2000. 1493 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 1494 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1496 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 1497 Port based Network Access Control, IEEE Std 802.1X-2001, 1498 June 2001. 1500 [IEEE80211] Information technology - Telecommunications and 1501 information exchange between systems - Local and 1502 metropolitan area networks - Specific Requirements Part 1503 11: Wireless LAN Medium Access Control (MAC) and 1504 Physical Layer (PHY) Specifications, IEEE Std. 1505 802.11-1997, 1997. 1507 6. Informative references 1509 [RFC1510] Kohl, J., Neuman, C., "The Kerberos Network 1510 Authentication Service (V5)", RFC 1510, September 1993. 1512 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1513 RFC 2246, November 1998. 1515 [RFC2486] Beadles, M., Aboba, B., "The Network Access Identifier", 1516 RFC 2486, January 1999. 1518 [RFC2486bis] Blunk, L, Vollbrecht, J., Aboba, B., Carlson, J., 1519 Levkowetz, H., "Extensible Authentication Protocol", 1520 RFC 2486bis-06.txt (work in progress), September 2003. 1522 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the 1523 Internet Protocol", RFC 2401, November 1998. 1525 [RFC2402] Kent,S., Atkinson, R., "IP Authentication Header", RFC 1526 2402, November 1998. 1528 [RFC2406] Kent,S., Atkinson, R., "IP Encapsulating Security Payload 1529 (ESP)", RFC 2406, November 1998. 1531 [RFC2407] Piper, D., "The Internet IP Security Domain of 1532 Interpretation of ISAKMP", RFC 2407, November 1998. 1534 [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and Turner, 1535 J., "Internet Security Association and Key Management 1536 Protocol (ISAKMP)", RFC 2408, November 1998. 1538 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 1539 (IKE)", RFC 2409, November 1998. 1541 [RFC2412] Orman, H., "The Oakley Key Determination Protocol", RFC 1543 2412, Nov. 1998. 1545 [RFC2433] Zorn, G., Cobb, S., "Microsoft PPP CHAP Extensions", RFC 1546 2433, October 1998. 1548 [RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol 1549 (PPTP)", RFC 2637, July 1999. 1551 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1552 G., and Palter, B., "Layer Two Tunneling Protocol L2TP", 1553 RFC 2661, August 1999. 1555 [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication 1556 Protocol", RFC 2716, October 1999. 1558 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 1559 2759, January 2000. 1560 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1562 [DECEPTION] Slatalla, M., and Quittner, J., "Masters of Deception." 1563 HarperCollins, New York, 1995. 1565 [KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos Password 1566 Security", Stanford University Computer Science 1567 Department, http://theory.stanford.edu/~tjw/krbpass.html 1569 [KRBLIM] Bellovin, S.M., Merritt, M., "Limitations of the kerberos 1570 authentication system", Proceedings of the 1991 Winter 1571 USENIX Conference, pp. 253-267, 1991. 1573 [KERB4WEAK] Dole, B., Lodin, S., and Spafford, E., "Misplaced trust: 1574 Kerberos 4 session keys", Proceedings of the Internet 1575 Society Network and Distributed System Security 1576 Symposium, pp. 60-70, March 1997. 1578 [PPTPv1] Schneier, B, Mudge, "Cryptanalysis of Microsoft's Point- 1579 to- Point Tunneling Protocol", Proceedings of the 5th ACM 1580 Conference on Communications and Computer Security, ACM 1581 Press, November 1998. 1583 [IEEE8023] ISO/IEC 8802-3 Information technology - 1584 Telecommunications and information exchange between 1585 systems - Local and metropolitan area networks - Common 1586 specifications - Part 3: Carrier Sense Multiple Access 1587 with Collision Detection (CSMA/CD) Access Method and 1588 Physical Layer Specifications, (also ANSI/IEEE Std 1589 802.3-1996), 1996. 1591 [MITM] Nokia Research Center, Man-in-the-middle attacks in 1592 tunneled authentication protocols, 1593 http://www.saunalahti.fi/~asokan/research/mitm.html, 1594 October 2002 1596 [MITM1] N. Asokan, Valtteri Niemi and Kaisa Nyberg, 1597 Man-in-the-middle in tunneled authentication protocols, 1598 Technical Report 2002/163, IACR ePrint archive, 1599 October 2002. Available from 1600 http://eprint.iacr.org/2002/163 1602 [SLA] Harkins, D., Piper, D., and Hoffman, P., "Secure Legacy 1603 Authentiation for IKEv2", draft-hoffman-sla-00.txt, 1604 December 2002 (work in progress) 1606 [IKEv2] Kaufman, C. (Editor), "Internet Key Exchange (IKEv2), 1607 draft-ietf-ipsec-ikev2-05.txt, February2003 1608 (work in progress) 1610 Acknowledgments 1612 We wish to thank N. Asokan, Valtteri Niemi, Kaisa Nyberg and Henry 1613 Haverinen of Nokia for initially making us aware of the problem [MITM]. 1615 Special thanks to Bernard Aboba, N.Asokan, Jesse Walker, Farid Adrangi, 1616 Nancy Cam-Winget, Joe Salowey, Jari Arkko, Mohan Parthasarathy, 1617 Jukka Ylitalo, Michael Richardson, DongGook Park and Hao Zhou for their 1618 valuable comments and suggestions. 1620 Also additional thanks to Bernard Aboba for his expert advice and 1621 editorial assistance with the early versions of this document. 1623 Authors' Addresses 1625 Jose Puthenkulam 1626 Intel Corporation 1627 2111 NE 25th Avenue, JF2-58 1628 Hillsboro, OR 97124 1630 EMail: jose.p.puthenkulam@intel.com 1631 Phone: +1 503 264 6121 1632 Fax: +1 503 264 4230 1633 Victor Lortz 1634 Intel Corporation 1635 2111 NE 25th Avenue, JF3-206 1636 Hillsboro, OR 97124 1638 EMail: victor.lortz@intel.com 1639 Phone: +1 503 264 3253 1640 Fax: +1 503 264 4230 1642 Ashwin Palekar 1643 Dan Simon 1644 Microsoft Corporation 1645 One Microsoft Way 1646 Redmond, WA 98052 1648 EMail: {ashwinp, dansimon}@microsoft.com 1649 Phone: +1 425 882 8080 1650 Fax: +1 425 936 7329 1652 Intellectual Property Statement 1654 The IETF takes no position regarding the validity or scope of any 1655 intellectual property or other rights that might be claimed to 1656 pertain to the implementation or use of the technology described in 1657 this document or the extent to which any license under such rights 1658 might or might not be available; neither does it represent that it 1659 has made any effort to identify any such rights. Information on the 1660 IETF's procedures with respect to rights in standards-track and 1661 standards-related documentation can be found in BCP-11. Copies of 1662 claims of rights made available for publication and any assurances of 1663 licenses to be made available, or the result of an attempt made to 1664 obtain a general license or permission for the use of such 1665 proprietary rights by implementors or users of this specification can 1666 be obtained from the IETF Secretariat. 1668 The IETF invites any interested party to bring to its attention any 1669 copyrights, patents or patent applications, or other proprietary 1670 rights which may cover technology that may be required to practice 1671 this standard. Please address the information to the IETF Executive 1672 Director. 1674 Full Copyright Statement 1676 Copyright (C) The Internet Society (2003). All Rights Reserved. 1677 This document and translations of it may be copied and furnished to 1678 others, and derivative works that comment on or otherwise explain it or 1679 assist in its implementation may be prepared, copied, published and 1680 distributed, in whole or in part, without restriction of any kind, 1681 provided that the above copyright notice and this paragraph are included 1682 on all such copies and derivative works. However, this document itself 1683 may not be modified in any way, such as by removing the copyright notice 1684 or references to the Internet Society or other Internet organizations, 1685 except as needed for the purpose of developing Internet standards in 1686 which case the procedures for copyrights defined in the Internet 1687 Standards process must be followed, or as required to translate it into 1688 languages other than English. The limited permissions granted above are 1689 perpetual and will not be revoked by the Internet Society or its 1690 successors or assigns. This document and the information contained 1691 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1692 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1693 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1694 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1695 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1697 EAP Issues 1699 Open issues relating to EAP, including the issues described in this 1700 document, are tracked on the following web site: 1702 http://www.drizzle.com/~aboba/EAP/eapissues.html 1704 Expiration Date 1706 This memo is filed as , and 1707 expires on April 26, 2004.