PPPEXT Working Group Vivek KamathINTERNET-DRAFT Ashwin PalekarCategory: Informational Mark Wodrich<draft-kamath-pppext-peapv0-00.txt> Microsoft25 October 2002Microsoft's PEAP version 0 (Implementation in Windows XP SP1)This document is an Internet-Draft and is in full conformance with allprovisions ofSection 10 of RFC 2026.Internet-Drafts are working documents of the Internet Engineering TaskForce (IETF), its areas, and its working groups. Note that other groupsmay also distribute working documents as Internet- Drafts.Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet-Drafts as reference materialor to cite them other than as "work in progress."The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txtThe list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.Copyright NoticeCopyright (C) The Internet Society (2002). All Rights Reserved.AbstractThis specification documents the implementation of PEAP supported inWindows XP SP1. This implementation utilizes a version number of zero(0) and supports acknowledged and protected success and failureindications, using the EAP Extensions method, Type 33.Kamath, Palekar & Wodrich Informational [Page 1]
INTERNET-DRAFT PEAP Version 0 25 October 2002Table of Contents1. Introduction ..........................................31.1 EAP encapsulation ...............................31.2 Version field ...................................31.3 EAP Extensions method ...........................42. Details of EAP extensions method ......................42.1 Extensions Request Packet .......................42.2 Extensions Response Packet ......................52.3 AVP format ......................................63. Security considerations .............................73.1 Authentication and integrity protection .........73.2 Outcomes ........................................74. Normative references ................................85. Informative references ..............................9Appendix A - Examples ........................................10Acknowledgments ..............................................18Author's Addresses ...........................................18Intellectual Property Statement ..............................18Full Copyright Statement .....................................19Kamath, Palekar & Wodrich Informational [Page 2]
INTERNET-DRAFT PEAP Version 0 25 October 20021. IntroductionMicrosoft's Windows XP SP1 implementation of PEAP version 0 differs inthe following ways from the protocol specified in [PEAP]. Version field EAP encapsulation Acknowledged and protected success and failure using EAP extensions methodPEAP protocol [PEAP] supports versioning and hence servers and clients cansupport 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 encapsulationThe [PEAP] specification requires that EAP packets be tunneled within aTLS channel in their entirety. However, the Windows XP SP1implementation of PEAP does not include an EAP header on packets sentwithin the TLS channel, except for EAP Extension packets (Type 33),where the complete header is sent. As a result, for EAP Types otherthan 33, the Code, Identifier, and Length fields are not sent, butrather EAP packets sent within the PEAP tunnel begin with the Typefield.While the Code, Identifier and Length fields are not sent over the wire,they are reconstructed at the receiver prior to EAP processing. Forexample, the Code and Identifier fields of the tunneled EAP packet areassumed to be the same as the equivalent fields within the outer EAPheader, and the Length field of the tunneled EAP packet is derived fromthe Length field of the PEAP packet. This has the followingimplications:[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 20021.2. Version Field[PEAP] is currently a work-in-progress. In order to allow for backwardcompatibility once the final specification of PEAP is completed, aversion 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 compatibilityonce the final specification of PEAP is complete. Version negotiationtakes place at the start of the conversation, with the authenticatorindicating its highest supported version. The peer then responds withthe highest version it supports. The conversation will then occur usingthe highest version supported by both parties. This behavior isillustrated in the last example inAppendix A.1.3. EAP extensions methodThe [PEAP] termination mechanism (sending an encrypted EAP Success orEAP Failure packet) does not function correctly with Authenticatorsimplementing [IEEE8021X]. Since IEEE 802.1X authenticators "manufacture"a clear-text EAP Success based on receipt of a RADIUS Access-Accept, ora clear-text EAP Failure based on receipt of a RADIUS Access-Reject,unless an acknowledged success/failure indication is used, the PEAPSupplicant may never receive a protected success/failure indication.This leaves the PEAP Supplicant open to attack. As a result, the WindowsXP SP1 PEAP implementation supports acknowledged and protectedsuccess/failure indications, using the EAP Extensions method (Type 33).2. Details of EAP extensions methodThe packet formats for the EAP Extensions method (type 33) follow.2.1. Extensions Request PacketA summary of the Extensions Request packet format is shown below. Thefields are transmitted from left to right.0 1 2 30 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 1Kamath, Palekar & Wodrich Informational [Page 4]
INTERNET-DRAFT PEAP Version 0 25 October 2002Identifier 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 ExtensionsData The Data field is of variable length, and contains Attribute-Value Pairs (AVPs).2.2. Extensions Response PacketA summary of the Extensions Response packet format is shown below. Thefields are transmitted from left to right.0 1 2 30 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 2Identifier 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.TypeKamath, Palekar & Wodrich Informational [Page 5]
INTERNET-DRAFT PEAP Version 0 25 October 2002 33 - EAP ExtensionsData The Data field is of variable length, and contains Attribute-Value Pairs (AVPs).2.3. AVP formatExtensions AVPs are defined as follows:0 1 2 30 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 AVPR 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 ResultLength 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 20022.3.1. Result AVPThe Result AVP provides support for acknowledged Success and Failurewithin EAP. It is defined as follows:0 1 2 30 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 AVPR Reserved, set to zero (0)AVP Type 3 - ResultLength 2Status The status field is two octets. Values include: 1 - Success 2 - Failure3. Security considerations3.1. Authentication and integrity protectionThe EAP Extension method is presumed to run before or after an EAPmethod that supports mutual authentication and establishes a protectedchannel. PEAP is such a method, and as a result the acknowledgedSuccess and Failure messages are always protected.Note however, that [IEEE8021X] manufactures clear-text EAP Success andEAP Failure messages, so that even though the Result AVP will beprotected, this will be followed by a clear-text EAP Success or EAPKamath, Palekar & Wodrich Informational [Page 7]
INTERNET-DRAFT PEAP Version 0 25 October 2002Failure packet.3.2. OutcomesWithin the Microsoft PEAP Version 0 implementation, support for the EAPExtensions method and the Result AVP is required. The only outcome whichshould be considered a successful authentication is when an EAP Requestof Type=Extensions with Result AVP of Status=Success is answered by anEAP Response of Type=Extensions with Result AVP of Status=Success. Allother combinations (Extensions Success, Extensions Failure), (ExtensionsFailure, 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 whetheran EAP Success or EAP Failure packet is subsequently sent, either inclear-text or within the PEAP tunnel. Because the EAP Extensions methodis protected within the PEAP channel, its messages cannot be spoofed,whereas clear-text Success and Failure messages can be sent by anattacker.While the [PEAP] specification permits a tunneled EAP Success or Failurepacket to be sent as the last message, this is not possible within theWindows XP SP1 implementation, which can only tunnel EAP packets ofcodes Request or Response within PEAP. Since the [IEEE8021X]specification requires that the switch or access point "manufacture" aclear-text EAP Success packet when an Access-Accept is received from thebackend authentication server, and a clear-text EAP Failure packet whenan Access-Reject is received. As a result, a tunneled EAP Success orFailure packet, if sent as the last message, would be thrown away byconformant [IEEE 8021X] implementations, and replaced with clear-text.This problem is being addressed within the IEEE 802.1aa revision to IEEE802.1X, but the fix may take a while to move through the standardsprocess 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 2002Appendix A - ExamplesIn the case where an identity exchange occurs withinPEAP Part 1, the conversation will appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-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/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Type=XKamath, Palekar & Wodrich Informational [Page 10]
INTERNET-DRAFT PEAP Version 0 25 October 2002EAP-Response/EAP-Type=X or NAK -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X -> <- EAP-Request/ EAP-Type=Extensions Result=SuccessEAP-Response/EAP-Type=ExtensionsResult=Success ->TLS channel torn down(messages sent in clear-text) <- EAP-SuccessIn the case where the PEAP fragmentation is required, the conversationwill appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-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 2002EAP-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=0EAP-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/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X or NAK -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X -> <- EAP-Request/ EAP-Type=Extensions Result=SuccessEAP-Response/EAP-Type=ExtensionsKamath, Palekar & Wodrich Informational [Page 12]
INTERNET-DRAFT PEAP Version 0 25 October 2002Result=Success ->TLS channel torn down(messages sent in clear-text) <- EAP-SuccessIn the case where the server authenticates to the clientsuccessfully in PEAP Part 1, but the client fails to authenticateto the server in PEAP Part 2, the conversation will appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-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/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X or NAK -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X -> <- EAP-Request/ EAP-Type=Extensions Result=FailureEAP-Response/EAP-Type=ExtensionsResult=Failure ->(TLS session cache entry flushed)TLS channel torn down(messages sent in clear-text) <- EAP-FailureIn the case where server authentication is unsuccessful in PEAP Part 1,the conversation will appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-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 2002EAP-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=0EAP-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 cacheflushing for unsuccessful PEAP Part 2 authentications and both sidesauthenticate successfully, the conversationwill appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-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=SuccessEAP-Response/EAP-Type=ExtensionsResult=Success ->TLS channel torn down(messages sent in clear-text) <- EAP-SuccessIn the case where a previously established session is being resumed, and theserver authenticates to the client successfullybut the client fails to authenticate to the server, the conversationwill appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-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-ResponseEAP-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 2002and the server authentication is unsuccessful,the conversation will appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-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=0EAP-Response/EAP-Type=PEAP, V=0(TLS Alert message) ->(TLS session cache entry flushed) <- EAP-FailureIn the case where the peer and authenticator have mismatched PEAP versions(e.g. the peer has a pre-standard implementationwith 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/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Request/ EAP-Type=PEAP, V=1Kamath, 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=0EAP-Response/EAP-Type=PEAP, V=0(TLS Alert message) ->(TLS session cache entry flushed) <- EAP-FailureAcknowledgmentsThanks to Narendra Gidwani of Microsoft for useful discussions of thisproblem space.Author AddressesVivek KamathAshwin PalekarMark WodrichMicrosoft CorporationOne Microsoft WayRedmond, WA 98052Phone: +1 425 882 8080EMail: {vivek, ashwinp, markwo}@microsoft.comIntellectual Property StatementThe IETF takes no position regarding the validity or scope of anyintellectual property or other rights that might be claimed to pertainto the implementation or use of the technology described in thisdocument or the extent to which any license under such rights might ormight not be available; neither does it represent that it has made anyeffort to identify any such rights. Information on the IETF'sprocedures with respect to rights in standards-track and standards-Kamath, Palekar & Wodrich Informational [Page 18]
INTERNET-DRAFT PEAP Version 0 25 October 2002related documentation can be found inBCP-11. Copies of claims ofrights made available for publication and any assurances of licenses tobe made available, or the result of an attempt made to obtain a generallicense or permission for the use of such proprietary rights byimplementors or users of this specification can be obtained from theIETF Secretariat.The IETF invites any interested Party to bring to its attention anycopyrights, patents or patent applications, or other proprietary rightswhich may cover technology that may be required to practice thisstandard. Please address the information to the IETF ExecutiveDirector.Full Copyright StatementCopyright (C) The Internet Society (2002). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it orassist in its implementation may be prepared, copied, published anddistributed, in whole or in Part, without restriction of any kind,provided that the above copyright notice and this paragraph are includedon all such copies and derivative works. However, this document itselfmay not be modified in any way, such as by removing the copyright noticeor references to the Internet Society or other Internet organizations,except as needed for the purpose of developing Internet standards inwhich case the procedures for copyrights defined in the InternetStandards process must be followed, or as required to translate it intolanguages other than English. The limited permissions granted above areperpetual and will not be revoked by the Internet Society or itssuccessors or assigns. This document and the information containedherein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THEINTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THEINFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."Expiration DateThis memo is filed as <draft-kamath-pppext-peapv0-00.txt>, and expiresApril 23, 2002.Kamath, Palekar & Wodrich Informational [Page 19]
draft-kamath-pppext-peapv0-00
Expired Internet-Draft (individual)
| Document | Document type | Expired Internet-Draft (individual) Expired & archived This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process. | |
|---|---|---|---|
| Select version | |||
| Authors | Vivek Kamath,Ashwin Palekar,Mark Wodrich Email authors | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Other formats |