idnits 2.17.1 draft-puthenkulam-eap-binding-02.txt: -(85): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(635): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1038): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1068): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1086): 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 13 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 31) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 89 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** There are 4 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 200 has weird spacing: '...service verif...' == Line 426 has weird spacing: '...ication metho...' == Line 728 has weird spacing: '...tential man-i...' == Line 877 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.) -- The document date (3 March 2003) is 7719 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IPSEC' is mentioned on line 77, but not defined == Missing Reference: 'EAPMSCHAPV2' is mentioned on line 91, but not defined -- Looks like a reference, but probably isn't: '1' on line 1035 -- Looks like a reference, but probably isn't: '2' on line 1047 -- Looks like a reference, but probably isn't: '3' on line 1052 -- Looks like a reference, but probably isn't: '4' on line 1059 == Missing Reference: 'RFC1993' is mentioned on line 245, but not defined == Missing Reference: 'DHCPIPsec' is mentioned on line 300, but not defined == Missing Reference: 'CC-A' is mentioned on line 458, but not defined == Missing Reference: 'CC-B' is mentioned on line 469, but not defined == Missing Reference: 'CC-C' is mentioned on line 478, but not defined == Missing Reference: 'CC-D' is mentioned on line 487, but not defined == Missing Reference: 'S1' is mentioned on line 584, but not defined == Missing Reference: 'S2' is mentioned on line 560, but not defined == Missing Reference: 'S3' is mentioned on line 571, but not defined == Missing Reference: 'S4' is mentioned on line 580, but not defined == Missing Reference: 'Stage 1' is mentioned on line 632, but not defined == Missing Reference: 'Stage 2' is mentioned on line 764, but not defined == Unused Reference: 'EAP-MD5' is defined on line 1404, but no explicit reference was found in the text == Unused Reference: 'ISAKMP' is defined on line 1406, but no explicit reference was found in the text == Unused Reference: 'IKE' is defined on line 1408, but no explicit reference was found in the text == Unused Reference: 'PEAPV0' is defined on line 1410, but no explicit reference was found in the text == Unused Reference: 'RFC1661' is defined on line 1418, but no explicit reference was found in the text == Unused Reference: 'RFC1938' is defined on line 1421, but no explicit reference was found in the text == Unused Reference: 'DHCPIpsec' is defined on line 1445, but no explicit reference was found in the text == Unused Reference: 'IPSRAREQ' is defined on line 1458, but no explicit reference was found in the text == Unused Reference: 'GETCERT' is defined on line 1463, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 1480, but no explicit reference was found in the text == Unused Reference: 'IEEE80211' is defined on line 1487, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 1496, but no explicit reference was found in the text == Unused Reference: 'RFC2486' is defined on line 1502, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 1505, but no explicit reference was found in the text == Unused Reference: 'RFC2402' is defined on line 1508, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 1511, but no explicit reference was found in the text == Unused Reference: 'RFC2407' is defined on line 1514, but no explicit reference was found in the text == Unused Reference: 'RFC2412' is defined on line 1524, but no explicit reference was found in the text == Unused Reference: 'RFC2433' is defined on line 1528, but no explicit reference was found in the text == Unused Reference: 'RFC2716' is defined on line 1538, but no explicit reference was found in the text == Unused Reference: 'RFC2759' is defined on line 1541, but no explicit reference was found in the text == Unused Reference: 'RFC2866' is defined on line 1543, but no explicit reference was found in the text == Unused Reference: 'DECEPTION' is defined on line 1545, but no explicit reference was found in the text == Unused Reference: 'KRBATTACK' is defined on line 1548, but no explicit reference was found in the text == Unused Reference: 'KRBLIM' is defined on line 1552, but no explicit reference was found in the text == Unused Reference: 'KERB4WEAK' is defined on line 1556, but no explicit reference was found in the text == Unused Reference: 'PPTPv1' is defined on line 1561, but no explicit reference was found in the text == Unused Reference: 'IEEE8023' is defined on line 1566, but no explicit reference was found in the text == Unused Reference: 'MITM1' is defined on line 1579, 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-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) -- 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) -- 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) Summary: 12 errors (**), 0 flaws (~~), 54 warnings (==), 22 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 Intel Corporation 4 Category: Informational Ashwin Palekar 5 Dan Simon 6 Microsoft 7 3 March 2003 9 The Compound Authentication Binding Problem 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2003). All Rights Reserved. 33 Abstract 35 There are several motivations for using compound authentication methods 36 using tunnels, but man-in-the-middle attacks are possible in certain 37 circumstances when they 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 studies the problems 41 and suggests potential solutions to mitigate them. 43 Table of Contents 45 1. Introduction .......................................... 3 46 1.1 Scope ........................................... 3 47 1.2 Motivations for Compound Methods ................ 4 48 1.3 Problem Statement ............................... 5 49 1.4 Requirements Language ........................... 5 50 1.5 Terminology ..................................... 5 51 2. Problem Description.................................... 7 52 2.1 Overview ........................................ 7 53 2.2 Attack Scenarios ................................ 9 54 2.2 Conditions for the attack........................ 11 55 3. Potential Solutions ................................... 12 56 3.1 Solution criteria ............................... 13 57 3.2 Solution concepts ............................... 14 58 3.3 Solution mechanisms ............................. 15 59 3.4 Thwarting the attack............................. 19 60 3.5 Solution approaches ............................. 21 61 3.6 Solution scope .................................. 22 62 4. Reference Solution in Tunneling Protocol............... 23 63 4.1 Binding Phase Exchange........................... 23 64 4.2 Compound MAC and Session Key derivation.......... 25 65 4.3 Binding Message Formats ......................... 27 66 4.4 IANA Considerations.............................. 33 67 5. Normative references .................................. 33 68 6. Informative references ................................ 35 69 ACKNOWLEDGMENTS .............................................. 36 70 AUTHORS' ADDRESSES ........................................... 37 71 Full Copyright Statement ..................................... 39 72 1. Introduction 74 As authentication protocols evolved over time, weaker ones have 75 either been replaced or modified to meet the increasing security needs 76 in new environments. The development of secure tunneling techniques like 77 [TLS] and [IPSEC] have generated a lot of interest in securing legacy or 78 weaker authentication protocols using tunnels. We call such compositions 79 of multiple authentication protocols that are used in concert to 80 accomplish a single purpose, Compound Authentication Methods. They may 81 be used for several purposes, including user authentication for granting 82 network access or establishing a security association for 83 confidentiality and integrity protection of data traffic. 85 We highlight certain �man-in-the-middle� vulnerabilities associated with 86 the composition of compound authentication methods that are being 87 proposed or already in use today. These include authentication methods 88 that are commonly encapsulated within an independently authenticated 89 tunnel that provides additional protective properties. Some examples of 90 compound authentication methods using tunnels include EAPMD5 using 91 [EAPTTLS], [EAPMSCHAPV2] using [PEAP], PANA over TLS [PANATLS], and 92 [XAUTH] with ISAKMP as part of IKE. These may also include multiple 93 authentication methods used in sequence when multiple credentials are 94 used in different stages of authentication. 96 1.1. Scope 98 This document identifies the man-in-the-middle attacks that are possible 99 when one-way authenticated tunnels are used to protect communications of 100 one or a sequence of authentication methods; and characterizes the 101 solution(s) that address the attack. The context studied is the use of 102 compound authentication for getting access from an authentication 103 server. 105 Intuitively, certain attacks may also be possible with sequences of 106 authentication methods even if they are not used within one-way 107 authenticated tunnels, but we don�t address those scenarios here. 109 We study the root causes of the attack and develop solutions using a mix 110 of policy based and cryptographic means. We also describe a reference 111 solution as a logical extension to an EAP based tunneling protocol. 112 However the same principles could be used in other classes of 113 authentication protocols as well. 115 1.2. Motivations for Compound Methods using tunnels 117 They are the following: 119 [1] Support for legacy authentication methods in new environments: 121 These new environments have brought new requirements including identity 122 privacy, mutual authentication, authentication data confidentiality, 123 integrity protection, replay and dictionary attack protection and strong 124 cipher keys for the authenticated link, especially in the context of 125 wireless networks. Secure tunneling techniques like TLS and ISAKMP with 126 strong security properties provide a way to accomplish this in an 127 extensible manner, providing longer life for easy to use legacy methods. 129 ex: Using legacy PAP that has no key derivation in 802.11 WLANs, by 130 running it inside an EAP-TTLS tunnel that provides the additional 131 protection needed. 133 [2] Consistent security properties for authentication methods: 135 Any time a new credential type is introduced, it becomes necessary to 136 construct a complete cryptographic protocol with all the necessary 137 security properties, which is not an easy task to accomplish. The 138 availability of well-reviewed tunneling protocols like TLS and ISAKMP 139 provide the opportunity to construct simpler methods for new credentials 140 that can use the protection of the tunnel to do authentication securely. 141 On a wireless network supporting multiple authentication methods, this 142 enables consistent security for all credential types. 144 ex: EAP-SIM running inside a PEAP tunnel that uses a TLS tunnel for 145 protection. 147 [3] Support for Multiple credentials 149 New system capabilities in certain cases require authentication of more 150 than one credential between two peers. This sometimes requires 151 authentication methods with different security properties to be 152 sequenced. By running the sequence inside a tunnel, it enables providing 153 a protection layer for all the methods. 155 [4] Deployment aspects for securing legacy methods: 157 The ease of deployment of secure tunneling techniques using server 158 authentication alone as in TLS and also IPSec (though they allow 159 mutual authentication), making them even more popular candidates for 160 securing the use of legacy authentication methods. 162 ex: The TLS tunnel in PEAP can be established with server authentication 163 using a server certificate. No client certificates that are unique per 164 user are required. 166 1.3. Problem Statement 168 This document suggests that compound methods have evolved from need, 169 but their composition today as it is practiced, has some 170 man-in-the-middle vulnerabilities in certain circumstances. These 171 were not known at the time these compositions were suggested but have 172 been found recently [MITM]. As compound methods have widespread 173 application, this document studies the problem, its circumstances and 174 and suggests solutions for mitigating them using a mix of protocol 175 extensions and policy based techniques. 177 1.4. Requirements language 179 In this document, several words are used to signify the requirements of 180 the specification. These words are often capitalized. The key words 181 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 182 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 183 interpreted as described in [RFC2119]. 185 1.5. Terminology 187 This document frequently uses the following terms: 189 Authenticator 190 The end of the link requiring the authentication. 192 Peer The other end of the point-to-point link (PPP), point-to-point 193 LAN segment (IEEE 802.1x) or 802.11 wireless link, which is 194 being authenticated by the Authenticator. In IEEE 802.1X, this 195 end is known as the Supplicant. We also sometimes refer to the 196 Peer as a Client of the Authentication Server also. 198 Authentication Server 199 It is an entity that provides an Authentication Service to an 200 Authenticator. This service verifies from the credentials 201 provided by the Peer, the claim of identity made by the Peer. 203 Silently Discard 204 This means the implementation discards the packet without 205 further processing. The implementation SHOULD provide the 206 capability of logging the error, including the contents of the 207 silently discarded packet, and SHOULD record the event in a 208 statistics counter. 210 Sequenced Methods 211 Authentication methods which are used in sequence one after an 212 another where each completes and the other one starts. The 213 authentication is complete after the final method in the 214 sequence is completed. 216 Tunneled Methods 217 The first method sets up a tunnel and subsequent method(s) run 218 within the tunnel. 220 Binding Phase 221 The protocol stage where validation of the peers 222 participating in the compound authentication method is carried 223 out after all the individual methods have completed. 225 Compound MAC 226 A Message Authentication Code (MAC) computed using keying 227 material from multiple methods used in a compound 228 authentication method. This is computed during the binding 229 phase. 231 Compound Keys 232 Session keys computed using keying material from multiple 233 methods used in a compound authentication method. This is 234 computed during the binding phase and can be used for 235 ciphering at the lower layers or as application specific keys. 237 2. Problem Description 239 2.1. Overview 241 The attack described in this document can be mounted against a number 242 of proposed IETF protocols, including IKE with [XAUTH],[PIC],[PANATLS], 243 [EAPTTLS], and [PEAP]. Each of these protocols supports tunneling of 244 legacy authentication methods such as CHAP [RFC1994], EAP-MD5 [RFC2284], 245 One-Time-Password (OTP) [RFC1993], Generic Token Card (GTC) [RFC2284], 246 and SecurID [SECURID] in order to provide a number of benefits, 247 including well-understood key derivation, fast reconnect, mutual 248 authentication, replay and dictionary attack protection and privacy 249 support. 251 The attack is enabled when compound authentication techniques are 252 used, allowing clients and servers to authenticate each other with one 253 or more methods encapsulated within an independently authenticated 254 tunnel. The simplest attacks occur when the tunnel is authenticated 255 only from the server to the client, and where tunneled authentication 256 techniques are permitted both inside and outside a tunnel using the 257 same credential. The tunnel client, having not proved its identity, 258 can act as a man-in-the-middle, luring unsuspecting clients to 259 authenticate to it, using any authentication method suitable for use 260 inside the tunnel. The attacks are possible even though the tunnels 261 created within these protocols utilize well-analyzed protocols such as 262 ISAKMP [RFC2408] and TLS [RFC2246], because mutual authentication 263 (supported within both protocols) is not used. 265 Since the initial authentication only authenticates the server to the 266 client, or provides only an indication of group membership (where group 267 pre-shared keys are used within IKE), and because the keys derived 268 within ISAKMP and TLS are not subsequently included within the tunneled 269 authentication methods, there is no demonstration that the ISAKMP/TLS 270 endpoints are the same as the tunneled authentication endpoints. Where 271 authentication techniques are enabled both inside and outside the 272 tunnel, such as when they are in use for multiple purposes (e.g. dialup 273 or web authentication) then an attacker can induce an unsuspecting 274 client to authenticate, then tunnel the authentication within 275 [XAUTH],[PIC],[PANATLS],[EAPTTLS] or [PEAP]. 277 For the purposes of the attack, it makes no difference whether the 278 authentication method used inside the tunnel supports mutual 279 authentication or not. The vulnerability exists as long as both sides 280 are not required to demonstrate participation in the previous "tunnel 281 authentication" as well as subsequent authentications, and as long as 282 keys derived during the exchange are not dependent on material from 283 *all* of the authentications. 285 Thus it is the lack of client authentication within the initial security 286 association, combined with key derivation based on a one-way tunnel 287 authentication, and lack of "cryptographic binding" between the security 288 association and the tunneled authentication method that enables the 289 vulnerability. In addition, it is necessary for the same authentication 290 credentials to be used inside and outside of tunnels. 292 Despite the prevalence of man-in-the-middle vulnerabilities within IETF 293 protocol proposals, it should be noted that these attacks are not the 294 result of design flaws within IKE [RFC2409], TLS[RFC2246], or EAP 295 [RFC2284]. 297 IPsec VPN implementations which require strong mutual authentication 298 within the tunnel prior to permitting subsequent authentication are not 299 vulnerable to this attack. For example, when L2TP over IPsec [RFC3193], 300 or IPsec tunnel mode [DHCPIPsec], is used with certificate 301 authentication or unique pre-shared keys, the attack is not possible. By 302 requiring strong mutual authentication via certificates or a unique pre- 303 shared key, the tunnel server obtains the ability to verify the identity 304 of the tunnel client. The tunnel server may then subsequently apply 305 access control in order to limit authentication within the established 306 tunnel. 308 However, where group pre-shared keys are used (as is common in IKE Main 309 Mode implementations that support clients with dynamically allocated IP 310 addresses), followed by one-way authentication mechanisms such as CHAP 311 [RFC1994], the vulnerability is exposed. Since group pre-shared keys 312 only determine group membership but authenticate neither the client nor 313 the server, it is not possible for the server to enforce access controls 314 on individual members of the group. Since CHAP is a widely used 315 authentication method, an attacker can easily gain access to a client 316 willing to engage in CHAP authentication. This allows any client with 317 knowledge of the group pre-shared key to act as a man-in-the-middle for 318 another member of the group. 320 The concept of EAP tunneling has been introduced by recent work-in- 321 progress such as [PIC], [PANATLS], [EAPTTLS], and [PEAP]. However, these 322 proposals have not yet been published as RFCs, and are not yet widely 323 deployed. 325 Note that man-in-the-middle vulnerabilities are not a necessary 326 consequence of "credential reuse". For example, they need not 327 necessarily occur where the same authentication credentials are used in 328 accessing the network via multiple media. For example, L2TP [RFC2661], 329 when used in "compulsory tunneling", assumes that the same credentials 330 are used for both PPP and VPN access. PPP dialin users are then 331 permitted to access a VPN by tunneling PPP packets from the network 332 access server (NAS) to the VPN server. This is mainly because, on 333 physically secure networks, unlike wireless networks, its harder to 334 become a man-in-the-middle. 336 2.2. Attack scenario 338 This section describes how man-in-the-middle vulnerabilities can be 339 exploited, as well as discussing the underlying causes of the attacks. 340 We use a single example to highlight the problem. But the weakness of 341 the composition of tunnel-based compound authentication methods should 342 become apparent even in a broader context using this example. 344 The major scenario for the attack is a one-way authenticated tunnel 345 encapsulating subsequent authentication methods. In this scenario, the 346 client and server first establish a tunnel, then include within the 347 tunnel one or more authentication method(s). The attacker first poses 348 as a valid client to the server and establishes a tunnel that is 349 authenticated only on the server end, obtaining tunnel keys. Since 350 these keys protect a conversation between an attacker and a server, the 351 strength of the key derivation is not relevant. 353 For the purposes of exploiting the vulnerability, it does not matter 354 whether the tunneling protocol is IKE [RFC2409] authenticated via a 355 group pre-shared key; PIC [PIC], which uses ISAKMP [RFC2408] with one- 356 way authentication; or TLS [RFC2246] with server-only authentication, as 357 used with [PANATLS], [EAPTTLS] or [PEAP]. The effect is the same - a 358 tunnel that does not provide mutual authentication of the tunnel 359 endpoints. 361 Once the attacker has established a tunnel to the server, it seeks to 362 induce clients to connect to it. This can be accomplished by having the 363 attacker masquerade as a legitimate 802.11 access point (AP) or Ethernet 364 switch implementing [IEEE8021X], a PPP Network Access Server (NAS), a 365 SIP server supporting CHAP, or a VPN server using a protocol such as 366 Client <-|Rogue NAS | NAS Auth Server 367 | Attacker |-> 368 | | | | 369 | | | | 370 | | Tunnel establishment w/ | 371 | | Server Authentication (1) | 372 | |<========================================>| 373 | | | | 374 | (Non-Authenticated | (Authenticated 375 | end of tunnel) | end of tunnel) 376 | | | | 377 | +--------------+ | +--------------+ 378 | | Tunnel | (2) | | Tunnel | 379 | | Keys Derived | | | Keys Derived | 380 | +--------------+ | +--------------+ 381 | | | | 382 | |..........................................| 383 | | Tunnel | 384 | |..........................................| 385 | | (Encrypted using Tunnel keys) | 386 | | | | 387 | | | | 388 | Tunneled authentication method (3) | 389 |<==============================================================>| 390 | | | | 391 | | | | 392 +--------------+ | | +--------------+ 393 | Method | | | | Method | 394 | Keys Derived | (4) | | | Keys Derived | 395 | and used. | | | | Not Used. | 396 +--------------+ | | +--------------+ 397 | | | | 398 | | |<===tunnel keys=========| 399 | | | | 400 | | Client's session| | 401 | | stolen | | 402 |====================+|<===============>| | 403 | Data || | | 404 | dropped v| | | 406 Figure 1 - Man-in-the-middle attack on a one-way authenticated tunnel 408 PPTP [RFC2637]. For the purposes of the attack, it is necessary that 409 the client be induced to authenticate to the attacker using an 410 authentication mechanism permitted within the tunnel. It is also 411 necessary that the credentials within the client protocol and the 412 tunneled authentication protocol be the same, so that the 413 authentication mechanism remains valid when encapsulated within the 414 tunnel. 416 Figure 1 illustrates the attack, for the case where the attacker acts as 417 a rogue NAS or Access Point. In step 1, the attacker creates a tunnel 418 with the authentication server. This can occur directly in [PIC] or 419 [XAUTH] or through a NAS using EAP [RFC2284]. In step 2, tunnel keys are 420 derived, using server-only authentication via protocols 421 such as ISAKMP [RFC2408], IKE [RFC2409] with group pre-shared keys or 422 TLS [RFC2246]. Since the tunnel is between the attacker and the server, 423 both the server and attacker possess the keys. 425 In the third step, the client connects to the rogue NAS or AP, and the 426 attacker tunnels the authentication method between the client and 427 server. The tunneled authentication method may or may not derive keys, 428 but if it does, then in the fourth step, the method keys are derived on 429 the client and the server. Since the attacker does not obtain the 430 method keys, it is not able to decrypt traffic sent between client and 431 server. However, while the client may use the method keys, the server 432 will typically use only tunnel keys, which have been obtained by the 433 attacker. 435 In the last step, the attacker obtains access to the server, using the 436 successfully tunneled authentication and the tunnel keys. The attacker 437 does not have access to client data, since it is encrypted with the 438 method keys. As a result, it will typically discard the data sent by the 439 client, who will eventually disconnect due to a lack of response. Since 440 the attacker has accomplished its mission, continued interaction with 441 the client is not necessary unless reauthentication is required. 443 The attack described is also possible, if the tunnel server is not the 444 final authentication server. Now in that case the vulnerability is even 445 more serious because the inner method could be running to an untrusted 446 network, and it assumes, that the tunnel server and the final 447 authentication server have a trust relationship which it cannot validate. 448 EAPTTLS typically suggests this model and care must be taken while 449 deploying this intermediate tunnel termination model to prevent such 450 man-in-the-middle attacks. 452 2.3. Conditions for the Attack 454 The following are some causal conditions that are necessary for this 455 attack to be possible. We label these conditions using a prefix CC 456 and refer to them during the solution description. 458 [CC-A] Client and Authentication server policy allowing client 459 credentials to be used both within one-way server-authenticated tunnels 460 and outside them. 462 ex: An authentication server supports EAP-MD5 using EAP-TTLS and also 463 supports the same method when used without EAP-TTLS. This can occur 464 when clients are being upgraded at different times or when upgrades are 465 not universal. If the identities used were different in each case, then 466 the server would be able to detect fraudulent use and prevent the 467 attack. 469 [CC-B] The ability for a man-in-the-middle to pose as a legitimate 470 client to the authentication server as well as a legitimate 471 authenticator to the client and perform both functions simultaneously. 473 ex: A 802.11 WLAN client that also has the capabilities to function as 474 an AP and functions as one entity with malicious intent. This is 475 relatively easy to accomplish given the low cost of equipment and tools. 476 This may be relatively more difficult to accomplish on dial-up RAS servers. 478 [CC-C] The inability of the authentication server to validate that the 479 client authentication occurring inside a tunnel originated at the 480 same endpoint as the tunnel itself. 482 ex: When an EAP method runs inside of EAP-TTLS or PEAP, the tunnel 483 endpoint that is not authenticated really doesn�t prove that it 484 originated the inner EAP conversation as link is protected only by the 485 tunnel keys. 487 [CC-D] The data link being authenticated is always confidentiality- 488 and/or integrity-protected using tunnel keys instead of the keys 489 derived from the client method running inside the tunnel. 491 ex: The keys from any EAP method running inside of EAP-TTLS or PEAP are 492 not used today. 494 3. Potential Solutions 496 This section describes potential solutions to the man-in-the-middle 497 attacks prevously described. This includes a discussion of solution 498 criteria, concepts, mechanisms, approaches and their scope. Some of the 499 limitations of these solutions are also captured. 501 3.1. Solution Criteria 503 The following are some of the criteria for a potential solution. 505 Backwards compatibility 506 A solution MUST NOT require modification of existing 507 authentication methods. Since tunneling is used in order 508 to prolong the life of legacy authentication techniques, 509 requiring replacement of existing methods across the 510 board is likely to be unacceptable. 512 Simplicity A solution SHOULD add minimal round trips to the 513 authentication exchange and be modest in its 514 computational cost. 516 Protocol compatibility 517 Given that tunneling techniques are used with well- 518 established security protocols such as IKE [RFC2409], 519 ISAKMP [RFC2408], TLS [RFC2246], and RADIUS [RFC2865], a 520 solution MUST NOT require changes to these protocols. 522 Forward evolution 523 The solution SHOULD be compatible with authentication 524 methods supporting mutual authentication and key 525 derivation. It is acceptable if the solution cannot 526 be uniformly applied for providing security for tunneling 527 of one-way authentication methods that do not derive 528 keys, such as CHAP, EAP-MD5,OTP, Generic Token Card, or 529 SecurID. As described earlier, these methods are already 530 vulnerable to connection hijacking. 532 Architectural compatibility 533 Solutions MUST NOT require fundamental architectural 534 changes to established technologies such as network 535 access authentication. Since these technologies are 536 already widely deployed, such changes would be likely to 537 be unacceptable. 539 3.2. Solution Concepts 541 There are several concepts at our disposal for mitigating this attack. 542 As the root problem was missing proof that both peers actually performed 543 all the individual methods in the compound authentication, one solution 544 is to provide just that. The other solutions include restrictions on the 545 implementation of the compound authentication methods so as to avoid 546 the causal conditions described in section 2.3 (CC-A...CC-D). 548 So here we list all the concepts and some of the limitations of each. 550 [S1] Provide proof that the unauthenticated tunnel endpoint is a real 551 peer and not the man-in-the-middle attacker using cryptographic 552 binding. This prevents condition CC-C. 554 This solution works for all key-deriving methods used inside a 555 tunnel. And this is the primary solution described 556 in this document. This will not work for non-key-deriving methods 557 without breaking at least one of our solution criteria. So we 558 only consider this solution for key-deriving methods. 560 [S2] Guarantee that the same peer credential is never usable inside and 561 outside a tunnel using server and client policy. This prevents 562 condition CC-A. 564 This solution actually works for all methods, but is sometimes hard 565 to deploy, due to legacy deployments, and since clients and servers 566 need to be synchronized for proper policy enforcement. An 567 additional problem with this solution is the manageability issues 568 due to the multiple credentials that have to be managed by the same 569 client and server. 571 [S3] Prevent an Access Point (or Base station)/Client to be ever 572 manipulated to perform both functions and become an attacker. 573 This prevents condition CC-B. 575 This solution is possible to accomplish in a very limited context, 576 like under the watchful eyes of law enforcement. But due to the 577 wide availability of hacking tools, it is extremely expensive to 578 implement in the real world. 580 [S4] Provide a mechanism for all method secrets in a compound 581 authentication to be used for deriving link layer cipher keys. This 582 prevents condition CC-D. 584 This solution also, just like [S1], will only work for only key- 585 deriving methods. For non-key-deriving methods, this won't work 586 as the only choice is to use tunnel keys to meet the 587 solution criteria. 589 For realizing concepts S1 and S4 we use cryptographic means. S2 is 590 realizable just using policy techniques on the client and server ends. 591 Thus we have solutions that can prevent all the causal conditions 592 except CC-B as solution S3 is not viable. 594 3.3. Solution Mechanisms 596 The solution mechanisms include a mix of policy based techniques and 597 using cryptographic means. Assuming that compound methods are of 598 interest, the policy based techniques have significant relevance for 599 non-key deriving (possibly legacy) authentication methods where 600 cryptographic binding is not necessarily practical. These involve 601 the following mechanisms: 603 [1] Providing separate credentials for a user identity supported inside 604 and outside tunnels. 606 This enables the server to know when a credential that is not 607 intended for use inside a tunnel is being used. This maybe done 608 by an attacker and appropriate action can be taken. Though this is 609 restrictive and worsens usability, it maybe easy to deploy. 611 [2] Enforce client and server policy to always use authentication 612 methods inside tunnels. 614 This could have more significant deployment issues, but is a better 615 option if possible, as it enables the benefits of compound methods 616 to be realized more effectively. 618 For non-key deriving methods, if they are modifiable, then using a 619 signal to indicate when they are running inside a tunnel would also 620 prevent the attack. This works because the server is able to 621 distinguish between an attacker diverting a method into a tunnel versus 622 a client method intentionally initiated inside a tunnel. However such 623 signals need protection from spoofing. 625 The mechanisms to provide cryptographic proof involve combining some 626 knowledge unknown to the attacker derived from each authentication 627 method involved in a compound authentication to prove that both parties 628 are the real peers. This knowledge may be in the form of keying material 629 available to both parties. This information can be used as part of a 630 two-stage solution. 632 [Stage 1] Binding Phase Exchange with Compound Keyed MACs 634 Here we execute an additional 2-way handshake to the tunneling protocol 635 or base protocol, we call it the �Binding Phase Exchange�. This phase is 636 entered only if the server knows that all the individual 637 authentication methods inside the tunnel have completed. (There maybe 638 some situations where binding maybe carried out after each inner method 639 completes. However that is beyond our scope at the moment.) 640 In case of the tunnel server endpoint not being the final 641 authentication server, it has possession of the inner method keys if 642 they are available. The keys from all the inner methods and the tunnel 643 keys are used to compute keyed compound MACs as described in section 4.2. 644 The validation of the compound MACs protects against the 645 man-in-the-middle attack, as the attacker is unable to get any of the 646 inner method keys. Here the server sends a Binding request B1 with 647 a B1_MAC and the client validates it. If the message is valid the client 648 responds with the B2 message that also has a B2_MAC associated with it. 649 If the server successfully validate the B2_MAC, then it can be certain 650 that there was not man-in-the-middle. 652 | Binding Request(B1)[S_NONCE...S_MAC] | 653 |<===============================================================| 654 | | 655 | | 656 | Binding Response(B2)[C_NONCE....C_MAC] | 657 |===============================================================>| 658 | | 660 Figure 2: Binding Phase Message Flows 662 For clarity, we name all the keys and nonce values used in the two 663 stages. The input keys for the binding phase are TSK and the several 664 ISKs, one from each inner method. These keys should be available before 665 the binding phase exchange can be carried out. The details of the 666 derivation of these keys are in section 4.2 668 TSK Tunnel Session Key. This is part of the base keying material 669 available from the tunneling protocol. It should be at least 670 256 bits and derived ensuring key separation for binding, 671 non-binding, transmit and receive encryption and integrity 672 purposes. 674 ISK Inner Session Key for the inner authentication method running 675 inside the tunnel. Each inner method that derives keys will 676 have an non-zero ISK. It could be of variable length depending 677 on the particular method. But should be at least 64 bits. The 678 key derivation process in section 4.2 is capable of handling 679 variable length ISKs as they are input as strings to the PRFs. 681 S_NONCE 256 bit random number used for computing the Compound keyed 682 MAC values for the B1 message (B1_MAC) and the B2 message 683 (B2_MAC). 685 C_NONCE 256 bit random number used for computing the Compound keyed 686 MAC value for the B2 message (B2_MAC). 688 The output keys generated as part of the cryptographic binding process 689 are the MAC keys CMK_B1 and CMK_B2 and the CSK. CMK_B1 and CMK_B2 are 690 needed for computing the B1_MAC and B2_MAC repectively in stage 1. The 691 CSk is needed for stage 2. 693 CMK_B1 Compound MAC key derived for the B1 message MAC (B1_MAC) 694 computation. It is 128 bits in length. It is derived using 695 two nonces the S_NONCE and the C_NONCE both of which are 696 256 bit random numbers and also additional parameters that 697 representative of all the inner methods. 699 CMK_B2 Compound MAC key derived for the B2 message MAC (B2_MAC) 700 computation. It is 128 bits in length. This is derived 701 with the S_NONCE which is a 256 bit random number. 703 CSK Compound Session Key, which is the bound key generated for 704 use as the base keying material for the link layer. It is 705 192 bytes in length. The different portions of the CSK 706 are partitioned into 32 byte chunks and specified for 707 different uses. 709 Here we descibe the stage 1 message exchange related aspects. 711 B1. Binding Request 713 This message is a request sent from the tunnel server to the 714 tunnel client to perform binding. Among other parameters it 715 includes a 256 bit random number, ie. the S_NONCE and a compound 716 keyed MAC, B1_MAC computed by the server over the entire 717 B1 message. There is a compound MAC server key CMK_B1, derived 718 for computing the B1_MAC on the server and another equivalent one 719 derived on the client for validating it after receiving the 720 message. The S_NONCE is used in the derivation of this CMK_B1 in 721 addition to the bound keying material (ISK1...ISKn) from all the 722 inner methods inside the tunnel and the tunnel keys (TSK). So if 723 the client and server have all the keying material from all the 724 methods, the B1_MAC validation on the client should succeed and 725 the response message B2 will be sent. 727 In the case of invalid B1_MAC, the client need not send a response 728 and can disconnect as a potential man-in-the-middle could be 729 present and be modifying packets. Also this message as it will be 730 enacapsulated in the underlying protocol, the retry policies on 731 the server can be specified as part of that protocol which 732 initiates binding. 734 B2. Binding Response 736 This is only sent as a response to B1 and includes a B2_MAC and 737 also additional parameters including a 256 bit random number 738 called the C_NONCE. The B2_MAC is a compound keyed MAC calculated 739 over the entire B2 message. The derivation of B2_MAC is explained 740 in section 4.2. A client MAC key is derived for computing this 741 B2_MAC. To prevent against replay attacks, the CMK_B2 is derived 742 using the S_NONCE and the C_NONCE and can only be derived after 743 the B1 message is received. 745 If the B1 message has an invalid B1_MAC, this CMK_B2 MAC key 746 derivation is not possible and the B2 message cannot be safely 747 constructed. So no response is sent. The server that does not 748 receive a B2 response can timeout and disconnect or perform a 749 retry. It is expected to use a new S_NONCE for every retry. 751 If the Binding Phase successfully completes with the server validating 752 the B2 message, then the compound authentication is complete. More 753 details this binding phase exchange is described in section 4.1. 754 The CMKs should provide enough strength for the MACs so that it cannot 755 be broken in the time taken to authenticate. ie. seconds. Its important 756 to remember that the binding phase exchange when performed as the 757 final step to to complete authentication should include the protected 758 success/failure indication using the Result TLV. This is described in 759 section 4.1. Also other meta information about the methods exchanged 760 can be used for policy validation or fraud detection purposes. However 761 the protection from the attack is mainly from the MACs and not from 762 the other parameters. 764 [Stage 2] Compound Session Keys Generation 766 In stage 2 we generate combined keys that are session keys for 767 link layer confidentiality and integrity protection needs.These are 768 computed using from all the inner method keys if they are available 769 and the tunnel keys. The resultant keys called Compound Session Keys 770 (CSKs) are provided to the link layer for ciphering and integrity 771 protection. These keys provide the assurance that all packets 772 are being exchanged between the real peers and no man-in-the-middle is 773 actually decrypting the conversation. The Compound Session Key 774 derivation is specified in section 4.2. 776 Though from our analysis, compound MACs used in the Stage 1 Binding 777 Phase Exchange provide the necessary protection, we argue that for 778 additional protection one could also use Stage 2. 780 Performing Stage 1 prevents a man-in-the-middle from gaining 781 authenticated access. It also prevents false authenticated states 782 which could result in a Denial-of-Service attack that could result 783 if only Stage 2 is done. 785 Only implementing Stage 2 does not require additional round trips, but 786 it enables the man-in-the-middle to authenticate, although not to 787 obtain keys used for subsequent link-level authentication and encryption 788 of the data. This implies that the client will only discover an attack 789 when it discovers that it is unable to decipher the incoming data 790 stream. As a result, Stage 2 is probably not sufficient by itself. 792 3.4. Thwarting the attack 794 Figure 3 shows how by adding the Binding Phase Protocol Exchange 795 the attack is prevented as the man-in-the-middle attacker cannot provide 796 the correct B1_MAC that the client will validate against in the B1 797 message in step (5). Also the B2 message cannot be successfully sent 798 by the attacker and the server will fail a false B2 message, that does 799 not possess a valid B2_MAC. Hence the compound session keys (if stage 2 800 is used) or tunnel keys are not sent to the Authenticator by the server. 801 Thus the man-in-the-middle attack is prevented. 803 Client <-|Rogue NAS | NAS Auth Server 804 | Attacker |-> 805 | | | | 806 | | | | 807 | | Tunnel establishment w/ | 808 | | Server Authentication (1) | 809 | |<========================================>| 810 | | | | 811 | (Non-Authenticated | (Authenticated 812 | end of tunnel) | end of tunnel) 813 | | | | 814 | +--------------+ | +--------------+ 815 | | Tunnel | (2) | | Tunnel | 816 | | Keys Derived | | | Keys Derived | 817 | +--------------+ | +--------------+ 818 | | | | 819 | |..........................................| 820 | | Tunnel | 821 | |..........................................| 822 | | (Encrypted using Tunnel keys) | 823 | | | | 824 | | | | 825 | Tunneled mutual authentication method (3) | 826 | | w/key derivation| | 827 |<==============================================================>| 828 | | | | 829 | | | | 830 +--------------+ | | +--------------+ 831 | Compound | | | | Compound | 832 | Keys Derived | (4) | | | Keys Derived | 833 +--------------+ | | +--------------+ 834 | | | | 835 | | Binding Request | | 836 | | (5) (B1_MAC) | | 837 |<===============================================================| 838 | | | | 839 | | Binding Response| | 840 | | (6) (B2_MAC) | | 841 |===============================================================>| 842 | | | | 843 | | | Attack detected | 844 | | | No keys(CSK/TSK)sent | 845 | | | | 846 | | | Failure | 847 | | | <======================| 849 Figure 3 - Man-in-the-middle attack thwarted by compound MAC and 850 compound session keys 852 3.5. Solution approaches 854 Stages 1 or 2 can be implemented in different ways: 856 EAP In this approach, the binding phase exchange of a compound 857 keyed MACs is supported within EAP, by implementing the 858 exchange as a new EAP method occuring after authentication is 859 complete. Tunnel keys are provided by the tunneling protocol 860 to the EAP layer in order to enable computation of the 861 compound keyed MACs and compound session keys. Since existing 862 EAP implementations already enable EAP methods to provide 863 keying material to the EAP layer, such an interface typically 864 already exists. This approach is general in that it applies to 865 any tunneling technique. 867 Tunneling method 868 In this approach, the tunneling method acquires keying 869 material derived by the underlying authentication methods, in 870 order to enable computation of the compound keyed MACs and 871 compound session keys. Since existing tunneling techniques 872 typically do not provide an interface for receiving keying 873 material from authentication methods, this approach will 874 typically require some re-architecture of existing 875 implementations. It also has the disadvantage of requiring 876 changes to each tunneling method, and as a result is not as 877 general as an EAP-based solution. Given the prevalence of the 878 attacks described within this document, it would represent a 879 considerable burden on the security community to review 880 changes to each individual tunneling approach. However, such 881 an approach may be able to take advantage of properties of the 882 underlying tunnel technology, such as the ability to have more 883 than one packet in transit at a time. 885 EAP methods 886 In this approach, keys derived from previous EAP methods are 887 incorporated into the authentication calculations of 888 subsequent methods. Since existing interfaces only support the 889 export of keys by EAP methods, not importation, some 890 rearchitecture is required in this approach. In addition, this 891 approach requires modification of existing EAP methods, which 892 will create deployment barriers. However, this approach may 893 be applied even to methods which support only one-way 894 authentication and do not generate keys. As mentioned 895 earlier the use of signals to indicate the explicit intention 896 to run inside a tunnel can be another approach to mitigating 897 the problem. However the signals have to be protected from 898 spoofing and that is not easy without some keying material 899 being available. 901 Based on the pros and cons of each approach, we recommend a solution 902 that applies to all EAP methods either in the Tunneling method or 903 in the EAP base protocol. 905 3.6. Solution scope 907 The policy based mechanisms we described in the previous section will 908 work for any tunneling protocol, but it can be a bit restrictive. 910 The cryptographic mechanisms work for all key deriving methods and 911 can be implemented in the EAP base protocol or the tunneling protocol 912 as extensions. 914 When a mix of key deriving and non-key deriving methods are used inside 915 the tunnel the nature of protection largely relies on the key deriving 916 methods. If the non-key deriving methods are not properly managed 917 through policy mechanisms as described earlier and if they play a 918 significant role in the compound authentication success/failure 919 condition then the vulnerability still exists. But the attacker may not 920 be able to take control of the network access session. 922 However it important to note that, downgrade attacks are possible 923 with modified EAP or tunneling protocols as attackers can always try 924 to get the server to connect to a client tunnel that does not support 925 cryptographic binding or the policy mechanisms. So appropriate server 926 policies are needed to either not support older versions of the 927 protocols that do not have the enhancements or have counter measures 928 in place to deal with potential fraud. 930 4. Reference Solution in Tunneling Protocol 932 Here we describe a reference solution using cryptographic binding 933 that can be implemented in a tunneled EAP-based authentication protocol 934 like PEAP to thwart man-in-the-middle attacks. This involves 935 incorporating a binding phase handshake after all the inner EAP methods 936 complete to provide cryptographic proof that the peers indeed took part 937 in all the authentication methods. We use compound keyed MACs for these 938 messages using keys derived from the individual methods combined with 939 the tunnel keys. We also derive cryptographically bound session keys 940 that can be used for ciphering at the link layer. Though we limit our 941 discussion to PEAP, the principles used here can be applied to other 942 compound authentication protocols as well. Here for simplicity we 943 assume the tunnel server endpoint is the final authentication server. 945 Its also very important to note that the tunnel protocol needs to do 946 proper version negotiation upfront to prevent downgrade attacks. In the 947 case where the tunnel server is not the final authentication server, 948 this binding phase is started only after the tunnel server gets the 949 inner method keys from the final authentication server. This also 950 assumes that the tunnel server and authentication server have a security 951 association that enables them to share these keys and the tunnel server 952 is capable of holding the authentication state till the binding phase 953 is complete. 955 4.1 Binding Phase Handshake 957 This 2-way handshake for cryptographic binding can be added as a tunnel 958 protocol extension. This handshake is started when the server makes 959 a determination that the last inner authentication methods have 960 completed. The following meta information is used in both the Binding 961 Request (B1) and Binding Response (B2) messages. 963 - Highest version number supported by the tunnel client and tunnel 964 server 966 - Information of each inner authentication method. Method type, version, 967 size of keys used for CMK computation and identity used to 968 authenticate both client and server. 970 - Type of media being used for the authentication. ex: RADIUS 971 NAS-Port-Type. 973 The version number will prevent roll back attacks between tunnel 974 protocol versions that support cryptographic binding, but not for other 975 implementations that do not support it. 977 The server having possession of all the inner method keys and also 978 the tunnel keys, and including a 256 bit server Nonce (S_NONCE), 979 computes a compound MAC server key (CMK_B1). This and other 980 cryptographic derivations are described in the next section. Then the 981 server sends a Binding Request Message (B1) that has a server-computed 982 compound keyed MAC (B1_MAC) associated with it. This message body 983 includes the version number of the protocol extension, 984 a 256 bit S_NONCE, a RESULT_TLV that provides protected success/failure 985 indication, one METHOD_IDENTITY_TLV each for all the methods that were 986 exchanged inside the tunnel and the METHOD_IDENTITY_TLV for the tunnel 987 server. The B1_MAC is computed over this entire message body by setting 988 the MAC field bits to zero. 990 | Binding Request(B1) | 991 |<===============================================================| 992 | [VERSION,S_NONCE,RESULT_TLV, METHOD_IDENTITY_TLV.....,B1_MAC] | 993 | | 994 | | 995 | Binding Response(B2) | 996 |===============================================================>| 997 | [VERSION,C_NONCE,RESULT_TLV, METHOD_IDENTITY_TLV.....,B2_MAC] | 998 | | 1000 Figure 4: Binding Phase Message Flows (Success Case) 1002 The client on receiving the B1 message will first compute its own CMK_B1 1003 using the S_NONCE and its own knowledge of all the inner method keys and 1004 the tunnel keys. Then it validates the B1_MAC sent from the server by 1005 recomputing it over the B1 message body with MAC bits set to zero. If 1006 the B1 message is valid, it responds with a Binding Response (B2) 1007 message that includes a compound keyed MAC (B2_MAC). Before it responds, 1008 it first computes a MAC key (CMK_B2), for computing the B2_MAC, 1009 using the tunnel keys, all the inner method keys, the S_NONCE received 1010 from the server and a locally derived 256 bit client Nonce (C_NONCE). 1011 The B2 message body is similar to the B1 message, and includes a version 1012 number of the protocol extension, a 256 bit C_NONCE, a RESULT TLV that 1013 provides acknowledgment for the protected success/failure indication, 1014 one METHOD_IDENTITY_TLV each for all the methods that were exchanged 1015 inside the tunnel and the METHOD_IDENTITY_TLV for the tunnel server 1016 that was known to the client (it could include the FQDN or the server 1017 name in the PEAP server certificate). A client side MAC (B2_MAC) is 1018 computed for this message body using the CMK_B2, with the MAC bits set 1019 to zero, and is included in the B2 message. figure 4 shows both the 1020 messages in the success case. 1022 There are several conditions that can cause invalid B1 or B2 messages, 1023 they include the following: 1025 � Invalid B1_MAC or B2_MAC 1026 � Incompatible protocol version 1027 � Invalid RESULT_TLV 1028 � Invalid METHOD_IDENTITY_TLV 1030 A man-in-the-middle attack can cause these conditions to occur. More 1031 details on detecting these conditions are described as part of the 1032 message formats in section 4.3. Here we describe how they are handled 1033 as the failure authentication cases. 1035 [1] Client receiving an invalid B1 message 1037 If the client finds the Binding Request (B1) message to be invalid, it 1038 doesn�t send any response. It can make a decision to drop the connection 1039 at this time, as it is not certain, that its talking to the right server. 1040 Any other Binding Requests (B1) messages if they arrive subsequently, 1041 and if they are valid, are responded to using proper Binding Response 1042 (B2) messages. This is to allow for packet loss during the server retry 1043 time period. The retry of packets is handled by the EAP layer; and is 1044 transparent to the EAP methods. The packets should not be different 1045 because the media is unreliable. 1047 [2] Client never receiving a B1 message 1049 In this case, client having waited for sufficient time (retry time 1050 period) will time out and can drop the connection. 1052 [3] Server receiving an invalid B2 message 1054 If the server receives an invalid Binding Response (B2) message, it can 1055 decide to drop the connection, as its not certain that it is talking to 1056 the right client. Any further Binding Responses are ignored, even if the 1057 server had sent out more than one B1 messages. 1059 [4] Server never receiving a B2 message 1061 In this case, the server will time out and can do a retry, up to 3 times 1062 with new B1 messages. It must use a new S_NONCE every time it sends a 1063 new message. 1065 4.2 Compound MAC and Session Key derivation 1066 The input for the cryptographic binding we use includes the Tunnel 1067 Session Keys (TSK), and the inner method provided session keys, ISK1, 1068 ISK2,�ISKN, that belong to the N authentication methods used inside the 1069 tunnel. These keys may all be of varying sizes. The sizes used for this 1070 computation need to be input to the METHOD_IDENTITY_TLV as described in 1071 section 4.3. 1073 The Compound MAC for the client (the B2_MAC) and the server (the B2_MAC) 1074 are derived from two different MAC keys called CMK_B2 and CMK_B1 1075 respectively. A compound session key (CSK) is also derived on both the 1076 client and server for cryptographic purposes. If the binding phase is 1077 implemented, that alone prevents the man-in-the-middle attacks, so the 1078 CSKs are really not needed and the tunnel session keys can still be used 1079 for ciphering purposes. 1081 The CMK_B1, CMK_B2 and CSK are derived as follows for the PEAP protocol. 1083 PEAP tunnel session key (TSK); TSK is calculated using the EAP-TLS 1084 algorithm (RFC2716 section 3.5). and is 192 octets. 1086 ISK1��ISKn are the EAP inner session keys obtained from methods 1 to n. 1087 In some cases, ISKi, for some i, may be the null string (""). 1089 We use the P_SHA-1 PRF specified in the TLS specification [RFC2246]. 1091 Compound MAC Key derivation algorithm: 1093 Take the second 256 bits of TSK (192-octet TLS/SChannel output) 1095 IPMK0 = TSK 1097 for j = 1 to n do 1099 IPMKj = PRF(IPMK(j-1),"Intermediate PEAP MAC key", ISKj); 1101 CMK_B1 = PRF(IPMKn,"PEAP Server B1 MAC key",S_NONCE) 1103 CMK_B2 = PRF(IPMKn,"PEAP Client B2 MAC key",C_NONCE|S_NONCE) 1105 ("|" denotes concatenation) 1107 The pseudorandom function PRF(k,label,string) is computed as 1108 P-SHA1(k,label|string) (or substitute, if necessary, any other PRF that 1109 produces output of sufficient length). Here the outputs are taken to 1110 as many bits as are necessary (typically 256 bits for a key). 1112 Compound Session Key Generation (PEAP encryption key): 1114 The following function provides the necessary keying material. 1116 CSK = PRF(IPMKn, "PEAP compound session key", C_NONCE|S_NONCE, 1117 OutputLength) 1119 where 1121 PRF(Key, Label, String, OutputLength) 1122 Output ::= NULL 1123 for i = 0 to (OutputLength/20 - 1) do 1124 Output ::= Output | P-SHA1(Key, Label | String | i | OutputLength) 1125 return 1st OutputLength octets of Output 1127 ("|" denotes concatenation) 1129 Here the outputs are taken to as many bits as are necessary. 1130 (typically 256 bits for a key). 1132 4.3 Binding Message Formats 1134 There seems to be a assumption below that binding packets are only 1135 transferred in the final ACK packet inside PEAP. The Binding messages 1136 can be transferred in the final protected ACK or in other EAP-TLV 1137 packets inside PEAP. It can be transferred after each EAP method if 1138 so desired. Only the final ACKed packet can contain the Result TLV. 1139 All other packets do not contain a Result TLV. 1141 The Binding Phase uses messages for Binding Request (B1) and Binding 1142 Response (B2) are defined using TLVs. They contain the TLV_RESULT 1143 that provides success/failure indications, TLV_METHOD_IDENTITY that 1144 provides meta information about an EAP method and is specifically 1145 designed for use in binding. For non-key generating inner EAP-methods 1146 in a tunnel, the TLV_METHOD_IDENTITY is used for achieving binding. 1148 We first describe the TLVs used and then define the B1 and B2 message 1149 formats. The generic TLV format is defined in [TLV] in section 3.1 1150 and duplicated below. 1152 0 1 2 3 1153 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 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 |M|R| Type | Length | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Value... 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 M 1162 0 - Non-mandatory TLV 1163 1 - Mandatory TLV 1165 R 1166 Reserved, set to zero (0) 1168 Type 1170 A 14-bit field, denoting the attribute type. Allocated AVP Types 1171 include: 1172 0 - Reserved 1173 1 - Reserved 1174 2 - Reserved 1175 3 - Result TLV (Acknowledged Result) 1177 Length 1179 The length of the Value field in octets. 1181 Value 1183 The value of the object. 1185 Result TLV: 1187 This is defined in draft-hiller-eap-tlv-00.txt [ref] in section 3.2 1188 and duplicated below. 1190 The Result TLV provides support for acknowledged Success and Failure 1191 messages within EAP. It is defined as follows: 1193 0 1 2 3 1194 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 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 |M|R| Type | Length | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Status | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 M 1203 1 - Mandatory TLV 1205 R 1207 Reserved, set to zero (0) 1209 TLV Type 1211 3 - Success/Failure 1213 Length 1215 2 1217 Status 1219 The status field is two octets. Values include: 1220 1 - Success 1221 2 - Failure 1223 Method Identity TLV: 1225 This TLV is used to indicate meta information about each method that 1226 participated in the compound authentication. It includes the method 1227 type (EAP,IPSec etc), the length of the key used for compound key 1228 derivation, the Client and Server identities used and their lengths. 1229 The Media type for the compound authentication is also included. 1231 0 1 2 3 1232 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 |M|R| TLV Type | Length | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Method Type | Version | Key Length | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Client Identity Length | | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1240 | Client Identity | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | Server Identity Length | | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1244 | Server Identity | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Media Type | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 M 1250 1 - Mandatory TLV 1252 R 1254 Reserved, set to zero (0) 1256 TLV Type 1258 METHOD_IDENTITY_TLV. See IANA considerations section 1260 Method Type 1262 One octet. This indicates what EAP method type was used. 1264 Version 1266 One octet. This indicates the version of the EAP method used. 1268 Key Length 1270 Length of the method keys in bits, used to for compound key 1271 derivation. It is the length of the ISK or TSK used to for 1272 compound MAC and session key derivations. They are the same 1273 size for both. 1275 Client Identity Length 1277 2 octets. The number of octets used for the Client Identity field 1279 Client Identity 1281 As many octets as indicated in the Client Identity Length. For EAP methods, 1282 this would be the identity exchanged in the identity request packet. If no 1283 Identity request was used, then this would be set to 0. This field can be 1284 omitted if the Client Identity Length is set to 0. 1286 Server Identity Length 1288 2 octets. The number of octets used for the Server Identity field 1290 Server Identity 1292 As many octets as the value of Server Identity Length. This is to 1293 indicate the identity of the server, the client is talking to for 1294 a particular method. 1296 Media Type 1298 The media used for the compound authentication. eg. RADIUS NAS 1299 Port Type values. 1301 Implementation Note: 1303 Due to the identities not being consistent across methods, its 1304 possible that the client and server identities used in these TLVs for 1305 the Binding Request (B1) and Binding Response (B2) messages don�t 1306 necessarily match. The exact specification of these fields needs 1307 further study. 1309 Binding TLV: 1311 This message format is used for the Binding Request (B1) and also the 1312 Binding Response. This uses TLV type CRYPTO_BINDING_TLV. The format is 1313 as given below. 1315 0 1 2 3 1316 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 |M|R| TLV Type | Length | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Version | SubType | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | | 1323 + NONCE + 1324 | | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Reserved | Number of inner methods(n) | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | RESULT_TLV | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | METHOD_IDENTITY_TLV (0) | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | .... | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | METHOD_IDENTITY_TLV (n-1) | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | METHOD_IDENTITY_TLV (tunnel method) | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | | 1339 + Compound MAC + 1340 | | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 M 1344 1 - Mandatory TLV 1346 R 1348 Reserved, set to zero (0) 1350 TLV Type 1352 CRYPTO_BINDING_TLV. See IANA Considerations. 1354 Version 1356 Version of tunnel protocol extension for binding. Initially set to 1357 0. 1359 Length 1361 2 octets 1363 Nonce 1364 32 octets. 256 bit Random number that is never repeated and is 1365 used for compound MAC key derivation at each end. It is a S_NONCE 1366 for the B1 message and a C_NONCE for the B2 message. 1368 RESULT_TLV 1370 This is defined earlier. It either indicates a success/failure. 1372 METHOD IDENTITY TLV (0�n-1) 1374 This is defined earlier. One TLV indicating the meta information 1375 for each authentication method is included. 1377 METHOD IDENTITY TLV (tunnel) 1379 This is indicating the tunnel method meta information. 1381 MAC 1383 16 octets. This can be the Server MAC (B1_MAC) or the Client MAC 1384 (B2_MAC). It is computed over the entire Binding TLV packet using 1385 the HMAC-SHA1-128 using the CMK_B1 or CMK_B2. It is truncated to 1386 128 bits. 1388 4.4 IANA Considerations 1390 IANA has assigned the EAP type number 33 for TLVs. 1392 This protocol extension defines a new TLV types for cryptographic 1393 binding that are defined below. 1395 CRYPTO_BINDING_TLV 5 1396 METHOD_IDENTITY_TLV 6 1398 It also uses the Result TLV (RESULT_TLV) defined in the draft[TLV, PEAP] 1400 5. Normative references 1402 [TLS] [RFC2246] 1404 [EAP-MD5] [RFC2284] 1406 [ISAKMP] [RFC2408] 1408 [IKE] [RFC2409] 1410 [PEAPV0] Kamath, V., Palekar, A., Wodrich,M., "Microsoft's PEAP 1411 version 0 (Implementation in Windows XP SP1)", October 1412 2002 (work in progress) 1414 [TLV] Hiller, T., Palekar, A., Zorn, Glen, "A Container Type 1415 for the Extensible Authentication Protocol (EAP)", 1416 October 2002 (work in progress) 1418 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1419 RFC 1661, July 1994. 1421 [RFC1938] Haller, N. and C. Metz, "A One-Time Password System", RFC 1422 1938, May 1996. 1424 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1425 Protocol (CHAP)", RFC 1994, August 1996. 1427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1429 Requirement Levels", RFC 2119, March 1997.] 1431 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 1432 Protocol (EAP)", RFC 2284, March 1998. 1434 [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., 1435 "Remote Authentication Dial In User Service (RADIUS)", 1436 RFC 2865, June 2000. 1438 [RFC3193] Patel, B., et al., "Securing L2TP Using IPsec", RFC 3193, 1439 November 2001. 1441 [EAPTTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS 1442 Authentication Protocol", Internet draft (work in 1443 progress), February 2002. 1445 [DHCPIpsec] Patel, B., et al., "DHCPv4 Configuration of IPsec Tunnel 1446 Mode", Internet draft (work in progress), draft-ietf- 1447 ipsec-dhcp-13.txt, June 2001. 1449 [PEAP] Andersson, H., et al., "Protected EAP Protocol (PEAP)", 1450 Internet draft (work in progress), draft-josefsson- 1451 pppext-eap-tls-eap-05.txt, September 2002. 1453 [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE 1454 Credential Provisioning Protocol", Internet draft (work 1455 in progress), draft-ietf-ipsra-pic-06.txt, September 1456 2002. 1458 [IPSRAREQ] Kelly, S., Ramamoorthi, S., "Requirements for IPsec 1459 Remote Access Scenarios", Internet draft (work in 1460 progress), draft-ietf-ipsra- reqmts-05.txt, September 1461 2002. 1463 [GETCERT] Bellovin, S., and Moskowitz, B., "Client Certificate and 1464 Key Retrieval for IKE", Internet draft (work in 1465 progress), draft-bellovin-ipsra-getcert-00.txt, June 1466 2000. 1468 [SECURID] Josefsson, S., "The EAP SecurID(r) Mechanism", Internet 1469 draft (work in progress), draft-josefsson-eap- 1470 securid-01.txt, February 2002. 1472 [PANATLS] Ohba, Y., et al., "PANA over TLS", Internet draft (work 1473 in progress), draft-ohba-pana-potls-00.txt, September 1474 2002. 1476 [XAUTH] Pereira, R., Beaulieu, S., "Extended Authentication 1477 within ISAKMP/Oakley", Internet-draft (work in progress), 1478 draft-beaulieu-ike-xauth-02.txt, September, 2000. 1480 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 1481 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1483 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 1484 Port based Network Access Control, IEEE Std 802.1X-2001, 1485 June 2001. 1487 [IEEE80211] Information technology - Telecommunications and 1488 information exchange between systems - Local and 1489 metropolitan area networks - Specific Requirements Part 1490 11: Wireless LAN Medium Access Control (MAC) and 1491 Physical Layer (PHY) Specifications, IEEE Std. 1492 802.11-1997, 1997. 1494 6. Informative references 1496 [RFC1510] Kohl, J., Neuman, C., "The Kerberos Network 1497 Authentication Service (V5)", RFC 1510, September 1993. 1499 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1500 RFC 2246, November 1998. 1502 [RFC2486] Beadles, M., Aboba, B., "The Network Access Identifier", 1503 RFC 2486, January 1999. 1505 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the 1506 Internet Protocol", RFC 2401, November 1998. 1508 [RFC2402] Kent,S., Atkinson, R., "IP Authentication Header", RFC 1509 2402, November 1998. 1511 [RFC2406] Kent,S., Atkinson, R., "IP Encapsulating Security Payload 1512 (ESP)", RFC 2406, November 1998. 1514 [RFC2407] Piper, D., "The Internet IP Security Domain of 1515 Interpretation of ISAKMP", RFC 2407, November 1998. 1517 [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and Turner, 1518 J., "Internet Security Association and Key Management 1519 Protocol (ISAKMP)", RFC 2408, November 1998. 1521 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 1522 (IKE)", RFC 2409, November 1998. 1524 [RFC2412] Orman, H., "The Oakley Key Determination Protocol", RFC 1526 2412, Nov. 1998. 1528 [RFC2433] Zorn, G., Cobb, S., "Microsoft PPP CHAP Extensions", RFC 1529 2433, October 1998. 1531 [RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol 1532 (PPTP)", RFC 2637, July 1999. 1534 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1535 G., and Palter, B., "Layer Two Tunneling Protocol L2TP", 1536 RFC 2661, August 1999. 1538 [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication 1539 Protocol", RFC 2716, October 1999. 1541 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 1542 2759, January 2000. 1543 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1545 [DECEPTION] Slatalla, M., and Quittner, J., "Masters of Deception." 1546 HarperCollins, New York, 1995. 1548 [KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos Password 1549 Security", Stanford University Computer Science 1550 Department, http://theory.stanford.edu/~tjw/krbpass.html 1552 [KRBLIM] Bellovin, S.M., Merritt, M., "Limitations of the kerberos 1553 authentication system", Proceedings of the 1991 Winter 1554 USENIX Conference, pp. 253-267, 1991. 1556 [KERB4WEAK] Dole, B., Lodin, S., and Spafford, E., "Misplaced trust: 1557 Kerberos 4 session keys", Proceedings of the Internet 1558 Society Network and Distributed System Security 1559 Symposium, pp. 60-70, March 1997. 1561 [PPTPv1] Schneier, B, Mudge, "Cryptanalysis of Microsoft's Point- 1562 to- Point Tunneling Protocol", Proceedings of the 5th ACM 1563 Conference on Communications and Computer Security, ACM 1564 Press, November 1998. 1566 [IEEE8023] ISO/IEC 8802-3 Information technology - 1567 Telecommunications and information exchange between 1568 systems - Local and metropolitan area networks - Common 1569 specifications - Part 3: Carrier Sense Multiple Access 1570 with Collision Detection (CSMA/CD) Access Method and 1571 Physical Layer Specifications, (also ANSI/IEEE Std 1572 802.3-1996), 1996. 1574 [MITM] Nokia Research Center, Man-in-the-middle attacks in 1575 tunneled authentication protocols, 1576 http://www.saunalahti.fi/~asokan/research/mitm.html, 1577 October 2002 1579 [MITM1] Asokan, N., Niemi, V., Nyberg, K., "Man-in-the-middle 1580 in tunneled authentication", November 2002 1582 Acknowledgments 1584 We wish to thank N. Asokan, Valterri Niemi, Kaisa Nyberg and Henry 1585 Haverinen of Nokia for initially making us aware of the problem [MITM]. 1587 Special thanks to Bernard Aboba, N.Asokan, Jesse Walker, Farid Adrangi, 1588 Nancy Cam-Winget and Joe Salowey for their valuable comments and 1589 suggestions. 1591 Also thanks to Bernard Aboba for his expert advice and editorial 1592 assistance. 1594 Authors' Addresses 1596 Jose Puthenkulam 1597 Intel Corporation 1598 2111 NE 25th Avenue, JF2-58 1599 Hillsboro, OR 97124 1601 EMail: jose.p.puthenkulam@intel.com 1602 Phone: +1 503 264 6121 1603 Fax: +1 503 264 8154 1604 Victor Lortz 1605 Intel Corporation 1606 2111 NE 25th Avenue, JF3-206 1607 Hillsboro, OR 97124 1609 EMail: victor.lortz@intel.com 1610 Phone: +1 503 264 3253 1611 Fax: +1 503 264 4230 1613 Ashwin Palekar 1614 Dan Simon 1615 Microsoft Corporation 1616 One Microsoft Way 1617 Redmond, WA 98052 1619 EMail: {ashwinp, dansimon}@microsoft.com 1620 Phone: +1 425 882 8080 1621 Fax: +1 425 936 7329 1623 Full Copyright Statement 1625 Copyright (C) The Internet Society (2003). All Rights Reserved. 1626 This document and translations of it may be copied and furnished to 1627 others, and derivative works that comment on or otherwise explain it or 1628 assist in its implementation may be prepared, copied, published and 1629 distributed, in whole or in part, without restriction of any kind, 1630 provided that the above copyright notice and this paragraph are included 1631 on all such copies and derivative works. However, this document itself 1632 may not be modified in any way, such as by removing the copyright notice 1633 or references to the Internet Society or other Internet organizations, 1634 except as needed for the purpose of developing Internet standards in 1635 which case the procedures for copyrights defined in the Internet 1636 Standards process must be followed, or as required to translate it into 1637 languages other than English. The limited permissions granted above are 1638 perpetual and will not be revoked by the Internet Society or its 1639 successors or assigns. This document and the information contained 1640 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1641 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1642 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1643 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1644 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1645 EAP Issues 1647 Open issues relating to EAP, including the issues described in this 1648 document, are tracked on the following web site: 1650 http://www.drizzle.com/~aboba/EAP/eapissues.html 1652 Expiration Date 1654 This memo is filed as , and 1655 expires on September 3, 2003.