idnits 2.17.1 draft-aboba-pppext-key-problem-04.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 16 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 17 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 29 instances of too long lines in the document, the longest one being 9 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 683 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 (6 December 2002) is 7811 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2284' is mentioned on line 62, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) -- Looks like a reference, but probably isn't: '1' on line 351 == Missing Reference: 'RFC2548' is mentioned on line 374, but not defined -- Looks like a reference, but probably isn't: '2' on line 376 == Unused Reference: 'RFC2434' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'SHA' is defined on line 631, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) == Outdated reference: A later version (-10) exists of draft-ietf-pppext-rfc2284bis-08 ** 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 (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group Bernard Aboba 3 INTERNET-DRAFT Dan Simon 4 Category: Informational Microsoft 5 6 6 December 2002 8 EAP Key Management Guidelines 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 EAP key 40 management algorithms can be discussed and evaluated. 42 Table of Contents 44 1. Introduction .......................................... 3 45 1.1 Requirements language ........................... 4 46 1.2 Terminology ..................................... 4 47 2. EAP architecture overview ............................. 5 48 2.1 Implications of the architecture ................ 8 49 2.2 EAP key hierarchy ............................... 9 50 3. EAP Keying Requirements ............................... 10 51 3.1 EAP method requirements ......................... 10 52 3.2 Ciphersuite requirements ........................ 13 53 4. Security considerations ............................... 14 54 5. Normative references .................................. 14 55 6. Informative references ................................ 14 56 Acknowledgments .............................................. 16 57 Author's Addresses ........................................... 16 58 Intellectual Property Statement .............................. 16 59 Full Copyright Statement ..................................... 17 60 1. Introduction 62 The Extensible Authentication Protocol (EAP), defined in [RFC2284], was 63 developed to provide extensible authentication for use with PPP 64 [RFC1661]. Since then, new applications of EAP have emerged, including 65 IEEE 802.1X network port authentication [IEEE8021X], and PIC [PIC]. 67 The primary purpose of EAP is to authenticate an EAP Client to a Network 68 Access Server (NAS), as well as to provide keys for use with a 69 ciphersuite. EAP presumes that prior to authentication, the EAP Client 70 and NAS have located each other via some out-of-band mechanism. For 71 example, for use with PPP, the Client might contain a phone book that 72 would provide phone numbers of NASes used with the selected service. In 73 IEEE 802.11, the Client (also known as a Station) may locate NAS devices 74 (also known as Access Points) using the IEEE 802.11 Beacon and Probe 75 Request/Response frames. EAP also assumes that ciphersuite negotiation 76 and selection is done out-of-band, and therefore need not be handled 77 within EAP itself. For example, a Client might be preconfigured with the 78 ciphersuite to be used in communicating with a given NAS, or 79 alternatively, the ciphersuite may be negotiated out-of-band. For 80 example, within PPP, the ciphersuite is negotiated within the Encryption 81 Control Protocol (ECP) after EAP authentication is completed. Within 82 IEEE 802.11i, the AP capabilities (including ciphersuite) are advertised 83 in the Beacon and Probe Responses, and are verified during a 4-way 84 exchange after EAP authentication has completed. The desired ciphersuite 85 is indicated within the Association/Reassociation Request/Response 86 exchange. 88 EAP methods defined in [RFC2284bis] include EAP MD5, as well as One-Time 89 Password (OTP) and Generic Token Card methods. Each of these methods 90 supports one-way authentication only but not key derivation. However, 91 subsequent EAP method specifications such as EAP TLS [RFC2716], EAP SRP 92 [EAPSRP], EAP GSS [EAPGSS] and EAP AKA [EAPAKA] have provided for mutual 93 authentication, as well as key derivation. 95 The ciphersuites for which EAP may provide keying material have also 96 grown in number. With the increase in the number of EAP methods and 97 applicable ciphersuites, there is a need for defining how transient 98 session keys are derived from the master secrets produced by EAP 99 methods, and how keys are used to provide cryptographic binding between 100 methods used in a sequence or tunnel. Allowing each EAP method to 101 handle this in its own way is likely to produce unacceptable results. 103 This document reviews the issues involved in EAP key derivation and 104 provides guidelines for the generation of keys by EAP methods. 106 1.1. Requirements language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in BCP 14 [RFC2119]. 112 1.2. Terminology 114 This document frequently uses the following terms: 116 Authentication Server 117 An Authentication Server is an entity that provides an 118 Authentication Service to a Network Access Server (NAS). This 119 service verifies from the credentials provided by the Client, 120 the claim of identity made by the Client. Where an 121 Authentication Server is provided, it acts as the EAP server, 122 terminating EAP conversation with the EAP Client. 124 Cryptographic binding 125 The demonstration of the EAP Client to the EAP Server that a 126 single entity has acted as the EAP Client for all methods 127 executed within a sequence or tunnel. Binding MAY also imply 128 that the EAP Server demonstrates to the Client that a single 129 entity has acted as the EAP Server for all methods executed 130 within a sequence or tunnel. If executed correctly, binding 131 serves to mitigate man-in-the-middle vulnerabilities. 133 Master key (MK) 134 The key derived between the EAP Client and Server during the 135 EAP authentication process. 137 Network Access Server (NAS) 138 The device that provides access to the network. Where no 139 Authentication Server is present, the NAS acts as the EAP 140 Server, terminating the EAP conversation with the Client. 141 Where an Authentication Server is present, the NAS may act as 142 a passthrough for one or more authentication methods and for 143 non-local users. 145 Pairwise Master Key (PMK) 146 Pairwise Master Keys (PMKs) are derived from the Master Key 147 (MK) and are subsequently used in generation of Transient 148 Session Keys (TSKs) for use in the selected ciphersuite. So 149 that the PMKs are usable with any ciphersuite, they are longer 150 than is necessary, and are truncated to fit. 152 Transient Session Keys (TSKs) 153 The EAP Client and NAS derive the TSKs from the PMKs. These 154 are of appropriate size for use with the chosen ciphersuite. 156 2. EAP architecture overview 158 EAP authentication involves a Client, NAS and (optionally) an 159 Authentication Server. One of the goals of EAP is to enable development 160 of new authentication methods without requiring deployment of new code 161 on the NAS. While the NAS may implement some methods locally and use 162 those methods to authenticate local users, it may at the same time act 163 as a "passthrough" for other users and methods. Supporting "passthrough" 164 of authentication to the Authentication Server enables the NAS to 165 support additional non-locally implemented methods. Among other things, 166 this implies that a NAS need not implement code for each EAP method 167 required by authenticating Clients. 169 Figure 1 illustrates the EAP authentication process in the case where 170 the Client is authenticated locally by the NAS using a locally installed 171 authentication method. In this case, the Master Key (MK) and Pairwise 172 Master Keys (PMKs) are derived on the Client and the NAS, which acts as 173 the EAP server during the EAP authentication exchange. The Client and 174 NAS then use the PMK to derive the transient session keys used with the 175 selected ciphersuite. It is assumed that ciphersuite negotiation is 176 handled out of band, rather than within EAP. 178 If the authentication occurs with a method not implemented on the NAS, 179 or involves a non-local user whose credentials the Server is unable to 180 validate, then the NAS functions as a "passthrough". For passthrough 181 authentication methods, instead of requiring code on the NAS, the NAS 182 delegates the authentication to an Authentication Server. The 183 Authentication Server installs the desired EAP methods, typically by 184 interfacing with the operating system via an EAP API, such as that 185 described in [EAPAPI]. 187 In order to allow the Client and Authentication Server to install new 188 EAP methods without requiring an operating system upgrade, operating 189 systems isolate EAP method-specific code within the installed EAP 190 methods, and thus largely operate as "passthrough" entities with respect 191 to EAP. 193 Figure 2 describes the relationship between the EAP Client, NAS and 194 Authentication Server, for authentications which occur in "passthrough" 195 mode. As described in the figure, the EAP conversation may "pass 196 through" the NAS on its way between the Client and the Authentication 197 Server (which acts as the EAP Server in this case). As a result, the 198 NAS does not have knowledge of the keys that are derived between the 199 Authentication Server and the Client, and these keys need to be 200 transmitted from the Authentication Server to the NAS. 202 +-+-+-+-+-+ +-+-+-+-+-+ 203 | | | | 204 | | | | 205 | Cipher- | | Cipher- | 206 | Suite | | Suite | 207 | | | | 208 +-+-+-+-+-+ +-+-+-+-+-+ 209 ^ ^ 210 | | 211 | | 212 | | 213 V V 214 +-+-+-+-+-+ +-+-+-+-+-+ 215 | | EAP | | 216 | | Conversation | | 217 | |<=============>| NAS | 218 | Client | | (EAP | 219 | | | Server) | 220 | | | | 221 | | | | 222 +-+-+-+-+-+ +-+-+-+-+-+ 223 ^ ^ 224 | | 225 | EAP API | EAP API 226 | | 227 V V 228 +-+-+-+-+-+ +-+-+-+-+-+ 229 | | | | 230 | | | | 231 | EAP | | EAP | 232 | Method | | Method | 233 | | | | 234 +-+-+-+-+-+ +-+-+-+-+-+ 236 Figure 1 - Relationship between EAP Client and 237 NAS (acting as an EAP Server) where no 238 Authentication Server is present 240 +-+-+-+-+-+ +-+-+-+-+-+ 241 | | | | 242 | | | | 243 | Cipher- | | Cipher- | 244 | Suite | | Suite | 245 | | | | 246 +-+-+-+-+-+ +-+-+-+-+-+ 247 ^ ^ 248 | | 249 | | 250 | | 251 V V 252 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 253 | | EAP | | | | 254 | | Conversation | | | | 255 | |<================================>| Authent.| 256 | Client | | NAS | | Server | 257 | | | |<=======| | 258 | | | | PMK(s) | (EAP | 259 | | | | | Server) | 260 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 261 ^ ^ 262 | | 263 | EAP API | EAP API 264 | | 265 V V 266 +-+-+-+-+-+ +-+-+-+-+-+ 267 | | | | 268 | | | | 269 | EAP | | EAP | 270 | Method | | Method | 271 | | | | 272 +-+-+-+-+-+ +-+-+-+-+-+ 274 Figure 2 - "Passthrough" relationship between EAP Client, 275 NAS and Authentication Server. 277 EAP methods are installed on the the Client and the Authentication 278 Server, typically communicating via an EAP API, so that the main Client 279 and Authentication Server code does not need to be modified to add new 280 methods. Among the results that are passed back by EAP methods via the 281 APIs are the PMK(s) to be communicated from the Authentication Server to 282 the NAS. Ciphersuites are installed on the NAS and the Client. 284 2.1. Implications of the architecture 286 While EAP methods which derive keys can be used to provide automated 287 keying for a ciphersuite, this does not imply that the EAP method need 288 contain ciphersuite-specific code. Since the Client and NAS need to 289 implement a given ciphersuite, ciphersuite-specific code is expected to 290 exist on the Client and NAS. However, since the Authentication Server 291 is not involved in the protection of data traffic, and may not even be 292 aware of the negotiated ciphersuite, it cannot be assumed to implement 293 ciphersuite-specific code, and the backend Authentication Server will 294 not necessarily have knowledge of the ciphersuites available on the NAS 295 and Client. 297 Since the Authentication Server may not have knowledge of the 298 ciphersuite that has been negotiated, it may not be possible for this 299 information to be passed to the EAP method via the EAP APIs. As a 300 result, inclusion of ciphersuite-specific code within an EAP method may 301 not be possible. 303 Similarly, because the NAS is assumed to not have knowledge of 304 individual EAP methods, it cannot be assumed to include code specific to 305 an EAP method. Moreover, since operating systems provide EAP APIs in 306 order to remain "EAP-Method Agnostic", EAP method-specific code is best 307 kept out of the EAP APIs as well. 309 Drawbacks to allowing EAP methods to specify session key derivation 310 mechanisms for individual ciphersuites include: 312 Document Revision 313 If an EAP method specifies how to derive transient 314 session keys on a per-ciphersuite basis, then this 315 document will need to be revised each time a new 316 ciphersuite comes out. This would also imply that an 317 Authentication Server supporting an EAP method might not 318 be usable with a NAS supporting EAP, due to lack of 319 support for a ciphersuite implemented on the NAS. Since 320 the EAP architecture enables the NAS "passthrough" EAP 321 methods that it does not implement, a NAS implementing 322 EAP can be used to implement any authentication method 323 supported by the Authentication Server and Client, not 324 just locally implemented methods. 326 EAP method complexity 327 Forcing the EAP method to include ciphersuite-specific 328 code for transient session key derivation increases the 329 complexity of EAP method development, as well as Client 330 and Authentication Server implementations. 332 Knowledge asymmetry 333 In practice, an EAP method may not have knowledge of the 334 ciphersuite that has been negotiated. In PPP, negotiation 335 of the ciphersuite is accomplished via the Encryption 336 Control Protocol (ECP), described in [RFC1968]. Since 337 ECP negotiation occurs after authentication, unless an 338 EAP method is utilized that supports ciphersuite 339 negotiation (such as EAP-TLS [RFC2716]), the Client, NAS 340 and backend Authentication Server may not be able to 341 anticipate the ciphersuite that will be used and 342 therefore this information cannot be provided to the EAP 343 method. 345 2.2. EAP Key hierarchy 347 In the most general case, ciphersuite-specific keys must be derived from 348 the master secret (K) derived by the EAP method. This is accomplished 349 in two steps. 351 [1] Derivation of the PMK from the Master Key. Using a one-way 352 function, the EAP method derives the Pairwise Master Keys (PMKs) 353 from the master key. Since any entity possessing the master key can 354 impersonate the client and authentication server, the master key 355 MUST be kept local to the client and authentication server and MUST 356 NOT be provided to the NAS. However, the client and NAS need to 357 share a key in order to subsequently derive ciphersuite-specific 358 keys to protect subsequent data communications. Deriving the PMK 359 from the master key via a one-way function enables the 360 Authentication Server to provide the PMK(s) to the NAS without 361 compromising the master key. Note that the PMK(s) are never 362 directly used by the ciphersuitesw; they are only used in the 363 derivation of transient session keys. The Client and Authentication 364 Server compute the PMK(s) within the EAP method; the Authentication 365 Server then transmits the PMK(s) to the NAS. 367 Examples of Pairwise Master Key (PMK) derivation algorithms are 368 provided in Section 3.5 of EAP TLS [RFC2716]. In that document, the 369 PMK(s) are referred to as "Master Session Keys", and are derived 370 based on the Pseudo-Random Function (PRF) defined in TLS [RFC2246]. 371 Equivalent algorithms are provided in IKE [RFC2409] for the 372 derivation of SKEYID_d, SKEYID_a and SKEYID_e from the master key 373 SKEYID. RADIUS attributes for PMK transport are provided in 374 [RFC2548]. 376 [2] Derivation of the "transient session keys" from the PMK(s). The 377 "transient session keys" are used by the ciphersuite negotiated 378 between the EAP client and NAS. Depending on the negotiated 379 ciphersuite and media, the algorithms for "transient session key" 380 derivation may differ. For example, 802.11 WEP does not provide a 381 keyed message integrity check, and typically uses only a single 382 encryption key in both directions. On the hand, PPP MPPE [RFC3079] 383 requires encryption keys in both directions. 385 Note that the master key may not be directly available within all EAP 386 methods. For security reasons, the TLS master secret is typically not 387 directly available via TLS APIs. As a result, [RFC2716] derives PMKs 388 from the TLS master secret. 390 Since EAP TLS [RFC2716] does not assume knowledge of the negotiated 391 ciphersuite, it provides PMKs large enough for use with any ciphersuite, 392 assuming that these will be truncated for use within the Client and NAS. 393 Since the raw master secret is typically not available in to EAP-TLS 394 implementations, when this EAP method is used, the TLS PRF function is 395 needed to derive keying material from it. 397 Other EAP methods may also encounter similar issues. For example, EAP 398 GSS implementations will typically not be able to access the master keys 399 directly, but can call GSS_Wrap() to encrypted tokens and GSS_GetMIC() 400 to generate authentication tokens based on the master secret. EAP GSS 401 implementations will therefore need to use GSS-API calls to derive 402 PMK(s) from the master key, rather than operating on the master key 403 directly. 405 Where the master key K is not exportable, an intermediate step is 406 required to generate a "Pseudo-Master Key" from the master key. For 407 example, in [EAPGSS], a "Pseudo-Master Key", K' is derived via GSS-API 408 calls, and is used instead. 410 The steps by which the Transient Session Keys (TSKs) are derived from 411 the Master Key (MK) are illustrated in Figure 3 on the next page. 413 3. EAP Keying requirements 415 This section describes the keying requirements of EAP methods that MUST 416 be met by method specifications requesting publication as an RFC. 418 3.1. EAP method requirements 420 Key derivation 421 Methods listing IEEE 802.11 WLANs as the intended medium MUST 422 support key derivation. 424 Algorithm specification 425 Methods supporting key derivation MUST include a specification for 426 the derivation of the PMK from the Master Key. 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+--- 429 | | | | ^ 430 | Is a raw master key | | Can a pseudo-master key | | 431 | available or can | | be derived from | | 432 | the PRF operate on it? | | the master key? | | 433 | | | | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 435 | | | 436 | K | K' | 437 | | | 438 V V | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 440 | | | 441 | Pairwise Master Key | EAP | 442 | Derivation | Method | 443 | | | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EAP V 445 | | API ---+--- 446 | Pairwise Master Key(s) | | 447 | | | 448 | | AAA | 449 | | Keys V 450 V V ---+--- 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 452 | | | 453 | Ciphersuite-Specific Key Hierarchy | NAS | 454 | and Derivation | | 455 | | V 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+--- 458 Figure 3 - Architecture for derivation of ciphersuite-specific 459 session key from the EAP master key K. 461 Ciphersuite independence 462 The algorithm for deriving the PMK(s) from the "master key" 463 provided by the EAP method MUST be ciphersuite-independent. The 464 algorithm MUST NOT require ciphersuite-specific code to be 465 implemented within an EAP method. 467 One-way function 468 Given the PMK, it MUST NOT be possible to derive the Master Key. 470 Key size 471 An EAP method supporting key derivation SHOULD generate a PMK of at 472 least 512 bits in length. 474 Standard Keying AVPs 475 In order to enable Authentication Servers to provide keying 476 material to the NAS in a well defined format, AAA servers SHOULD 477 use ciphersuite-independent AAA attributes to transmit the PMK(s) 478 from the Authentication Server to the NAS. Since it is assumed 479 that the Authentication Server will perform the required 480 calculations to compute the PMK(s), the PMK derivation algorithm 481 need not be implemented on the NAS. 483 Key Entropy 484 The strength of the session keys is dependent upon the security of 485 the EAP method providing the keying material. If the chosen EAP 486 method has security vulnerabilities, or does not produce a key of 487 sufficient entropy then it is possible that weak session keys may 488 be produced. An EAP method supporting key derivation SHOULD 489 generate PMK(s) with at least 128 bits of entropy. 491 Nonce exchange 492 In order to assure non-repetition of the PMK, the PMK derivation 493 SHOULD include a two-way nonce exchange, using nonces of at least 494 128-bits. 496 Known-good algorithms 497 The derivation and validation of key derivation algorithms is 498 difficult, and as a result it is highly desirable to reuse existing 499 algorithms. This enables the security community to carefully 500 analyze the proposed algorithm; such an analysis would be difficult 501 were multiple algorithms to proliferate. As a result, EAP methods 502 SHOULD utilize well established and analyzed mechanisms for 503 deriving the PMK from the Master Key. 505 3.2. Ciphersuite requirements 507 The derivation of transient session keys from PMK(s) occurs after the 508 ciphersuite has been determined. Ciphersuites looking to be keyed by 509 EAP methods need to provide the following facilities: 511 TSK specification 512 In order to use the PMK(s) provided by EAP methods, ciphersuites 513 keyed via EAP need to define how transient session keys are derived 514 from the PMK(s) provided by EAP methods. 516 EAP method independence 517 Algorithms for deriving transient session keys from PMK(s) 518 MUST NOT depend on the EAP method. Derivation of transient 519 session keys occurs on the client as well as on the NAS, which 520 acts as a "passthrough" for EAP. Therefore the NAS cannot be 521 expected to have knowledge of the EAP method that has been 522 negotiated. 524 Cryptographic separation 525 The transient session keys derived from the PMK(s) MUST be 526 cryptographically independent. That is, given one of the 527 transient session keys it MUST NOT be possible to derive other 528 transient session key(s). 530 PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE 531 [RFC3078]. The DES algorithm is described in [FIPSDES], and DES modes 532 (such as CBC, used in RFC 2419 and DES-EDE3-CBC, used in RFC 2420) are 533 described in [DESMODES]. For PPP DESEbis, a single 56-bit encryption 534 key is required, used in both directions; for PPP 3DES, a 168-bit 535 encryption key is needed, used in both directions. As described in 536 [RFC2419] and [RFC2420] for both protocols, the IV, which is different 537 in each direction, is "deduced from an explicit 64-bit nonce, which is 538 exchanged in the clear during the negotiation phase." 540 For MPPE, 40-bit, 56-bit or 128-bit encryption keys can be required in 541 each direction, as described in [RFC3078]. Since MPPE is based on the 542 RC4 algorithm, no initialization vector is required. While these PPP 543 ciphersuites provide encryption, they do not provide a per-packet keyed 544 message integrity check (MIC). Thus, an authentication key is not 545 required in either direction. 547 Within 802.11, ciphersuites include WEP-40, described in [IEEE80211], 548 which requires a 40-bit encryption key, the same in either direction; 549 and WEP-128, which requires a 104-bit encryption key, the same in either 550 direction. These ciphersuites also do not include a keyed MIC. 552 Recently, new ciphersuites have been proposed for use with 802.11 that 553 do provide per-packet authentication as well as encryption 554 [IEEE80211Tgi]. These ciphersuites use either 104-bit or 128-bit keys, 555 and include definition of their own ciphersuite-specific key hierarchy. 557 4. Security considerations 559 The subject of this document is security. 561 5. Normative References 563 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 564 51, RFC 1661, July 1994. 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, March 1997. 569 [RFC2246] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", RFC 570 2246, November 1998. 572 [RFC2284bis] 573 Blunk, L., Vollbrecht, J., Aboba, B., "Extensible 574 Authentication Protocol (EAP)", Internet draft (work in 575 progress), draft-ietf-pppext-rfc2284bis-08.txt, December 2002. 577 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 578 RFC 2409, November 1998. 580 [IEEE8021X] 581 IEEE Standards for Local and Metropolitan Area Networks: Port 582 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 584 6. Informative References 586 [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 587 1996. 589 [RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 590 Version 2 (DESE-bis)", RFC 2419, September 1998. 592 [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", 593 RFC 2420, September 1998. 595 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 596 Considerations Section in RFCs", BCP 26, RFC 2434, October 597 1998. 599 [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", 600 RFC 2716, October 1999. 602 [RFC3078] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption 603 (MPPE) RFC 3078, March 2001. 605 [RFC3079] Zorn, G. "Deriving Keys for use with Microsoft Point-to-Point 606 Encryption (MPPE)," RFC 3079, March 2001. 608 [EAPGSS] Aboba, B., "EAP GSS Authentication Protocol", Internet draft 609 (work in progress), draft-aboba-pppext-eapgss-12.txt, April 610 2002. 612 [EAPAKA] Arkko, J., Haverinen, H., "EAP AKA Authentication", Internet 613 draft (work in progress), draft-arkko-pppext-eap-aka-05.txt, 614 October 2002. 616 [EAPSRP] Carlson, J., Aboba, B., Haverinen, H., "PPP EAP SRP-SHA1 617 Authentication Protocol", Internet-draft (work in progress), 618 draft-ietf-pppext-eap-srp-03.txt, July 2001. 620 [FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS 621 PUB 46 (January 1977). 623 [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE 624 Credential Provisioning Protocol", Internet draft (work in 625 progress), draft-ietf-ipsra-pic-06.txt, October 2002. 627 [DESMODES] 628 National Bureau of Standards, "DES Modes of Operation", FIPS 629 PUB 81 (December 1980). 631 [SHA] National Institute of Standards and Technology (NIST), 632 "Announcing the Secure Hash Standard," FIPS 180-1, U.S. 633 Department of Commerce, 04/1995 635 [IEEE80211Tgi] 636 IEEE Draft 802.11i/D2, "Draft Supplement to STANDARD FOR 637 Telecommunications and Information Exchange between Systems - 638 LAN/MAN Specific Requirements - Part 11: Wireless Medium 639 Access Control (MAC) and physical layer (PHY) specifications: 640 Specification for Enhanced Security", July 2001. 642 [IEEE80211] 643 Information technology - Telecommunications and information 644 exchange between systems - Local and metropolitan area 645 networks - Specific Requirements Part 11: Wireless LAN Medium 646 Access Control (MAC) and Physical Layer (PHY) Specifications, 647 IEEE Std. 802.11-1997, 1997. 649 [EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API", August 650 2000, http://msdn.microsoft.com/library/ 651 default.asp?url=/library/en-us/eap/eapport_0fj9.asp 653 Acknowledgments 655 Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, 656 Dorothy Stanley of Agerem and Russ Housley of RSA Security for useful 657 feedback. 659 Author Addresses 661 Bernard Aboba 662 Microsoft Corporation 663 One Microsoft Way 664 Redmond, WA 98052 666 EMail: bernarda@microsoft.com 667 Phone: +1 425 706 6605 668 Fax: +1 425 936 7329 670 Dan Simon 671 Microsoft Research 672 Microsoft Corporation 673 One Microsoft Way 674 Redmond, WA 98052 676 EMail: dansimon@microsoft.com 677 Phone: +1 425 706 6711 678 Fax: +1 425 936 7329 680 Intellectual Property Statement 682 The IETF takes no position regarding the validity or scope of any 683 intellectual property or other rights that might be claimed to pertain 684 to the implementation or use of the technology described in this 685 document or the extent to which any license under such rights might or 686 might not be available; neither does it represent that it has made any 687 effort to identify any such rights. Information on the IETF's 688 procedures with respect to rights in standards-track and standards- 689 related documentation can be found in BCP-11. Copies of claims of 690 rights made available for publication and any assurances of licenses to 691 be made available, or the result of an attempt made to obtain a general 692 license or permission for the use of such proprietary rights by 693 implementors or users of this specification can be obtained from the 694 IETF Secretariat. 696 The IETF invites any interested party to bring to its attention any 697 copyrights, patents or patent applications, or other proprietary rights 698 which may cover technology that may be required to practice this 699 standard. Please address the information to the IETF Executive 700 Director. 702 Full Copyright Statement 704 Copyright (C) The Internet Society (2002). All Rights Reserved. 705 This document and translations of it may be copied and furnished to 706 others, and derivative works that comment on or otherwise explain it or 707 assist in its implementation may be prepared, copied, published and 708 distributed, in whole or in part, without restriction of any kind, 709 provided that the above copyright notice and this paragraph are included 710 on all such copies and derivative works. However, this document itself 711 may not be modified in any way, such as by removing the copyright notice 712 or references to the Internet Society or other Internet organizations, 713 except as needed for the purpose of developing Internet standards in 714 which case the procedures for copyrights defined in the Internet 715 Standards process must be followed, or as required to translate it into 716 languages other than English. The limited permissions granted above are 717 perpetual and will not be revoked by the Internet Society or its 718 successors or assigns. This document and the information contained 719 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 720 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 721 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 722 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 723 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 725 Expiration Date 727 This memo is filed as , and 728 expires July 22, 2003.