PPPEXT Working Group Vivek Kamath INTERNET-DRAFT Ashwin Palekar Category: Informational Mark Wodrich <draft-kamath-pppext-peapv0-00.txt> Microsoft 25 October 2002 Microsoft's PEAP version 0 (Implementation in Windows XP SP1) 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 specification documents the implementation of PEAP supported in Windows XP SP1. This implementation utilizes a version number of zero (0) and supports acknowledged and protected success and failure indications, using the EAP Extensions method, Type 33. Kamath, Palekar & Wodrich Informational [Page 1]
INTERNET-DRAFT PEAP Version 0 25 October 2002 Table of Contents 1. Introduction .......................................... 3 1.1 EAP encapsulation ............................... 3 1.2 Version field ................................... 3 1.3 EAP Extensions method ........................... 4 2. Details of EAP extensions method ...................... 4 2.1 Extensions Request Packet ....................... 4 2.2 Extensions Response Packet ...................... 5 2.3 AVP format ...................................... 6 3. Security considerations ............................. 7 3.1 Authentication and integrity protection ......... 7 3.2 Outcomes ........................................ 7 4. Normative references ................................ 8 5. Informative references .............................. 9 Appendix A - Examples ........................................ 10 Acknowledgments .............................................. 18 Author's Addresses ........................................... 18 Intellectual Property Statement .............................. 18 Full Copyright Statement ..................................... 19 Kamath, Palekar & Wodrich Informational [Page 2]
INTERNET-DRAFT PEAP Version 0 25 October 2002 1. Introduction Microsoft's Windows XP SP1 implementation of PEAP version 0 differs in the following ways from the protocol specified in [PEAP]. Version field EAP encapsulation Acknowledged and protected success and failure using EAP extensions method PEAP protocol [PEAP] supports versioning and hence servers and clients can support multiple versions of the protocol. [PEAP] is currently at version 1. Each of these differences is explained in the sections that follow. 1.1. EAP encapsulation The [PEAP] specification requires that EAP packets be tunneled within a TLS channel in their entirety. However, the Windows XP SP1 implementation of PEAP does not include an EAP header on packets sent within the TLS channel, except for EAP Extension packets (Type 33), where the complete header is sent. As a result, for EAP Types other than 33, the Code, Identifier, and Length fields are not sent, but rather EAP packets sent within the PEAP tunnel begin with the Type field. While the Code, Identifier and Length fields are not sent over the wire, they are reconstructed at the receiver prior to EAP processing. For example, the Code and Identifier fields of the tunneled EAP packet are assumed to be the same as the equivalent fields within the outer EAP header, and the Length field of the tunneled EAP packet is derived from the Length field of the PEAP packet. This has the following implications: [a] The Code field of the tunneled EAP packet is assumed to be the same as the Code field of the PEAP packet. This may not always be the case; for example, an EAP Success or Failure packet (Code 3 and 4) may be tunneled within a PEAP Request packet (Code 1). This means that the Windows XP SP1 implementation of PEAP is incapable of tunneling arbitrary EAP packets. [b] Since the full EAP header is sent for the EAP Extensions type (Type 33), but not for other Types, it is difficult for the implementation to distinguish an Extensions Request (Code 1) from an EAP Type 1 (Identity) Request packet. In practice, this implies that the Windows XP SP1 PEAP implementation can only support authentication using a single EAP method per session. Kamath, Palekar & Wodrich Informational [Page 3]
INTERNET-DRAFT PEAP Version 0 25 October 2002 1.2. Version Field [PEAP] is currently a work-in-progress. In order to allow for backward compatibility once the final specification of PEAP is completed, a version field of zero (0) is used, rather than the value of one (1) required for conformant implementations as specified in [PEAP]. Note that use of distinct version numbers enables backward compatibility once the final specification of PEAP is complete. Version negotiation takes place at the start of the conversation, with the authenticator indicating its highest supported version. The peer then responds with the highest version it supports. The conversation will then occur using the highest version supported by both parties. This behavior is illustrated in the last example in Appendix A. 1.3. EAP extensions method The [PEAP] termination mechanism (sending an encrypted EAP Success or EAP Failure packet) does not function correctly with Authenticators implementing [IEEE8021X]. Since IEEE 802.1X authenticators "manufacture" a clear-text EAP Success based on receipt of a RADIUS Access-Accept, or a clear-text EAP Failure based on receipt of a RADIUS Access-Reject, unless an acknowledged success/failure indication is used, the PEAP Supplicant may never receive a protected success/failure indication. This leaves the PEAP Supplicant open to attack. As a result, the Windows XP SP1 PEAP implementation supports acknowledged and protected success/failure indications, using the EAP Extensions method (Type 33). 2. Details of EAP extensions method The packet formats for the EAP Extensions method (type 33) follow. 2.1. Extensions Request Packet A summary of the Extensions Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Data.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 Kamath, Palekar & Wodrich Informational [Page 4]
INTERNET-DRAFT PEAP Version 0 25 October 2002 Identifier The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each Request packet. Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Type 33 - EAP Extensions Data The Data field is of variable length, and contains Attribute-Value Pairs (AVPs). 2.2. Extensions Response Packet A summary of the Extensions Response packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Data.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 Identifier The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each Request packet. Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Type Kamath, Palekar & Wodrich Informational [Page 5]
INTERNET-DRAFT PEAP Version 0 25 October 2002 33 - EAP Extensions Data The Data field is of variable length, and contains Attribute-Value Pairs (AVPs). 2.3. AVP format Extensions AVPs are defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| AVP Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 0 - Non-mandatory AVP 1 - Mandatory AVP R Reserved, set to zero (0) AVP Type A 14-bit field, denoting the attribute type. Allocated AVP Types include: 0 - Reserved 1 - Reserved 2 - Reserved 3 - Acknowledged Result Length The length of the value field in octets. Value The value of the attribute. Kamath, Palekar & Wodrich Informational [Page 6]
INTERNET-DRAFT PEAP Version 0 25 October 2002 2.3.1. Result AVP The Result AVP provides support for acknowledged Success and Failure within EAP. It is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| AVP Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 1 - Mandatory AVP R Reserved, set to zero (0) AVP Type 3 - Result Length 2 Status The status field is two octets. Values include: 1 - Success 2 - Failure 3. Security considerations 3.1. Authentication and integrity protection The EAP Extension method is presumed to run before or after an EAP method that supports mutual authentication and establishes a protected channel. PEAP is such a method, and as a result the acknowledged Success and Failure messages are always protected. Note however, that [IEEE8021X] manufactures clear-text EAP Success and EAP Failure messages, so that even though the Result AVP will be protected, this will be followed by a clear-text EAP Success or EAP Kamath, Palekar & Wodrich Informational [Page 7]
INTERNET-DRAFT PEAP Version 0 25 October 2002 Failure packet. 3.2. Outcomes Within the Microsoft PEAP Version 0 implementation, support for the EAP Extensions method and the Result AVP is required. The only outcome which should be considered a successful authentication is when an EAP Request of Type=Extensions with Result AVP of Status=Success is answered by an EAP Response of Type=Extensions with Result AVP of Status=Success. All other combinations (Extensions Success, Extensions Failure), (Extensions Failure, Extensions Success), (Extensions Failure, Extensions Failure), (No extensions exchange) should be considered failed authentications, both by the EAP Peer and EAP Server. This is true regardless of whether an EAP Success or EAP Failure packet is subsequently sent, either in clear-text or within the PEAP tunnel. Because the EAP Extensions method is protected within the PEAP channel, its messages cannot be spoofed, whereas clear-text Success and Failure messages can be sent by an attacker. While the [PEAP] specification permits a tunneled EAP Success or Failure packet to be sent as the last message, this is not possible within the Windows XP SP1 implementation, which can only tunnel EAP packets of codes Request or Response within PEAP. Since the [IEEE8021X] specification requires that the switch or access point "manufacture" a clear-text EAP Success packet when an Access-Accept is received from the backend authentication server, and a clear-text EAP Failure packet when an Access-Reject is received. As a result, a tunneled EAP Success or Failure packet, if sent as the last message, would be thrown away by conformant [IEEE 8021X] implementations, and replaced with clear-text. This problem is being addressed within the IEEE 802.1aa revision to IEEE 802.1X, but the fix may take a while to move through the standards process and be implemented in commercial products. 4. Normative references [PEAP] Andersson, H., et al. "Protected EAP Protocol", Internet draft (work in progress), draft-josefsson-pppext-eap-tls- eap-02.txt, February 2002. [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. [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. Kamath, Palekar & Wodrich Informational [Page 8]
INTERNET-DRAFT PEAP Version 0 25 October 2002 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. 5. Informative references [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-1999, 1999. Kamath, Palekar & Wodrich Informational [Page 9]
INTERNET-DRAFT PEAP Version 0 25 October 2002 Appendix A - Examples In the case where an identity exchange occurs within PEAP Part 1, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=PEAP, V=0 (PEAP Start, S bit set) EAP-Response/ EAP-Type=PEAP, V=0 (TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) EAP-Response/ EAP-Type=PEAP, V=0 ([TLS certificate,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=PEAP -> TLS channel established (messages sent within the TLS channel) <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=X Kamath, Palekar & Wodrich Informational [Page 10]
INTERNET-DRAFT PEAP Version 0 25 October 2002 EAP-Response/ EAP-Type=X or NAK -> <- EAP-Request/ EAP-Type=X EAP-Response/ EAP-Type=X -> <- EAP-Request/ EAP-Type=Extensions Result=Success EAP-Response/ EAP-Type=Extensions Result=Success -> TLS channel torn down (messages sent in clear-text) <- EAP-Success In the case where the PEAP fragmentation is required, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=PEAP, V=0 (PEAP Start, S bit set) EAP-Response/ EAP-Type=PEAP, V=0 (TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) (Fragment 1: L, M bits set) EAP-Response/ EAP-Type=PEAP, V=0 -> <- EAP-Request/ EAP-Type=PEAP, V=0 (Fragment 2: M bit set) Kamath, Palekar & Wodrich Informational [Page 11]
INTERNET-DRAFT PEAP Version 0 25 October 2002 EAP-Response/ EAP-Type=PEAP, V=0 -> <- EAP-Request/ EAP-Type=PEAP, V=0 (Fragment 3) EAP-Response/ EAP-Type=PEAP, V=0 ([TLS certificate,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) (Fragment 1: L, M bits set)-> <- EAP-Request/ EAP-Type=PEAP, V=0 EAP-Response/ EAP-Type=PEAP, V=0 (Fragment 2)-> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=PEAP, V=0 -> TLS channel established (messages sent within the TLS channel) <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=X EAP-Response/ EAP-Type=X or NAK -> <- EAP-Request/ EAP-Type=X EAP-Response/ EAP-Type=X -> <- EAP-Request/ EAP-Type=Extensions Result=Success EAP-Response/ EAP-Type=Extensions Kamath, Palekar & Wodrich Informational [Page 12]
INTERNET-DRAFT PEAP Version 0 25 October 2002 Result=Success -> TLS channel torn down (messages sent in clear-text) <- EAP-Success In the case where the server authenticates to the client successfully in PEAP Part 1, but the client fails to authenticate to the server in PEAP Part 2, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=PEAP, V=0 (PEAP Start, S bit set) EAP-Response/ EAP-Type=PEAP, V=0 (TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) EAP-Response/ EAP-Type=PEAP, V=0 ([TLS certificate,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=PEAP, V=0 -> TLS channel established (messages sent within the TLS channel) Kamath, Palekar & Wodrich Informational [Page 13]
INTERNET-DRAFT PEAP Version 0 25 October 2002 <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=X EAP-Response/ EAP-Type=X or NAK -> <- EAP-Request/ EAP-Type=X EAP-Response/ EAP-Type=X -> <- EAP-Request/ EAP-Type=Extensions Result=Failure EAP-Response/ EAP-Type=Extensions Result=Failure -> (TLS session cache entry flushed) TLS channel torn down (messages sent in clear-text) <- EAP-Failure In the case where server authentication is unsuccessful in PEAP Part 1, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=PEAP, V=0 (PEAP Start) EAP-Response/ EAP-Type=PEAP, V=0 (TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS server_hello, TLS certificate, [TLS server_key_exchange,] TLS server_hello_done) EAP-Response/ Kamath, Palekar & Wodrich Informational [Page 14]
INTERNET-DRAFT PEAP Version 0 25 October 2002 EAP-Type=PEAP, V=0 (TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=PEAP, V=0 (TLS change_cipher_spec, TLS finished) <- EAP-Request/ EAP-Type=PEAP, V=0 EAP-Response/ EAP-Type=PEAP, V=0 (TLS Alert message) -> <- EAP-Failure (TLS session cache entry flushed) In the case where a previously established session is being resumed, the EAP server supports TLS session cache flushing for unsuccessful PEAP Part 2 authentications and both sides authenticate successfully, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=PEAP,V=0 (PEAP Start) EAP-Response/ EAP-Type=PEAP, V=0 (TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS server_hello, TLS change_cipher_spec TLS finished) EAP-Response/ EAP-Type=PEAP, V=0 (TLS change_cipher_spec, Kamath, Palekar & Wodrich Informational [Page 15]
INTERNET-DRAFT PEAP Version 0 25 October 2002 TLS finished) -> <- EAP-Request/ EAP-Type=Extensions Result=Success EAP-Response/ EAP-Type=Extensions Result=Success -> TLS channel torn down (messages sent in clear-text) <- EAP-Success In the case where a previously established session is being resumed, and the server authenticates to the client successfully but the client fails to authenticate to the server, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Request/ EAP-Type=PEAP, V=0 (TLS Start) EAP-Response/ EAP-Type=PEAP, V=0 (TLS client_hello) -> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS server_hello, TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=PEAP, V=0 (TLS change_cipher_spec, TLS finished) -> <- EAP-Request EAP-Type=PEAP, V=0 (TLS Alert message) EAP-Response EAP-Type=PEAP, V=0 -> <- EAP-Failure (TLS session cache entry flushed) In the case where a previously established session is being resumed, Kamath, Palekar & Wodrich Informational [Page 16]
INTERNET-DRAFT PEAP Version 0 25 October 2002 and the server authentication is unsuccessful, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Request/ EAP-Type=PEAP, V=0 (TLS Start) EAP-Response/ EAP-Type=PEAP, V=0 (TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS server_hello, TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=PEAP, V=0 (TLS change_cipher_spec, TLS finished) <- EAP-Request/ EAP-Type=PEAP, V=0 EAP-Response/ EAP-Type=PEAP, V=0 (TLS Alert message) -> (TLS session cache entry flushed) <- EAP-Failure In the case where the peer and authenticator have mismatched PEAP versions (e.g. the peer has a pre-standard implementation with version 0, and the authenticator has a Version 1 implementation, but the authentication is unsuccessful, the conversation will occur as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Request/ EAP-Type=PEAP, V=1 Kamath, Palekar & Wodrich Informational [Page 17]
INTERNET-DRAFT PEAP Version 0 25 October 2002 (TLS Start) EAP-Response/ EAP-Type=PEAP, V=0 (TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP, V=0 (TLS server_hello, TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=PEAP, V=0 (TLS change_cipher_spec, TLS finished) <- EAP-Request/ EAP-Type=PEAP, V=0 EAP-Response/ EAP-Type=PEAP, V=0 (TLS Alert message) -> (TLS session cache entry flushed) <- EAP-Failure Acknowledgments Thanks to Narendra Gidwani of Microsoft for useful discussions of this problem space. Author Addresses Vivek Kamath Ashwin Palekar Mark Wodrich Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 882 8080 EMail: {vivek, ashwinp, markwo}@microsoft.com 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- Kamath, Palekar & Wodrich Informational [Page 18]
INTERNET-DRAFT PEAP Version 0 25 October 2002 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 (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-kamath-pppext-peapv0-00.txt>, and expires April 23, 2002. Kamath, Palekar & Wodrich Informational [Page 19]