PPPEXT Working Group Bernard Aboba INTERNET-DRAFT Dan Simon Category: Informational Microsoft <draft-aboba-pppext-key-problem-03.txt> 22 October 2002 The EAP Keying Problem Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes the issues involved in key derivation by EAP methods and provides guidelines for generation and usage of EAP keys. Algorithms for key derivation are not specified in this document. Rather, this document lays out a framework within which algorithms can be discussed and evaluated. Aboba & Simon Informational [Page 1]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 Table of Contents 1. Introduction .......................................... 3 1.1 Requirements language ........................... 3 1.2 Terminology ..................................... 4 2. EAP architecture overview ............................. 5 2.1 Implications of the architecture ................ 7 3. EAP Keying Requirements ............................... 8 4. Security considerations ............................... 13 4.1 Key strength .................................... 13 4.2 Man-in-the-middle attacks ....................... 13 5. Normative references .................................. 15 6. Informative references ................................ 16 Acknowledgments .............................................. 17 Author's Addresses ........................................... 17 Intellectual Property Statement .............................. 18 Full Copyright Statement ..................................... 18 Aboba & Simon Informational [Page 2]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 1. Introduction The Extensible Authentication Protocol (EAP), defined in [RFC2284], was developed to provide extensible authentication for use with PPP [RFC1661]. Since then, new applications of EAP have emerged, including IEEE 802.1X network port authentication [IEEE8021X], and PIC [PIC]. Although the initial focus of EAP was authentication, it can also provide keys for use with a ciphersuite, and binding of methods within a sequence or tunnel. EAP methods defined in [RFC2284] include EAP MD5, as well as One-Time Password (OTP) and Generic Token Card methods. Each of these methods supports one-way authentication only but not key derivation. However, subsequent EAP method specifications such as EAP TLS [RFC2716], EAP SRP [EAPSRP], EAP GSS [EAPGSS] and EAP AKA [EAPAKA] have provided for mutual authentication, as well as key derivation. The ciphersuites for which EAP may provide keying material have also grown in number. PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE [RFC3078]. The DES algorithm is described in [FIPSDES], and DES modes (such as CBC, used in RFC 2419 and DES- EDE3-CBC, used in RFC 2420) are described in [DESMODES]. For PPP DESEbis, a single 56-bit encryption key is required, used in both directions; for PPP 3DES, a 168-bit encryption key is needed, used in both directions. As described in [RFC2419] and [RFC2420] for both protocols, the IV, which is different in each direction, is "deduced from an explicit 64-bit nonce, which is exchanged in the clear during the negotiation phase." For MPPE, 40-bit, 56-bit or 128-bit encryption keys can be required in each direction, as described in [RFC3078]. Since MPPE is based on the RC4 algorithm, no initialization vector is required. While these PPP ciphersuites provide encryption, they do not provide a per-packet keyed message integrity check (MIC). Thus, an authentication key is not required in either direction. Within 802.11, ciphersuites include WEP-40, described in [IEEE80211], which requires a 40-bit encryption key, the same in either direction; and WEP-128, which requires a 104-bit encryption key, the same in either direction. These ciphersuites also do not include a keyed MIC. Recently, new ciphersuites have been proposed for use with 802.11 that do provide per-packet authentication as well as encryption [IEEE80211Tgi]. These ciphersuites use either 104-bit or 128-bit keys, and include definition of their own ciphersuite-specific key hierarchy. With the increase in the number of EAP methods and applicable ciphersuites, there is a need for defining how transient session keys are derived from the master secrets produced by EAP methods, and how Aboba & Simon Informational [Page 3]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 keys are used to provide cryptographic binding between methods used in a sequence or tunnel. Allowing each EAP method to handle this in its own way is likely to produce unacceptable results. This document reviews the issues involved in EAP key derivation and provides guidelines for the generation of keys by EAP methods. 1.1. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. 1.2. Terminology This document frequently uses the following terms: Authentication Server An Authentication Server is an entity that provides an Authentication Service to an NAS. This service verifies from the credentials provided by the peer, the claim of identity made by the peer. Cryptographic binding The demonstration of the EAP peer to the authenticator that a single entity has acted as the EAP peer for all methods executed within a sequence or tunnel. Binding MAY also imply that the EAP authenticator demonstrates to the peer that a single entity has acted as the EAP authenticator for all methods executed within a sequence or tunnel. If executed correctly, binding serves to mitigate man-in-the-middle vulnerabilities. Master key The key derived between the EAP client and EAP server during the EAP authentication process. Master session key Master session keys are derived from the master key, and are subsequently used in generation of transient session keys for authentication, encryption and IV-generation. Since the transient session keys may be different in each direction, master session keys are also required in each direction, and are therefore referred to as "asymmetrical". So that the master session keys are to be usable with any ciphersuite, they are longer than is necessary, and are truncated to fit. Aboba & Simon Informational [Page 4]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 Transient session keys The chosen ciphersuite uses transient session keys for authentication and encryption as well as IVs (if required). The transient session keys are derived from the master session keys, and are of the appropriate size for use with the chosen ciphersuite. Depending on the ciphersuite, the transient session keys may be different in each direction. 2. EAP architecture overview One of the goals of EAP is to enable development of new authentication methods without requiring deployment of new code on the NAS. As a result, the NAS acts as a "passthrough", and need not understand specific EAP methods. Among other things, this implies that a NAS need not contain code specific to each EAP method. EAP Instead of requiring new code on the NAS, EAP methods are installed on the client and backend authentication server, typically interfacing with the operating system via an EAP API, such as that described in [EAPAPI]. In order to allow the client and backend server to install new EAP methods without requiring an operating system upgrade, operating systems isolate EAP method-specific code within the installed EAP methods, and thus largely operate as "passthrough" entities with respect to EAP. Figure 1 describes the relationship between the EAP peer, NAS and AAA server. As described in the figure, the EAP conversation "passes through" the NAS on its way between the client and the AAA server As a result, the NAS does not have knowledge of the keys that are derived between the AAA server and the client, and these keys need to be transmitted from the AAA server to the NAS. EAP methods are installed on the the client and the AAA server, typically communicating via an EAP API, so that the main client and AAA server code does not need to be modified to add new methods. Among the results that are passed back by EAP methods via the APIs are the keys to be communicated from the AAA server to the NAS. Ciphersuites are installed on the NAS and the client. While EAP methods which derive keys can be used to provide automated keying for a ciphersuite, this does not imply that the EAP method need contain ciphersuite-specific code. Since the client and NAS need to implement a given ciphersuite, ciphersuite-specific code is expected to exist on the client and NAS. However, since the backend authentication server is not involved in the protection of data traffic, and may not even be aware of the negotiated ciphersuite, it cannot be assumed to implement ciphersuite-specific code, and the backend authentication server will not necessarily have knowledge of the ciphersuites available on the NAS and client. Aboba & Simon Informational [Page 5]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | Cipher- | | Cipher- | | Suite | | Suite | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | | | | V V +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | | EAP | | | | | | Conversation | | | | | |<================================>| AAA | | Client | | NAS/ | | Server | | | | |<=======| | | | | | Keys | | | | | | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | EAP API | EAP API | | V V +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | EAP | | EAP | | Method | | Method | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 1 - Relationship between EAP client, AAA server and NAS. Aboba & Simon Informational [Page 6]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 2.1. Implications of the architecture Since the backend authentication server may not have knowledge of the ciphersuite that has been negotiated, it may not be possible for this information to be passed to the EAP method via the EAP APIs. As a result, inclusion of ciphersuite-specific code within an EAP method is inappropriate. Similarly, because the NAS is assumed to not have knowledge of individual EAP methods, it cannot be assumed to include code specific to an EAP method. Moreover, since operating systems provide EAP APIs in order to remain "EAP-Method Agnostic", EAP method- specific code is best kept out of the EAP APIs as well. Drawbacks to allowing EAP methods to specify session key derivation mechanisms for individual ciphersuites include: Document Revision If an EAP method specifies how to derive transient session keys on a per-ciphersuite basis, then this document will need to be revised each time a new ciphersuite comes out. This would also imply that an authentication server supporting an EAP method might not be usable with a NAS supporting EAP, due to lack of support for a ciphersuite implemented on the NAS. This is antithetical to the EAP architecture, which conceives of the NAS as a "pass through" device that does not need to understand EAP, and which therefore can work with any EAP method supported by the authentication server. EAP method complexity Forcing the EAP method to include ciphersuite-specific code for transient session key derivation increases the complexity of EAP method development, as well as client and authentication server implementations. Knowledge asymmetry In practice, an EAP method may not have knowledge of the ciphersuite that has been negotiated. In PPP, negotiation of the ciphersuite is accomplished via the Encryption Control Protocol (ECP), described in [RFC1968]. Since ECP negotiation occurs after authentication, unless an EAP method is utilized that supports ciphersuite negotiation (such as EAP-TLS [RFC2716]), the client, NAS and backend authentication server may not be able to anticipate the ciphersuite that will be used and therefore this information cannot be provided to the EAP method. Aboba & Simon Informational [Page 7]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 3. EAP keying requirements In the most general case, authentication and encryption keys as well as initialization vectors must be derived for each direction from the master secret K derived by the EAP method. This can accomplished via the specification of two classes of algorithms: [1] Algorithms for the derivation of "master session keys" from the negotiated master key. The "master session keys" are derived from the master key derived by the EAP method, but are never directly used by ciphersuites; they are only used in the derivation of transient session keys. These "master session keys" are derived on the client and the backend authentication server. The backend authentication server then transmits the "master session keys" to the NAS. [2] Algorithms for the derivation of "transient session keys" from the "master session keys". The "transient session keys" are used for encryption, authentication and IV-generation in each direction, and are derived by the NAS and client, based on the negotiated ciphersuite. Depending on the negotiated ciphersuite and media, a different set of "transient session keys" may be required; for example 802.11 WEP does not provide a keyed message integrity check, and typically uses only a single encryption key in both directions. The algorithm for deriving the "master session keys" from the "master key" is designed to be ciphersuite-independent, and is specific to the EAP method. The goal of this algorithm is to provide master session keys in a well defined format, suitable for passage between the AAA server and the NAS. Examples of master session key derivation algorithms are provided in Section 3.5 of EAP TLS [RFC2716], based on the Pseudo-Random Function (PRF) defined in TLS [RFC2246]. Equivalent algorithms are provided in IKE [RFC2409] for the derivation of SKEYID_d, SKEYID_a and SKEYID_e from the master key SKEYID. Examples of AAA master session key attributes are provided in [RFC2548]. Note that because the derivation and validation of these algorithms is difficult, it is highly desirable to reuse existing algorithms if at all possible. This enables the security community to carefully analyze the proposed algorithm. Such an analysis would be difficult were multiple algorithms to proliferate. However, since each EAP method is different, it is also true that existing algorithms may not fit all situations. Aboba & Simon Informational [Page 8]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 For example, the master key may not be directly available within all EAP methods. For security reasons, the TLS master secret is typically not directly available via TLS APIs. As a result, [RFC2716] derives master session keys from the TLS master secret, and uses those master session keys to derive the required session keys. Since EAP TLS [RFC2716] does not assume knowledge of the negotiated ciphersuite, it provides keys large enough for use with any ciphersuite, assuming that these will be truncated for use within the client and NAS. Since the raw master secret is typically not available in to EAP-TLS implementations, when this EAP method is used, the TLS PRF function is needed to derive keying material from it. Other EAP methods may also encounter similar issues. For example, EAP GSS implementations will typically not be able to access the master keys directly, but can call GSS_Wrap() to encrypted tokens and GSS_GetMIC() to generate authentication tokens based on the master secret. EAP GSS implementations will therefore need to use GSS-API calls to derive master session keys from the master key, rather than operating on the master key directly. By specifying the algorithm by which master session keys are derived within each EAP method, as well as the format by which the master session keys are transmitted from the AAA server to the NAS, the NAS can be assured of obtaining master session keys for each EAP method, in a well-defined format. Since it is assumed that the backend authentication server will perform the required calculations and will supply the NAS with the master session keys, the master session key algorithm need not be implemented on the NAS. Rather, the NAS will only need code for the second algorithm, namely for the derivation of ciphersuite-specific "transient session keys" from "master session keys". The derivation of ciphersuite-specific "transient session keys" from "master session keys" occurs after the ciphersuite has been determined, and provides for the derivation of the keys required within the ciphersuite-specific key hierarchy. The algorithm for deriving "transient session keys" from the "master session keys" is designed to be EAP-method independent, but is dependent on the negotiated ciphersuite and media. Since each ciphersuite and media may have different needs, the algorithms for transient session key derivation will vary according to the ciphersuite and media. Nevertheless, as with master session key derivation algorithms, it is desirable if commonalities can be found, so that the correctness and security of the algorithms can be more easily analyzed. Aboba & Simon Informational [Page 9]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 Figure 2 on the next page describes the overall logic of how master session keys and transient session keys are derived from the master key negotiated within an EAP method. The master key K may be of varying length, and as described earlier, may not be directly available to the EAP method. Where the master key K is not exportable, an intermediate step is required to generate a "Pseudo- Master Key" from the master key. For example, in EAP GSS, as described in [EAPGSS], a "Pseudo-Master Key", K' is derived via GSS-API calls, and is used instead. In order to enable interoperability between backend authentication servers, NASen and EAP clients implementing EAP methods that derive keys, the following is required: Key hierarchy In order to enable the keys derived within EAP methods to be used within any ciphersuite, EAP methods deriving keys need to specify the algorithms for master session key derivation. If possible, it is desirable to reuse existing key derivation techniques, rather than inventing new ones. Ciphersuite keys In order to use the master session keys provided by EAP methods, ciphersuites keyed via EAP need to define how ciphersuite-specific keys are derived from the master session keys provided by EAP methods, based on the ciphersuite-specific key hierarchy. Keying AVPs In order to enable backend authentication servers to provide keying material to the NAS in a well defined format, it is necessary to standardize the attributes used to transmit keys from the backend authentication server to the NAS. The algorithms for derivation of "master session keys" from the master key, and for derivation of "transient session keys" from the "master session keys" are not specified in this document. Rather, the purpose of this document is to lay out a framework within which algorithms can be discussed and evaluated. Aboba & Simon Informational [Page 10]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+--- | | | | ^ | Is a raw master key | | Can a pseudo-master key | | | available or can | | be derived from | | | the PRF operate on it? | | the master key? | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | K | K' | | | | V V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | EAP | | Master Session Key | Method | | Derivation | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Master Session Key Outputs | | | | | V V | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Key and IV Derivation | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | P->A | A->P | P->A | A->P | P->A | A->P EAP V | Enc. | Enc. | Auth. | Auth. | IV | IV API ---+--- | Key | Key | Key | Key | | ^ | | | | | | AAA | | | | | | | Keys V V V V V V V ---+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | | | | Ciphersuite-Specific Key Hierarchy | NAS | | | | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+--- Figure 2 - Architecture for derivation of ciphersuite-specific key hierarchy from the EAP method master key K. Aboba & Simon Informational [Page 11]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 For a proposed "master session key" derivation algorithm to be satisfactory, it needs to fulfill several requirements: Ciphersuite-independence A satisfactory "master session key" derivation algorithm MUST NOT require ciphersuite-specific code to be implemented within an EAP method. In practice, this implies that the master session keys MUST enable derivation of authentication and encryption keys and IVs in both directions. Generality A satisfactory "master session key" derivation algorithm MUST provide master session keys appropriate for use with a wide range of ciphersuites. Among other things, this implies that the master session keys MUST contain sufficient entropy to be usable with existing and future ciphersuites. At a minimum, master session keys SHOULD be at least 256 octets in length. Direct and Indirect Access Satisfactory "master session key" derivation algorithms MUST be applicable to EAP methods where the master key is not directly accessible. These include TLS and GSS-API methods. Generality It is likely that each EAP method will handle the derivation of "master session keys" from "master keys" in a different manner. However, wherever possible, well known algorithms SHOULD be reused, and customized to fit, rather than developing entirely new algorithms. Algorithms for "transient session key" derivation also needs to fulfill several requirements: EAP method independence Algorithms for deriving "transient session keys" from "master session keys" MUST NOT depend on the EAP method. Derivation of "transient session keys" is expected to occur on the NAS, which acts as a "passthrough" for EAP. Therefore the NAS cannot be expected to have knowledge of the EAP method that has been negotiated. Sufficient keying material Algorithms for derivation of "transient session keys" from "master session keys" will typically be dependent on the key hierarchy of the given ciphersuite and media. However, regardless of the specific key hierarchy, the derived "master session key" MUST provide sufficient entropy to enable "transient session keys" to be securely derived. For example, Aboba & Simon Informational [Page 12]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 an EAP method that generates a "master session key" with only 56 bits of entropy will not be adequate. 4. Security considerations 4.1. Key strength The strength of the session keys is dependent upon the security of the EAP method providing the master keying material. If the chosen EAP method has security vulnerabilities, or does not produce a key of sufficient entropy then it is possible that weak session keys may be produced. 4.2. Man-in-the-middle attacks Since EAP is widely implemented on multiple media, man-in-the-middle attacks are a fundamental concern. Where methods are used within a sequence or tunnel, cryptographic binding between the methods and (if present) the tunnel, is required so that a single peer and authenticator can be demonstrated to have taken part in the entire exchange. Without cryptographic binding, a man-in-the-middle attack may be enabled as described in Figure 3. +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | | | | | | EAP | +--------+ | | Client | Conversation |Attacker | Tunnel | | | |<================================>| NAS | | | | | | | | | | +--------+ | | | | | | | | | | | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ Figure 3 - Man-in-the-middle attack on EAP tunnel In the figure, the NAS (otherwise known as the EAP authenticator) supports authentication via tunneled EAP. If the EAP tunneling mechanism does not require client authentication, then an attacker can establish a tunnel to the NAS without having to authenticate itself. The attacker can then induce an unsuspecting client to authenticate to it. The attacker then tunnels EAP packets from the client to the NAS, authenticating itself to the NAS. Aboba & Simon Informational [Page 13]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 This would not constitute a true man-in-the-middle attack however, unless the attacker were also able to obtain the keys used to encrypt data between the client and the NAS. Since the EAP conversation occurs between the client and the NAS, a well designed EAP method would not permit the attacker to obtain the key derived between the client and NAS. However, if the key were to be derived solely from the tunnel setup between the attacker and NAS, then the attacker obtains the key without having to execute a man-in-the-middle attack on the EAP method itself. EAP tunneling protocols MUST demonstrate how they protect against this attack, by allowing the client to provide the authenticator with a cryptographic binding between the tunnel and the encapsulated methods. Another variety of attack is illustrated in Figure 4. +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | Client | EAP Method 2 | NAS 1 | | NAS 2 | | |<================================>| | | | EAP Method 1 | | | | | |<=============>| | | | | | | | | | | | | | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ Figure 4. Man-in-the-middle attack on EAP sequence In this attack, EAP method 1 is terminated on NAS 1, but EAP method 2 is proxied by NAS 1 to NAS 2. If the intent of the client is to require a single NAS to authenticate via two factors (say, a password/cert and a token) then this will not have been demonstrated. In order to provide the client with the assurance that a single NAS has acted as the authenticator for all methods within the sequence, the authenticator needs to demonstrate to the client a cryptographic binding between the sequence of EAP methods. The cryptographic binding may be demonstrated via a computation involving the keys generated during the EAP method sequence, as well as keys derived during tunnel setup. Where this is the case, it is not possible to bind EAP methods which do not derive keys. For an EAP method which does not derive keys to demonstrate cryptographic binding, the method as well as the EAP implementation would need to to support method-specific binding -- which existing methods and EAP implementations typically do not. For example, to allow the EAP method to incorporate keys derived by other methods, the EAP Aboba & Simon Informational [Page 14]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 implementation would need to support passing of keys between methods and the method would need to be able to make use of the passed keys. Such a method would not be implementable within an EAP implementation that did not support a key passing facility. The result is that typically only EAP methods that derive keys can be cryptographically bound in an interoperable way. 5. Normative References [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", RFC 2246, November 1998. [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. 6. Informative References [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996. [RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998. [RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998. [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. Aboba & Simon Informational [Page 15]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 [RFC3078] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption (MPPE) RFC 3078, March 2001. [RFC3079] Zorn, G. "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)," RFC 3079, March 2001. [EAPGSS] Aboba, B., "EAP GSS Authentication Protocol", Internet draft (work in progress), draft-aboba-pppext-eapgss-12.txt, April 2002. [EAPAKA] Arkko, J., Haverinen, H., "EAP AKA Authentication", Internet draft (work in progress), draft-arkko-pppext-eap-aka-05.txt, October 2002. [EAPSRP] Carlson, J., Aboba, B., Haverinen, H., "PPP EAP SRP-SHA1 Authentication Protocol", Internet-draft (work in progress), draft-ietf-pppext-eap-srp-03.txt, July 2001. [FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977). [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE Credential Provisioning Protocol", Internet draft (work in progress), draft-ietf-ipsra-pic-06.txt, October 2002. [DESMODES] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 (December 1980). [SHA] National Institute of Standards and Technology (NIST), "Announcing the Secure Hash Standard," FIPS 180-1, U.S. Department of Commerce, 04/1995 [IEEE80211Tgi] IEEE Draft 802.11i/D2, "Draft Supplement to STANDARD FOR Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security", July 2001. [IEEE80211] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1997, 1997. Aboba & Simon Informational [Page 16]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 [EAPAPI] Microsoft Developer Network, "Windows 2000 EAP API", August 2000, http://msdn.microsoft.com/library/ default.asp?url=/library/en-us/eap/eapport_0fj9.asp Acknowledgments Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft, Dorothy Stanley of Agerem and Russ Housley of RSA Security for useful feedback. Author Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329 Dan Simon Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: dansimon@microsoft.com Phone: +1 425 706 6711 Fax: +1 425 936 7329 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Aboba & Simon Informational [Page 17]
INTERNET-DRAFT The EAP Keying Problem 22 October 2002 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expiration Date This memo is filed as <draft-aboba-pppext-key-problem-03.txt>, and expires April 22, 2003. Aboba & Simon Informational [Page 18]