PPPEXT Working Group Bernard Aboba INTERNET-DRAFT Dan Simon Category: Informational Microsoft <draft-aboba-pppext-key-problem-00.txt> 4 November 2001 The EAP Session Key Problem Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 (2001). All Rights Reserved. Abstract This document makes the case for standardizing the algorithms used to derive authentication and encryption transient session keys from the master keying material derived by EAP methods. As EAP methods proliferate, allowing each EAP method to define its own ciphersuite- specific key derivation algorithms will compromise the security and generality that EAP was intended to provide. Aboba & Simon Informational [Page 1]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 Table of Contents 1. Introduction .......................................... 3 1.1 Requirements language ........................... 3 1.2 Terminology ..................................... 3 1.3 EAP overview .................................... 3 1.4 Problem overview ................................ 4 2. Proposed architecture ................................ 6 2.1 Solution requirements ........................... 8 3. Security considerations ............................... 10 4. References ............................................ 10 Acknowledgments .............................................. 13 Author's Addresses ........................................... 14 Intellectual Property Statement .............................. 14 Full Copyright Statement ..................................... 14 Aboba & Simon Informational [Page 2]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 1. Introduction 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 [18]. 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. Master key The session key derived between the EAP client and EAP server during the EAP authentication process. Master session key The keys derived from the master key that are subsequently used in generation of the transient session keys for authentication, encryption, and IV-generation. So that the master session keys are to be usable with any ciphersuite, they are longer than is necessary, and are truncated to fit. Transient session keys The chosen ciphersuites 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. 1.3. EAP overview The Extensible Authentication Protocol (EAP), defined in RFC 2284 [9], was developed to provide extensible authentication for use with PPP [1]. Since then, new applications of EAP have emerged, including IEEE 802.1X network port authentication, defined in [21], and provisioning of certificates based of legacy authentication methods via PIC, defined in [38]. EAP was developed in part to enable deployment of new authentication methods without requiring deployment of new code on the NAS. As a result, the NAS acts as a "passthrough", and does not need to understand Aboba & Simon Informational [Page 3]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 specific EAP methods. Among other things, this implies that a NAS cannot be assumed to contain code specific to any EAP method. Instead of requiring new code to be installed on the NAS in order to support a new EAP method, EAP method support is added to the client and backend authentication server. EAP method support is typically provided via an EAP API, such as that described in [42]. 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 also operate as "passthrough" entities with respect to EAP. Since the client and NAS will need to contain code to implement any particular ciphersuite, it is reasonable to assume that ciphersuite- specific code exists on these entities. However, just as the NAS should not need to be updated to support a new EAP method, the backend authentication server should not need to be updated to support a new ciphersuite on the NAS. Since the backend authentication server is not involved in the protection of data traffic, there is no intrinsic reason that it should need to implement ciphersuite-specific code. These restrictions, when put together, imply that including ciphersuite- specific code within an EAP method is inappropriate, as is including code specific to an EAP-method within the NAS. 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. 1.4. Problem overview RFC 2284 defined the EAP-MD5, as well as One-Time Password (OTP) and Generic Token Card methods. Since then, the development of additional EAP methods has accelerated. These include EAP-TLS [32], EAP-SRP [37], EAP-GSS [39] and EAP-AKA [40]. Each of these methods is capable of deriving keys, as well as providing for mutual authentication. The ciphersuites for which EAP may provide keying material have also grown in number. Within PPP, ciphersuites include DESEbis [16], 3DES [17], and MPPE [36]. For PPP DESEbis, a 56-bit encryption key is required in each direction; for PPP 3DES, a 168-bit encryption key is needed in each direction; for MPPE, 40-bit, 56-bit or 128-bit encryption keys can be required in each direction, as described in [35],[36]. While these PPP ciphersuites provide encryption, they do not provide a per-packet keyed message integrity check (MIC). Within 802.11, ciphersuites include WEP-40, described in [24], which requires a 40-bit encryption key, which is 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. Aboba & Simon Informational [Page 4]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 Recently, new ciphersuites have been proposed for use with 802.11 that do provide per-packet authentication as well as encryption. These methods, described in [41], require 128-bit authentication and encryption keys in each direction, and are based on AES [43]-[46]. With the increase in the number of EAP methods and applicable ciphersuites, there is a growing need for supplying algorithms to derive transient session keys from master keys produced by EAP methods. To date, this need has been filled on a piece-meal basis, with EAP methods such as EAP SRP [37], defining transient session key derivation mechanisms for each ciphersuite. There are significant drawbacks to allowing each EAP method to specify session key derivation mechanisms for individual ciphersuites. These 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 assymmetry 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 [10]. Since ECP negotiation occurs after authentication, unless an EAP method is utilized that supports ciphersuite negotiation (such as EAP-TLS [32]), 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 5]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 Similarly, it is also desirable to avoid proliferation of EAP method- specific master session key derivation algorithms. Aside from the duplication of effort this would imply, the deployment of many algorithms, as opposed to a single well-analyzed one, is more likely to create security vulnerabilities. 2. Proposed architecture This document proposes an architecture that avoids the proliferation of EAP method-specific master session key algorithms, as well as ciphersuite-specific transient session key algorithms. In the most general case, authentication and encryption keys as well as initialization vectors must be derived for each direction from the master key K derived by the EAP method. This is accomplished by the adoption of two standard algorithms: [1] An algorithm 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] An algorithm 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, not all of the "transient session keys" will 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 to apply across a wide range of EAP methods. This enables the security community to carefully analyze the proposed algorithm. Such an analysis would be difficult were multiple algorithms to proliferate. The specification of a universal algorithm for master session key derivation also enables development of libraries that can be called by EAP method developers, who otherwise would have to code algorithms independently within each EAP method. This also avoids having to upgrade AAA servers and EAP methods every time a new ciphersuite is developed, Aboba & Simon Informational [Page 6]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 By standardizing the master session key derivation within EAP methods and on the AAA server, the NAS can be assured of obtaining master session keys 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 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". Although the NAS needs to be upgraded to support additional ciphersuites, it is best if the code for generation of "transient session keys" from "master session keys" is as ciphersuite- independent as possible, so as to avoid requiring constant maintenance of the algorithm. The derivation of ciphersuite-specific "transient session keys" from "master session keys" occurs after the ciphersuite has been determined, and provides for authentication and encryption keys as well as IV- generation. Within the proposed architecture, this conversion is also carried out according to a standardized algorithm. The algorithm for deriving "transient session keys" from the "master session keys" is designed to be EAP-method independent, and to apply across a wide range of ciphersuites. This enables its security also to be thoroughly analyzed and for the code to be reused within the NAS where it is expected to reside. Note that the master key may not be directly available within all EAP methods. For security reasons, the TLS master key is typically not directly available via TLS APIs. As a result, RFC 2716 [32] derives master session keys from the TLS master key, and uses those master session keys to derive the required session keys. Since RFC 2716 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 key 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 key. 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. Aboba & Simon Informational [Page 7]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 While method-specific algorithms may be required in some methods, for other methods, the master key is directly available, and so the algorithm used to derive master sesion keys from it can be designed in complete freedom. However, even where such freedom is available, the proliferation of EAP method-specific key derivation algorithms is undesirable. Figure 1 on the next page describes the overall logic of how master session keys and transient session keys are derived from the master key negotiated with 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 [39], a "Pseudo-Master Key", K' is derived via GSS-API calls, and is used instead. 2.1. Solution requirements 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. 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 need to 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. Direct and Indirect Access A satisfactory "master session key" derivation algorithm MUST be applicable to EAP methods where the master key is not directly accessible. These include TLS and GSS-API methods. Aboba & Simon Informational [Page 8]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Master Session Key | | Derivation | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Master Session Key Outputs | | | V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Key and IV Derivation | | Derivation | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P->A | A->P | P->A | A->P | P->A | A->P | Enc. | Enc. | Auth. | Auth. | IV | IV | Key | Key | Key | Key | | | | | | | | | | | | | | V V V V V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Ciphersuite-Specific Truncation & | | Key utilization | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - Architecture for derivation of session keys from the EAP method master key K. Aboba & Simon Informational [Page 9]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 The algorithm for "transient session key" derivation also needs to fulfill several requirements: EAP method independence The algorithm 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. Generality The algorithm for derivation of "transient session keys" from "master session keys" MUST be suitable for use with a wide range of ciphersuites. In practice, this means that the algorithm must be usable with existing and future ciphersuites. 3. Security considerations 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, then it is possible that weak session keys may be produced. 4. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. [3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994. [4] Lloyd, B., Simpson, W., "PPP Authentication Protocols," RFC 1334, October 1992. [5] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)," RFC 1994, August 1996. [6] Zorn, G., Cobb, S., "Microsoft PPP CHAP Extensions," RFC 2433, October 1998. [7] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2," RFC 2759, January 2000. Aboba & Simon Informational [Page 10]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 [8] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [9] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [10] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996. [11] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977). [12] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 (December 1980). [13] National Institute of Standards and Technology (NIST), "Announcing the Secure Hash Standard," FIPS 180-1, U.S. Department of Commerce, 04/1995 [14] Daemen, Joan and Vincent Rijmen, "AES Proposal: Rijndael", September 1999, <http://www.esat.kuleuven.ac.be/~rijmen/rijndael/>. [15] National Institute of Standards and Technology, "Rijndael: NIST's Selection for the AES", December 2000, <http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf>. [16] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998. [17] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998. [18] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [19] D. Rand. "The PPP Compression Control Protocol", RFC 1962, Novell, June 1996. [20] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [21] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. [22] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Aboba & Simon Informational [Page 11]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 [23] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996. [24] 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. [25] Wu, T., "The Secure Remote Password Protocol", in Proceedings of the 1998 Internet Society Symposium on Network and Distributed Systems Security, San Diego, CA, pp. 97-111 [26] Wu, T., "The Secure Remote Password Protocol", March 1998, <http://srp.stanford.edu/srp/ndss.html>. [27] Wu, T., "The SRP Authentication and Key Exchange System," RFC 2945, September 2000. [28] Wu, T., "SRP: The Open Source Password Authentication Standard", March 1998, <http://srp.stanford.edu/srp/>. [29] Hopwood, D., "Standard Cryptographic Algorithm Naming", June 2000, <http://www.eskimo.com/~weidai/scan-mirror/>. [30] Menezes, A.J., van Oorschot, P.C. and S.A. Vanstone, "Handbook of Applied Cryptography", CRC Press, Inc., ISBN 0-8493-8523-7, 1997, <http://www.cacr.math.uwaterloo.ca/hac/about/chap7.ps>. [31] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [32] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [33] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", RFC 2246, November 1998. [34] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, November 1998. [35] Zorn, G. "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)," RFC 3079, March 2001. [36] Pall, G. and Zorn, G. "Microsoft Point-to-Point Encryption (MPPE) RFC 3078, March 2001. Aboba & Simon Informational [Page 12]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 [37] 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. [38] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE Credential Provisioning Protocol", Internet draft (work in progress), draft- ietf-ipsra-pic-03.txt, July 2001. [39] Aboba, B., "EAP GSS Authentication Protocol", Internet draft (work in progress), draft-aboba-pppext-eapgss-08.txt, October 2001. [40] Arkko, J., Haverinen, H., "EAP AKA Authentication", Internet draft (work in progress), draft-arkko-pppext-eap-aka-00.txt, December 2001. [41] 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. [42] Microsoft Developer Network, "Windows 2000 EAP API", August 2000, http://msdn.microsoft.com/library/default.asp?url=/library/en- us/eap/eapport_0fj9.asp [43] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES Proposal, June 1998. http://csrc.nist.gov/encryption/aes/round2/ AESAlgs/Rijndael/Rijndael.pdf [44] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard (AES)", U.S. DoC/NIST, summer 2001. [45] "Symmetric Key Block Cipher Modes of Operation," http://www.nist.gov/modes. [46] "Recommendation for Block Cipher Modes of Operation", National Institute of Standards and Technology (NIST) Special Publication 800-XX, CODEN: NSPUE2, U.S. Government Printing Office, Washington, DC, July 2001. Acknowledgments Thanks to Arun Ayyagari, Ashwin Palekar, and Tim Moore of Microsoft for useful feedback. Aboba & Simon Informational [Page 13]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 Author Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 706 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 706 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. 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 (2001). 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 Aboba & Simon Informational [Page 14]
INTERNET-DRAFT The EAP Session Key Problem 4 November 2001 assist in its implmentation 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 inthe 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-00.txt>, and expires May 22, 2002. Aboba & Simon Informational [Page 15]