idnits 2.17.1 draft-aboba-pppext-key-problem-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 38 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 734 has weird spacing: '...imed to perta...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (22 October 2002) is 7856 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 293 -- Looks like a reference, but probably isn't: '2' on line 302 == Missing Reference: 'RFC2548' is mentioned on line 324, but not defined == Unused Reference: 'RFC2434' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC3079' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 682, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: A later version (-16) exists of draft-arkko-pppext-eap-aka-05 == Outdated reference: A later version (-07) exists of draft-ietf-ipsra-pic-06 Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group Bernard Aboba 3 INTERNET-DRAFT Dan Simon 4 Category: Informational Microsoft 5 6 22 October 2002 8 The EAP Keying Problem 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet- Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2002). All Rights Reserved. 34 Abstract 36 This document describes the issues involved in key derivation by EAP 37 methods and provides guidelines for generation and usage of EAP keys. 38 Algorithms for key derivation are not specified in this document. 39 Rather, this document lays out a framework within which algorithms can 40 be discussed and evaluated. 42 Table of Contents 44 1. Introduction .......................................... 3 45 1.1 Requirements language ........................... 3 46 1.2 Terminology ..................................... 4 47 2. EAP architecture overview ............................. 5 48 2.1 Implications of the architecture ................ 7 49 3. EAP Keying Requirements ............................... 8 50 4. Security considerations ............................... 13 51 4.1 Key strength .................................... 13 52 4.2 Man-in-the-middle attacks ....................... 13 53 5. Normative references .................................. 15 54 6. Informative references ................................ 16 55 Acknowledgments .............................................. 17 56 Author's Addresses ........................................... 17 57 Intellectual Property Statement .............................. 18 58 Full Copyright Statement ..................................... 18 59 1. Introduction 61 The Extensible Authentication Protocol (EAP), defined in [RFC2284], was 62 developed to provide extensible authentication for use with PPP 63 [RFC1661]. Since then, new applications of EAP have emerged, including 64 IEEE 802.1X network port authentication [IEEE8021X], and PIC [PIC]. 66 Although the initial focus of EAP was authentication, it can also 67 provide keys for use with a ciphersuite, and binding of methods within a 68 sequence or tunnel. EAP methods defined in [RFC2284] include EAP MD5, 69 as well as One-Time Password (OTP) and Generic Token Card methods. Each 70 of these methods supports one-way authentication only but not key 71 derivation. However, subsequent EAP method specifications such as EAP 72 TLS [RFC2716], EAP SRP [EAPSRP], EAP GSS [EAPGSS] and EAP AKA [EAPAKA] 73 have provided for mutual authentication, as well as key derivation. 75 The ciphersuites for which EAP may provide keying material have also 76 grown in number. PPP ciphersuites include DESEbis [RFC2419], 3DES 77 [RFC2420], and MPPE [RFC3078]. The DES algorithm is described in 78 [FIPSDES], and DES modes (such as CBC, used in RFC 2419 and DES- 79 EDE3-CBC, used in RFC 2420) are described in [DESMODES]. For PPP 80 DESEbis, a single 56-bit encryption key is required, used in both 81 directions; for PPP 3DES, a 168-bit encryption key is needed, used in 82 both directions. As described in [RFC2419] and [RFC2420] for both 83 protocols, the IV, which is different in each direction, is "deduced 84 from an explicit 64-bit nonce, which is exchanged in the clear during 85 the negotiation phase." 87 For MPPE, 40-bit, 56-bit or 128-bit encryption keys can be required in 88 each direction, as described in [RFC3078]. Since MPPE is based on the 89 RC4 algorithm, no initialization vector is required. While these PPP 90 ciphersuites provide encryption, they do not provide a per-packet keyed 91 message integrity check (MIC). Thus, an authentication key is not 92 required in either direction. 94 Within 802.11, ciphersuites include WEP-40, described in [IEEE80211], 95 which requires a 40-bit encryption key, the same in either direction; 96 and WEP-128, which requires a 104-bit encryption key, the same in either 97 direction. These ciphersuites also do not include a keyed MIC. 99 Recently, new ciphersuites have been proposed for use with 802.11 that 100 do provide per-packet authentication as well as encryption 101 [IEEE80211Tgi]. These ciphersuites use either 104-bit or 128-bit keys, 102 and include definition of their own ciphersuite-specific key hierarchy. 104 With the increase in the number of EAP methods and applicable 105 ciphersuites, there is a need for defining how transient session keys 106 are derived from the master secrets produced by EAP methods, and how 107 keys are used to provide cryptographic binding between methods used in a 108 sequence or tunnel. Allowing each EAP method to handle this in its own 109 way is likely to produce unacceptable results. 111 This document reviews the issues involved in EAP key derivation and 112 provides guidelines for the generation of keys by EAP methods. 114 1.1. Requirements language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in BCP 14 [RFC2119]. 120 1.2. Terminology 122 This document frequently uses the following terms: 124 Authentication Server 125 An Authentication Server is an entity that provides an 126 Authentication Service to an NAS. This service verifies from 127 the credentials provided by the peer, the claim of identity 128 made by the peer. 130 Cryptographic binding 131 The demonstration of the EAP peer to the authenticator that a 132 single entity has acted as the EAP peer for all methods 133 executed within a sequence or tunnel. Binding MAY also imply 134 that the EAP authenticator demonstrates to the peer that a 135 single entity has acted as the EAP authenticator for all 136 methods executed within a sequence or tunnel. If executed 137 correctly, binding serves to mitigate man-in-the-middle 138 vulnerabilities. 140 Master key 141 The key derived between the EAP client and EAP server during 142 the EAP authentication process. 144 Master session key 145 Master session keys are derived from the master key, and are 146 subsequently used in generation of transient session keys for 147 authentication, encryption and IV-generation. Since the 148 transient session keys may be different in each direction, 149 master session keys are also required in each direction, and 150 are therefore referred to as "asymmetrical". So that the 151 master session keys are to be usable with any ciphersuite, 152 they are longer than is necessary, and are truncated to fit. 154 Transient session keys 155 The chosen ciphersuite uses transient session keys for 156 authentication and encryption as well as IVs (if required). 157 The transient session keys are derived from the master session 158 keys, and are of the appropriate size for use with the chosen 159 ciphersuite. Depending on the ciphersuite, the transient 160 session keys may be different in each direction. 162 2. EAP architecture overview 164 One of the goals of EAP is to enable development of new authentication 165 methods without requiring deployment of new code on the NAS. As a 166 result, the NAS acts as a "passthrough", and need not understand 167 specific EAP methods. Among other things, this implies that a NAS need 168 not contain code specific to each EAP method. EAP 170 Instead of requiring new code on the NAS, EAP methods are installed on 171 the client and backend authentication server, typically interfacing with 172 the operating system via an EAP API, such as that described in [EAPAPI]. 173 In order to allow the client and backend server to install new EAP 174 methods without requiring an operating system upgrade, operating systems 175 isolate EAP method-specific code within the installed EAP methods, and 176 thus largely operate as "passthrough" entities with respect to EAP. 178 Figure 1 describes the relationship between the EAP peer, NAS and AAA 179 server. As described in the figure, the EAP conversation "passes 180 through" the NAS on its way between the client and the AAA server As a 181 result, the NAS does not have knowledge of the keys that are derived 182 between the AAA server and the client, and these keys need to be 183 transmitted from the AAA server to the NAS. 185 EAP methods are installed on the the client and the AAA server, 186 typically communicating via an EAP API, so that the main client and AAA 187 server code does not need to be modified to add new methods. Among the 188 results that are passed back by EAP methods via the APIs are the keys to 189 be communicated from the AAA server to the NAS. Ciphersuites are 190 installed on the NAS and the client. 192 While EAP methods which derive keys can be used to provide automated 193 keying for a ciphersuite, this does not imply that the EAP method need 194 contain ciphersuite-specific code. Since the client and NAS need to 195 implement a given ciphersuite, ciphersuite-specific code is expected to 196 exist on the client and NAS. However, since the backend authentication 197 server is not involved in the protection of data traffic, and may not 198 even be aware of the negotiated ciphersuite, it cannot be assumed to 199 implement ciphersuite-specific code, and the backend authentication 200 server will not necessarily have knowledge of the ciphersuites available 201 on the NAS and client. 203 +-+-+-+-+-+ +-+-+-+-+-+ 204 | | | | 205 | | | | 206 | Cipher- | | Cipher- | 207 | Suite | | Suite | 208 | | | | 209 +-+-+-+-+-+ +-+-+-+-+-+ 210 ^ ^ 211 | | 212 | | 213 | | 214 V V 215 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 216 | | EAP | | | | 217 | | Conversation | | | | 218 | |<================================>| AAA | 219 | Client | | NAS/ | | Server | 220 | | | |<=======| | 221 | | | | Keys | | 222 | | | | | | 223 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 224 ^ ^ 225 | | 226 | EAP API | EAP API 227 | | 228 V V 229 +-+-+-+-+-+ +-+-+-+-+-+ 230 | | | | 231 | | | | 232 | EAP | | EAP | 233 | Method | | Method | 234 | | | | 235 +-+-+-+-+-+ +-+-+-+-+-+ 237 Figure 1 - Relationship between EAP client, AAA server and NAS. 239 2.1. Implications of the architecture 241 Since the backend authentication server may not have knowledge of the 242 ciphersuite that has been negotiated, it may not be possible for this 243 information to be passed to the EAP method via the EAP APIs. As a 244 result, inclusion of ciphersuite-specific code within an EAP method is 245 inappropriate. Similarly, because the NAS is assumed to not have 246 knowledge of individual EAP methods, it cannot be assumed to include 247 code specific to an EAP method. Moreover, since operating systems 248 provide EAP APIs in order to remain "EAP-Method Agnostic", EAP method- 249 specific code is best kept out of the EAP APIs as well. 251 Drawbacks to allowing EAP methods to specify session key derivation 252 mechanisms for individual ciphersuites include: 254 Document Revision 255 If an EAP method specifies how to derive transient 256 session keys on a per-ciphersuite basis, then this 257 document will need to be revised each time a new 258 ciphersuite comes out. This would also imply that an 259 authentication server supporting an EAP method might not 260 be usable with a NAS supporting EAP, due to lack of 261 support for a ciphersuite implemented on the NAS. This 262 is antithetical to the EAP architecture, which conceives 263 of the NAS as a "pass through" device that does not need 264 to understand EAP, and which therefore can work with any 265 EAP method supported by the authentication server. 267 EAP method complexity 268 Forcing the EAP method to include ciphersuite-specific 269 code for transient session key derivation increases the 270 complexity of EAP method development, as well as client 271 and authentication server implementations. 273 Knowledge asymmetry 274 In practice, an EAP method may not have knowledge of the 275 ciphersuite that has been negotiated. In PPP, negotiation 276 of the ciphersuite is accomplished via the Encryption 277 Control Protocol (ECP), described in [RFC1968]. Since 278 ECP negotiation occurs after authentication, unless an 279 EAP method is utilized that supports ciphersuite 280 negotiation (such as EAP-TLS [RFC2716]), the client, NAS 281 and backend authentication server may not be able to 282 anticipate the ciphersuite that will be used and 283 therefore this information cannot be provided to the EAP 284 method. 286 3. EAP keying requirements 288 In the most general case, authentication and encryption keys as well as 289 initialization vectors must be derived for each direction from the 290 master secret K derived by the EAP method. This can accomplished via 291 the specification of two classes of algorithms: 293 [1] Algorithms for the derivation of "master session keys" from the 294 negotiated master key. The "master session keys" are derived from 295 the master key derived by the EAP method, but are never directly 296 used by ciphersuites; they are only used in the derivation of 297 transient session keys. These "master session keys" are derived on 298 the client and the backend authentication server. The backend 299 authentication server then transmits the "master session keys" to 300 the NAS. 302 [2] Algorithms for the derivation of "transient session keys" from the 303 "master session keys". The "transient session keys" are used for 304 encryption, authentication and IV-generation in each direction, and 305 are derived by the NAS and client, based on the negotiated 306 ciphersuite. 308 Depending on the negotiated ciphersuite and media, a different set of 309 "transient session keys" may be required; for example 802.11 WEP does 310 not provide a keyed message integrity check, and typically uses only a 311 single encryption key in both directions. 313 The algorithm for deriving the "master session keys" from the "master 314 key" is designed to be ciphersuite-independent, and is specific to the 315 EAP method. The goal of this algorithm is to provide master session keys 316 in a well defined format, suitable for passage between the AAA server 317 and the NAS. 319 Examples of master session key derivation algorithms are provided in 320 Section 3.5 of EAP TLS [RFC2716], based on the Pseudo-Random Function 321 (PRF) defined in TLS [RFC2246]. Equivalent algorithms are provided in 322 IKE [RFC2409] for the derivation of SKEYID_d, SKEYID_a and SKEYID_e from 323 the master key SKEYID. Examples of AAA master session key attributes 324 are provided in [RFC2548]. 326 Note that because the derivation and validation of these algorithms is 327 difficult, it is highly desirable to reuse existing algorithms if at all 328 possible. This enables the security community to carefully analyze the 329 proposed algorithm. Such an analysis would be difficult were multiple 330 algorithms to proliferate. However, since each EAP method is different, 331 it is also true that existing algorithms may not fit all situations. 333 For example, the master key may not be directly available within all EAP 334 methods. For security reasons, the TLS master secret is typically not 335 directly available via TLS APIs. As a result, [RFC2716] derives master 336 session keys from the TLS master secret, and uses those master session 337 keys to derive the required session keys. 339 Since EAP TLS [RFC2716] does not assume knowledge of the negotiated 340 ciphersuite, it provides keys large enough for use with any ciphersuite, 341 assuming that these will be truncated for use within the client and NAS. 342 Since the raw master secret is typically not available in to EAP-TLS 343 implementations, when this EAP method is used, the TLS PRF function is 344 needed to derive keying material from it. 346 Other EAP methods may also encounter similar issues. For example, EAP 347 GSS implementations will typically not be able to access the master keys 348 directly, but can call GSS_Wrap() to encrypted tokens and GSS_GetMIC() 349 to generate authentication tokens based on the master secret. EAP GSS 350 implementations will therefore need to use GSS-API calls to derive 351 master session keys from the master key, rather than operating on the 352 master key directly. 354 By specifying the algorithm by which master session keys are derived 355 within each EAP method, as well as the format by which the master 356 session keys are transmitted from the AAA server to the NAS, the NAS can 357 be assured of obtaining master session keys for each EAP method, in a 358 well-defined format. Since it is assumed that the backend 359 authentication server will perform the required calculations and will 360 supply the NAS with the master session keys, the master session key 361 algorithm need not be implemented on the NAS. 363 Rather, the NAS will only need code for the second algorithm, namely for 364 the derivation of ciphersuite-specific "transient session keys" from 365 "master session keys". 367 The derivation of ciphersuite-specific "transient session keys" from 368 "master session keys" occurs after the ciphersuite has been determined, 369 and provides for the derivation of the keys required within the 370 ciphersuite-specific key hierarchy. The algorithm for deriving 371 "transient session keys" from the "master session keys" is designed to 372 be EAP-method independent, but is dependent on the negotiated 373 ciphersuite and media. 375 Since each ciphersuite and media may have different needs, the 376 algorithms for transient session key derivation will vary according to 377 the ciphersuite and media. Nevertheless, as with master session key 378 derivation algorithms, it is desirable if commonalities can be found, so 379 that the correctness and security of the algorithms can be more easily 380 analyzed. 382 Figure 2 on the next page describes the overall logic of how master 383 session keys and transient session keys are derived from the master key 384 negotiated within an EAP method. 386 The master key K may be of varying length, and as described earlier, may 387 not be directly available to the EAP method. Where the master key K is 388 not exportable, an intermediate step is required to generate a "Pseudo- 389 Master Key" from the master key. For example, in EAP GSS, as described 390 in [EAPGSS], a "Pseudo-Master Key", K' is derived via GSS-API calls, and 391 is used instead. 393 In order to enable interoperability between backend authentication 394 servers, NASen and EAP clients implementing EAP methods that derive 395 keys, the following is required: 397 Key hierarchy 398 In order to enable the keys derived within EAP methods to be used 399 within any ciphersuite, EAP methods deriving keys need to specify 400 the algorithms for master session key derivation. If possible, it 401 is desirable to reuse existing key derivation techniques, rather 402 than inventing new ones. 404 Ciphersuite keys 405 In order to use the master session keys provided by EAP methods, 406 ciphersuites keyed via EAP need to define how ciphersuite-specific 407 keys are derived from the master session keys provided by EAP 408 methods, based on the ciphersuite-specific key hierarchy. 410 Keying AVPs 411 In order to enable backend authentication servers to provide keying 412 material to the NAS in a well defined format, it is necessary to 413 standardize the attributes used to transmit keys from the backend 414 authentication server to the NAS. 416 The algorithms for derivation of "master session keys" from the master 417 key, and for derivation of "transient session keys" from the "master 418 session keys" are not specified in this document. Rather, the purpose of 419 this document is to lay out a framework within which algorithms can be 420 discussed and evaluated. 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+--- 423 | | | | ^ 424 | Is a raw master key | | Can a pseudo-master key | | 425 | available or can | | be derived from | | 426 | the PRF operate on it? | | the master key? | | 427 | | | | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 429 | | | 430 | K | K' | 431 | | | 432 V V | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 434 | | EAP | 435 | Master Session Key | Method | 436 | Derivation | | 437 | | | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 439 | | | 440 | Master Session Key Outputs | | 441 | | | 442 V V | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 444 | | | 445 | Key and IV Derivation | | 446 | | | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 448 | P->A | A->P | P->A | A->P | P->A | A->P EAP V 449 | Enc. | Enc. | Auth. | Auth. | IV | IV API ---+--- 450 | Key | Key | Key | Key | | ^ 451 | | | | | | AAA | 452 | | | | | | Keys V 453 V V V V V V ---+--- 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 455 | | | 456 | Ciphersuite-Specific Key Hierarchy | NAS | 457 | | | 458 | | V 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+--- 461 Figure 2 - Architecture for derivation of ciphersuite-specific key 462 hierarchy from the EAP method master key K. 464 For a proposed "master session key" derivation algorithm to be 465 satisfactory, it needs to fulfill several requirements: 467 Ciphersuite-independence 468 A satisfactory "master session key" derivation algorithm MUST 469 NOT require ciphersuite-specific code to be implemented within 470 an EAP method. In practice, this implies that the master 471 session keys MUST enable derivation of authentication and 472 encryption keys and IVs in both directions. 474 Generality 475 A satisfactory "master session key" derivation algorithm MUST 476 provide master session keys appropriate for use with a wide 477 range of ciphersuites. Among other things, this implies that 478 the master session keys MUST contain sufficient entropy to be 479 usable with existing and future ciphersuites. At a minimum, 480 master session keys SHOULD be at least 256 octets in length. 482 Direct and Indirect Access 483 Satisfactory "master session key" derivation algorithms MUST 484 be applicable to EAP methods where the master key is not 485 directly accessible. These include TLS and GSS-API methods. 487 Generality 488 It is likely that each EAP method will handle the derivation 489 of "master session keys" from "master keys" in a different 490 manner. However, wherever possible, well known algorithms 491 SHOULD be reused, and customized to fit, rather than 492 developing entirely new algorithms. 494 Algorithms for "transient session key" derivation also needs to fulfill 495 several requirements: 497 EAP method independence 498 Algorithms for deriving "transient session keys" from "master 499 session keys" MUST NOT depend on the EAP method. Derivation 500 of "transient session keys" is expected to occur on the NAS, 501 which acts as a "passthrough" for EAP. Therefore the NAS 502 cannot be expected to have knowledge of the EAP method that 503 has been negotiated. 505 Sufficient keying material 506 Algorithms for derivation of "transient session keys" from 507 "master session keys" will typically be dependent on the key 508 hierarchy of the given ciphersuite and media. However, 509 regardless of the specific key hierarchy, the derived "master 510 session key" MUST provide sufficient entropy to enable 511 "transient session keys" to be securely derived. For example, 512 an EAP method that generates a "master session key" with only 513 56 bits of entropy will not be adequate. 515 4. Security considerations 517 4.1. Key strength 519 The strength of the session keys is dependent upon the security of the 520 EAP method providing the master keying material. If the chosen EAP 521 method has security vulnerabilities, or does not produce a key of 522 sufficient entropy then it is possible that weak session keys may be 523 produced. 525 4.2. Man-in-the-middle attacks 527 Since EAP is widely implemented on multiple media, man-in-the-middle 528 attacks are a fundamental concern. Where methods are used within a 529 sequence or tunnel, cryptographic binding between the methods and (if 530 present) the tunnel, is required so that a single peer and authenticator 531 can be demonstrated to have taken part in the entire exchange. 533 Without cryptographic binding, a man-in-the-middle attack may be enabled 534 as described in Figure 3. 536 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 537 | | | | | | 538 | | | | | | 539 | | EAP | +--------+ | 540 | Client | Conversation |Attacker | Tunnel | | 541 | |<================================>| NAS | 542 | | | | | | 543 | | | +--------+ | 544 | | | | | | 545 | | | | | | 546 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 548 Figure 3 - Man-in-the-middle attack on EAP tunnel 550 In the figure, the NAS (otherwise known as the EAP authenticator) 551 supports authentication via tunneled EAP. If the EAP tunneling mechanism 552 does not require client authentication, then an attacker can establish a 553 tunnel to the NAS without having to authenticate itself. The attacker 554 can then induce an unsuspecting client to authenticate to it. The 555 attacker then tunnels EAP packets from the client to the NAS, 556 authenticating itself to the NAS. 558 This would not constitute a true man-in-the-middle attack however, 559 unless the attacker were also able to obtain the keys used to encrypt 560 data between the client and the NAS. Since the EAP conversation occurs 561 between the client and the NAS, a well designed EAP method would not 562 permit the attacker to obtain the key derived between the client and 563 NAS. However, if the key were to be derived solely from the tunnel setup 564 between the attacker and NAS, then the attacker obtains the key without 565 having to execute a man-in-the-middle attack on the EAP method itself. 566 EAP tunneling protocols MUST demonstrate how they protect against this 567 attack, by allowing the client to provide the authenticator with a 568 cryptographic binding between the tunnel and the encapsulated methods. 570 Another variety of attack is illustrated in Figure 4. 572 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 573 | | | | | | 574 | | | | | | 575 | | | | | | 576 | Client | EAP Method 2 | NAS 1 | | NAS 2 | 577 | |<================================>| | 578 | | EAP Method 1 | | | | 579 | |<=============>| | | | 580 | | | | | | 581 | | | | | | 582 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 584 Figure 4. Man-in-the-middle attack on EAP sequence 586 In this attack, EAP method 1 is terminated on NAS 1, but EAP method 2 is 587 proxied by NAS 1 to NAS 2. If the intent of the client is to require a 588 single NAS to authenticate via two factors (say, a password/cert and a 589 token) then this will not have been demonstrated. 591 In order to provide the client with the assurance that a single NAS has 592 acted as the authenticator for all methods within the sequence, the 593 authenticator needs to demonstrate to the client a cryptographic binding 594 between the sequence of EAP methods. 596 The cryptographic binding may be demonstrated via a computation 597 involving the keys generated during the EAP method sequence, as well as 598 keys derived during tunnel setup. Where this is the case, it is not 599 possible to bind EAP methods which do not derive keys. 601 For an EAP method which does not derive keys to demonstrate 602 cryptographic binding, the method as well as the EAP implementation 603 would need to to support method-specific binding -- which existing 604 methods and EAP implementations typically do not. For example, to allow 605 the EAP method to incorporate keys derived by other methods, the EAP 606 implementation would need to support passing of keys between methods and 607 the method would need to be able to make use of the passed keys. Such a 608 method would not be implementable within an EAP implementation that did 609 not support a key passing facility. 611 The result is that typically only EAP methods that derive keys can be 612 cryptographically bound in an interoperable way. 614 5. Normative References 616 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 617 51, RFC 1661, July 1994. 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, March 1997. 622 [RFC2246] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", RFC 623 2246, November 1998. 625 [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 626 Protocol (EAP)", RFC 2284, March 1998. 628 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 629 RFC 2409, November 1998. 631 [IEEE8021X] 632 IEEE Standards for Local and Metropolitan Area Networks: Port 633 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 635 6. Informative References 637 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 638 1996. 640 [RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 641 Version 2 (DESE-bis)", RFC 2419, September 1998. 643 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", 644 RFC 2420, September 1998. 646 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 647 Considerations Section in RFCs", BCP 26, RFC 2434, October 648 1998. 650 [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", 651 RFC 2716, October 1999. 653 [RFC3078] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption 654 (MPPE) RFC 3078, March 2001. 656 [RFC3079] Zorn, G. "Deriving Keys for use with Microsoft Point-to-Point 657 Encryption (MPPE)," RFC 3079, March 2001. 659 [EAPGSS] Aboba, B., "EAP GSS Authentication Protocol", Internet draft 660 (work in progress), draft-aboba-pppext-eapgss-12.txt, April 661 2002. 663 [EAPAKA] Arkko, J., Haverinen, H., "EAP AKA Authentication", Internet 664 draft (work in progress), draft-arkko-pppext-eap-aka-05.txt, 665 October 2002. 667 [EAPSRP] Carlson, J., Aboba, B., Haverinen, H., "PPP EAP SRP-SHA1 668 Authentication Protocol", Internet-draft (work in progress), 669 draft-ietf-pppext-eap-srp-03.txt, July 2001. 671 [FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS 672 PUB 46 (January 1977). 674 [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE 675 Credential Provisioning Protocol", Internet draft (work in 676 progress), draft-ietf-ipsra-pic-06.txt, October 2002. 678 [DESMODES] 679 National Bureau of Standards, "DES Modes of Operation", FIPS 680 PUB 81 (December 1980). 682 [SHA] National Institute of Standards and Technology (NIST), 683 "Announcing the Secure Hash Standard," FIPS 180-1, U.S. 684 Department of Commerce, 04/1995 686 [IEEE80211Tgi] 687 IEEE Draft 802.11i/D2, "Draft Supplement to STANDARD FOR 688 Telecommunications and Information Exchange between Systems - 689 LAN/MAN Specific Requirements - Part 11: Wireless Medium 690 Access Control (MAC) and physical layer (PHY) specifications: 691 Specification for Enhanced Security", July 2001. 693 [IEEE80211] 694 Information technology - Telecommunications and information 695 exchange between systems - Local and metropolitan area 696 networks - Specific Requirements Part 11: Wireless LAN Medium 697 Access Control (MAC) and Physical Layer (PHY) Specifications, 698 IEEE Std. 802.11-1997, 1997. 700 [EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API", August 701 2000, http://msdn.microsoft.com/library/ 702 default.asp?url=/library/en-us/eap/eapport_0fj9.asp 704 Acknowledgments 706 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 707 Dorothy Stanley of Agerem and Russ Housley of RSA Security for useful 708 feedback. 710 Author Addresses 712 Bernard Aboba 713 Microsoft Corporation 714 One Microsoft Way 715 Redmond, WA 98052 717 EMail: bernarda@microsoft.com 718 Phone: +1 425 706 6605 719 Fax: +1 425 936 7329 721 Dan Simon 722 Microsoft Research 723 Microsoft Corporation 724 One Microsoft Way 725 Redmond, WA 98052 727 EMail: dansimon@microsoft.com 728 Phone: +1 425 706 6711 729 Fax: +1 425 936 7329 731 Intellectual Property Statement 733 The IETF takes no position regarding the validity or scope of any 734 intellectual property or other rights that might be claimed to pertain 735 to the implementation or use of the technology described in this 736 document or the extent to which any license under such rights might or 737 might not be available; neither does it represent that it has made any 738 effort to identify any such rights. Information on the IETF's 739 procedures with respect to rights in standards-track and standards- 740 related documentation can be found in BCP-11. Copies of claims of 741 rights made available for publication and any assurances of licenses to 742 be made available, or the result of an attempt made to obtain a general 743 license or permission for the use of such proprietary rights by 744 implementors or users of this specification can be obtained from the 745 IETF Secretariat. 747 The IETF invites any interested party to bring to its attention any 748 copyrights, patents or patent applications, or other proprietary rights 749 which may cover technology that may be required to practice this 750 standard. Please address the information to the IETF Executive 751 Director. 753 Full Copyright Statement 755 Copyright (C) The Internet Society (2002). All Rights Reserved. 756 This document and translations of it may be copied and furnished to 757 others, and derivative works that comment on or otherwise explain it or 758 assist in its implementation may be prepared, copied, published and 759 distributed, in whole or in part, without restriction of any kind, 760 provided that the above copyright notice and this paragraph are included 761 on all such copies and derivative works. However, this document itself 762 may not be modified in any way, such as by removing the copyright notice 763 or references to the Internet Society or other Internet organizations, 764 except as needed for the purpose of developing Internet standards in 765 which case the procedures for copyrights defined in the Internet 766 Standards process must be followed, or as required to translate it into 767 languages other than English. The limited permissions granted above are 768 perpetual and will not be revoked by the Internet Society or its 769 successors or assigns. This document and the information contained 770 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 771 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 772 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 773 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 774 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 776 Expiration Date 778 This memo is filed as , and 779 expires April 22, 2003.