idnits 2.17.1 draft-ietf-eap-otp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2284, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 73 has weird spacing: '...ication mecha...' == Line 564 has weird spacing: '...>, and expir...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Type-Data field contains the OTP "challenge" as a displayable message in the Request. In the Response, this field is used for the 6 words from the OTP dictionary [RFC1938]. The messages MUST not be null terminated. The length of the field is derived from the Length field of the Request/Reply packet. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Type-Data field in the Request contains a displayable message greater than zero octets in length. The length of the message is determined by Length field of the Request packet. The message MUST not be null terminated. A Response MUST be sent in reply to the Request with a Type field of 6 (Generic Token Card). The Response contains data from the Token Card required for authentication. The length is of the data is determined by the Length field of the Response packet. (Using the creation date from RFC2284, updated by this document, for RFC5378 checks: 1995-03-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 311 -- Looks like a reference, but probably isn't: '2' on line 314 -- Looks like a reference, but probably isn't: '3' on line 316 -- Looks like a reference, but probably isn't: '4' on line 346 -- Looks like a reference, but probably isn't: '5' on line 322 -- Looks like a reference, but probably isn't: '6' on line 325 -- Looks like a reference, but probably isn't: '7' on line 329 -- Looks like a reference, but probably isn't: '8' on line 331 -- Looks like a reference, but probably isn't: '9' on line 334 ** Obsolete normative reference: RFC 1938 (Obsoleted by RFC 2289) ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group L. Blunk 3 INTERNET-DRAFT Merit Networks, Inc. 4 Category: Standards Track J. Vollbrecht 5 Interlink Networks, Inc. 6 12 October 2002 Bernard Aboba 7 Updates: RFC 2284 Microsoft 9 The One Time Password (OTP) and Generic Token Card Authentication Protocols 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet- Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2002). All Rights Reserved. 33 Abstract 35 EAP is an authentication protocol which supports multiple authentication 36 mechanisms. EAP typically runs directly over the link layer without 37 requiring IP and therefore includes its own support for in-order 38 delivery and re-transmission. While EAP was originally developed for use 39 with PPP, it is also now in use with IEEE 802. This document defines the 40 One Time Password (OTP) and Generic Token Card EAP methods, both of 41 which provide one-way authentication, but not key generation. As a 42 result, the OTP and Generic Token Card methods, when used by themselves, 43 are only appropriate for use on networks where physical security can be 44 assumed. These methods SHOULD NOT be used on wireless networks, or over 45 the Internet, unless the EAP conversation is protected. This can be 46 accomplished using technologies such as IPsec or TLS. 48 Table of Contents 50 1. Introduction .......................................... 3 51 1.1 Specification of Requirements ................... 3 52 1.2 Terminology ..................................... 3 53 2. Packet Format ......................................... 4 54 2.1 EAP Request Packet .............................. 5 55 2.2 EAP Response Packet ............................. 6 56 2.3 One-Time Password ............................... 6 57 2.4 Generic Token Card .............................. 7 58 3. Security considerations ............................... 8 59 3.1 Threat model .......................................... 8 60 3.2 Security claims ....................................... 9 61 3.3 Packet modification attacks ........................... 9 62 3.4 Mutual authentication ................................. 10 63 3.5 Confidentiality ...................................... 10 64 4. Normative references .................................. 11 65 5. Informative references ................................ 11 66 ACKNOWLEDGMENTS .............................................. 12 67 AUTHORS' ADDRESSES ........................................... 12 68 Intellectual property statement .............................. 13 69 Full Copyright Statement ..................................... 13 70 1. Introduction 72 EAP, defined in [RFC2284], is an authentication protocol which supports 73 multiple authentication mechanisms. EAP typically runs directly over 74 the link layer without requiring IP and therefore includes its own 75 support for in-order delivery and re-transmission. While EAP was 76 originally developed for use with PPP [RFC1661], it is also now in use 77 with IEEE 802 [IEEE802]. The encapsulation of EAP on IEEE 802 link 78 layers is defined in [IEEE8021X]. This document defines the One Time 79 Password (OTP) and Generic Token Card EAP methods. 81 1.1. Specification of Requirements 83 In this document, several words are used to signify the requirements of 84 the specification. These words are often capitalized. The key words 85 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 86 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 87 interpreted as described in [RFC2119]. 89 1.2. Terminology 91 This document frequently uses the following terms: 93 Authenticator 94 The end of the link requiring the authentication. 96 Peer The other end of the point-to-point link (PPP), point-to-point 97 LAN segment (IEEE 802.1X) or 802.11 wireless link, which being 98 authenticated by the Authenticator. In IEEE 802.1X, this end 99 is known as the Supplicant. 101 Authentication Server 102 An Authentication Server is an entity that provides an 103 Authentication Service to an Authenticator. This service 104 verifies from the credentials provided by the peer, the claim 105 of identity made by the peer. 107 Port Access Entity (PAE) 108 The protocol entity associated with a physical or virtual 109 (802.11) Port. A given PAE may support the protocol 110 functionality associated with the Authenticator, peer or both. 112 Silently Discard 113 This means the implementation discards the packet without 114 further processing. The implementation SHOULD provide the 115 capability of logging the error, including the contents of the 116 silently discarded packet, and SHOULD record the event in a 117 statistics counter. 119 Displayable Message 120 This is interpreted to be a human readable string of 121 characters, and MUST NOT affect operation of the protocol. 122 The message encoding MUST follow the UTF-8 transformation 123 format [RFC2044]. 125 2. Packet Format 127 A summary of the EAP OTP and Generic Token Card Request/Response packet 128 format is shown below. The fields are transmitted from left to right. 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Code | Identifier | Length | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Type | Data... 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Code 140 1 - Request 141 2 - Response 143 Identifier 145 The identifier field is one octet and aids in matching responses with 146 requests. 148 Length 150 The Length field is two octets and indicates the length of the EAP 151 packet including the Code, Identifier, Length, Type, and Data fields. 152 Octets outside the range of the Length field should be treated as 153 Data Link Layer padding and should be ignored on reception. 155 Type 157 5 - OTP 6 - Generic Token Card 159 Data 161 The format of the Data field is determined by the Code field. 163 2.1. EAP Request Packet 165 A summary of the EAP Request packet format is shown below. The fields 166 are transmitted from left to right. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Code | Identifier | Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Type | Type-Data... 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Code 178 1 180 Identifier 182 The Identifier field is one octet and aids in matching responses with 183 requests. The Identifier field MUST be changed on each Request 184 packet. 186 Length 188 The Length field is two octets and indicates the length of the EAP 189 packet including the Code, Identifier, Length, Type, and Type-Data 190 fields. 192 Type 194 5 - OTP 6 - Generic Token Card 196 Type-Data 198 The format of the Type-Data field is determined by the Code and Type 199 fields. 201 2.2. EAP Response Packet 203 A summary of the EAP OTP And Generic Token Card Response packet format 204 is shown below. The fields are transmitted from left to right. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Code | Identifier | Length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Type-Data... 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Code 216 2 218 Identifier 220 The Identifier field is one octet and MUST match the Identifier field 221 from the corresponding request. 223 Length 225 The Length field is two octets and indicates the length of the EAP 226 packet including the Code, Identifier, Length, Type, and Type-Data 227 fields. 229 Type 231 5 - OTP 6 - Generic Token Card 233 Type-Data 235 The format of the Type-Data field is determined by the Code and Type 236 fields. 238 2.3. One-Time Password (OTP) 240 Description 242 The One-Time Password system is defined in "A One-Time Password 243 System" [RFC1938]. The Request contains a displayable message 244 containing an OTP challenge. A Response MUST be sent in reply to the 245 Request. The Response MUST be of Type 5 (OTP) or Type 3 (Nak). The 246 Nak reply indicates the peer's desired authentication mechanism 247 Type(s). 249 Type 251 5 253 Type-Data 255 The Type-Data field contains the OTP "challenge" as a displayable 256 message in the Request. In the Response, this field is used for the 257 6 words from the OTP dictionary [RFC1938]. The messages MUST not be 258 null terminated. The length of the field is derived from the Length 259 field of the Request/Reply packet. 261 2.4. Generic Token Card 263 Description 265 The Generic Token Card Type is defined for use with various Token 266 Card implementations which require user input. The Request contains 267 a displayable message and the Reply contains the Token Card 268 information necessary for authentication. Typically, this would be 269 information read by a user from the Token card device and entered as 270 ASCII text. 272 Type 274 6 276 Type-Data 278 The Type-Data field in the Request contains a displayable message 279 greater than zero octets in length. The length of the message is 280 determined by Length field of the Request packet. The message MUST 281 not be null terminated. A Response MUST be sent in reply to the 282 Request with a Type field of 6 (Generic Token Card). The Response 283 contains data from the Token Card required for authentication. The 284 length is of the data is determined by the Length field of the 285 Response packet. 287 3. Security Considerations 289 EAP was designed for use with dialup PPP [RFC1661] and wired local area 290 networks [IEEE802]. On these networks, an attacker would need to gain 291 physical access to the telephone or switch infrastructure in order to 292 mount an attack. While such attacks have been documented, such as in 293 [DECEPTION], they are assumed to be rare. 295 However, subsequently EAP has been proposed for use on wireless 296 networks, and over the Internet, where physical security cannot be 297 assumed. On such networks, the security vulnerabilities are greater, as 298 are the requirements for EAP security. 300 This section documents the threats that exist on physically insecure 301 networks carrying EAP, as well as laying out the consequences of the use 302 of the OTP and Generic Token Card methods on those networks. We then 303 discuss mechanisms by which the threats may be mitigated. 305 3.1. Threat model 307 On physically insecure networks, it is possible for an attacker to gain 308 access to the physical medium. This enables a range of attacks, 309 including the following: 311 [1] An adversary may try to discover user identities by snooping data 312 packets. 314 [2] An adversary may try to modify or spoof EAP packets. 316 [3] An adversary may launch denial of service attacks by terminating 317 EAP conversations. 319 [4] An adversary may attempt to recover the pass-phrase by mounting an 320 off-line dictionary attack. 322 [5] An adversary may attempt to convince the Peer to connect to an 323 untrusted network. 325 [6] An adversary may attempt to disrupt the EAP negotiation in order to 326 weaken the authentication, gain access to user passwords or remove 327 confidentiality protection. 329 [7] An adversary may attempt to mount a denial of service attack. 331 [8] An attacker may attempt to take advantage of weak key derivation 332 techniques used within EAP methods. 334 [9] An attacker may attempt to take advantage of weak ciphersuites 335 subsequently used after EAP authentication has concluded. 337 Where EAP is used over wireless networks, an attacker needs to be within 338 the coverage area of the wireless medium in order to carry out these 339 attacks. However, where EAP is used over the Internet, no such 340 restrictions apply. 342 3.2. Security claims 344 Of the threats described in the previous section, the OTP and Generic 345 Token Card method only provide protection against dictionary attack 346 (threat [4]). Since the purpose of the OTP and Generic Token Card 347 methods is to authenticate "something the user has", neither method 348 requires a password, and so neither method is vulnerable to dictionary 349 attack. Identity protection is not provided, nor is authentication and 350 integrity protection of EAP packets. The OTP and Generic Token card 351 methods provide one-way authentication only, and therefore do not 352 prevent the peer from connecting to an untrusted network, although 353 another method could conceivably be run in the opposite direction. No 354 protection is provided against "bidding down" attacks, although EAP 355 peers and authenticators may implement policy to limit the likelihood of 356 such an attack. No keys are derived by the OTP and Generic Token Card 357 methods, and so it is not possible to use these methods in order to 358 provide keying material for a subsequent ciphersuite. Neither the OTP 359 nor the Generic Token Card method provide for protected ciphersuite 360 negotiation. 362 As a result, the OTP and Generic Token Card methods, when used by 363 themselves, are only appropriate for use on networks where physical 364 security can be assumed. These methods SHOULD NOT be used on wireless 365 networks, or over the Internet, unless the EAP conversation is 366 protected. This can be accomplished using technologies such as IPsec 367 [RFC2401] or TLS [RFC2246]. 369 The following security issues are discussed in more depth in the 370 sections that follow: 372 Identity protection 373 Packet modification attacks 374 Mutual authentication 375 Confidentiality 377 3.3. Identity protection 379 Both the OTP and Generic Token Card methods assume that an Identity 380 exchange has taken place prior to invoking the method, so that 381 parameters unique to the user's claimed identity can be retrieved by the 382 authenticator and used in the authentication. Since EAP Identity 383 Request and Response methods are sent in the clear, an attacker may 384 obtain the user identity. 386 3.4. Packet modification attacks 388 Neither the Generic Token Card nor the OTP method provide for 389 authentication and integrity protection of material sent within the data 390 portion of an EAP message. EAP also does not provide built-in support 391 for authentication or integrity protection. This means that an attacker 392 may modify all or portions of EAP messages, including Request and 393 Response messages of types Identity, Notification, Nak, OTP, and Generic 394 Token Card as well as Success and Failure messages. Therefore the 395 Generic Token card and OTP methods assume that physical access to the 396 link is restricted, so that such attacks are unlikely. 398 However, where EAP is run over wireless networks or over IP, such as 399 within protocols supporting PPP or Ethernet tunneling [RFC2661], 400 physical security can no longer be assumed. In this case, the Generic 401 Token card and OTP methods SHOULD be authenticated and integrity 402 protected by alternate means. This can be achieved, for example, by 403 encapsulating the EAP exchange within protocols such as IPsec [RFC2401] 404 or TLS [RFC2246]. 406 3.5. Mutual authentication 408 In EAP there is no requirement that authentication be full duplex or 409 that the same protocol be used in both directions. It is perfectly 410 acceptable for different protocols to be used in each direction. This 411 will, of course, depend on the specific protocols negotiated. 413 The OTP and Generic Token Card methods only provide for one-way 414 authentication; that is, they authenticate the EAP peer to the 415 authenticator. Therefore the authenticator's identity remains 416 unverified. 418 Where physical security can be assumed, such one-way authentication may 419 be acceptable; however, for wireless media such as 802.11 [IEEE80211] or 420 for EAP use over IP, where physical security can no longer be assumed, 421 mutual authentication is necessary to guard against rogue 422 authenticators. As a result, in these situations, the OTP and Generic 423 Token Card methods cannot by themselves provide adequate security. 425 3.6. Confidentiality 427 Neither the OTP nor the Generic Token card methods derive session keys 428 for use with per-packet authentication, integrity protection or 429 confidentiality. Typically, this means that subsequent data traffic 430 will either utilize static session keys, or will be unprotected. Where 431 EAP is run over wireless networks, such as 802.11 [IEEE80211], there may 432 be an expectation that keys for link layer ciphersuites will be provided 433 by the EAP method. This implies that the OTP and Generic Token Card 434 methods will not be acceptable for use in such situations, since if they 435 are used, then data traffic will be vulnerable to a wide variety of 436 attacks, including traffic insertion, snooping and session hijacking. 438 4. Normative References 440 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 441 RFC 1661, July 1994. 443 [RFC1938] Haller, N. and C. Metz, "A One-Time Password System", RFC 444 1938, May 1996. 446 [RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode 447 and ISO 10646", RFC 2044, October 1996. 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", RFC 2119, March 1997. 452 [RFC2284] Blunk, L., Vollbrecht, J., "Extensible Authentication 453 Protocol (EAP)", RFC 2284, March 1998. 455 5. Informative References 457 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, 458 January 1999. 460 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the 461 Internet Protocol", RFC 2401, November 1998. 463 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 464 G., and Palter, B., "Layer Two Tunneling Protocol L2TP", 465 RFC 2661, August 1999. 467 [DECEPTION] Slatalla, M., and Quittner, J., "Masters of Deception," 468 HarperCollins, New York, 1995. 470 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 471 Overview and Architecture, ANSI/IEEE Std 802, 1990. 473 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 474 Port based Network Access Control, IEEE Std 802.1X-2001, 475 June 2001. 477 [IEEE80211] Information technology - Telecommunications and 478 information exchange between systems - Local and 479 metropolitan area networks - Specific Requirements Part 480 11: Wireless LAN Medium Access Control (MAC) and 481 Physical Layer (PHY) Specifications, IEEE Std. 482 802.11-1999, 1999. 484 Acknowledgments 486 Al Rubens (Merit) also provided valuable feedback on this document, as 487 did Glen Zorn (Cisco) and Ashwin Palekar (Microsoft). 489 Authors' Addresses 491 Larry J. Blunk 492 Merit Network, Inc. 493 4251 Plymouth Rd., Suite C 494 Ann Arbor, MI 48105 496 EMail: ljb@merit.edu 497 Phone: 734-763-6056 498 FAX: 734-647-3185 500 John R. Vollbrecht 501 Interlink Networks, Inc. 502 775 Technology Drive, Suite 200 503 Ann Arbor, MI 48108 504 USA 506 Phone: +1 734 821 1205 507 Fax: +1 734 821 1235 508 EMail: jrv@interlinknetworks.com 510 Bernard Aboba 511 Microsoft Corporation 512 One Microsoft Way 513 Redmond, WA 98052 515 EMail: bernarda@microsoft.com 516 Phone: +1 425 706 6605 517 Fax: +1 425 936 7329 518 Intellectual Property Statement 520 The IETF takes no position regarding the validity or scope of any 521 intellectual property or other rights that might be claimed to pertain 522 to the implementation or use of the technology described in this 523 document or the extent to which any license under such rights might or 524 might not be available; neither does it represent that it has made any 525 effort to identify any such rights. Information on the IETF's 526 procedures with respect to rights in standards-track and standards- 527 related documentation can be found in BCP-11. Copies of claims of 528 rights made available for publication and any assurances of licenses to 529 be made available, or the result of an attempt made to obtain a general 530 license or permission for the use of such proprietary rights by 531 implementers or users of this specification can be obtained from the 532 IETF Secretariat. 534 The IETF invites any interested party to bring to its attention any 535 copyrights, patents or patent applications, or other proprietary rights 536 which may cover technology that may be required to practice this 537 standard. Please address the information to the IETF Executive 538 Director. 540 Full Copyright Statement 542 Copyright (C) The Internet Society (2002). All Rights Reserved. 543 This document and translations of it may be copied and furnished to 544 others, and derivative works that comment on or otherwise explain it or 545 assist in its implementation may be prepared, copied, published and 546 distributed, in whole or in part, without restriction of any kind, 547 provided that the above copyright notice and this paragraph are included 548 on all such copies and derivative works. However, this document itself 549 may not be modified in any way, such as by removing the copyright notice 550 or references to the Internet Society or other Internet organizations, 551 except as needed for the purpose of developing Internet standards in 552 which case the procedures for copyrights defined in the Internet 553 Standards process must be followed, or as required to translate it into 554 languages other than English. The limited permissions granted above are 555 perpetual and will not be revoked by the Internet Society or its 556 successors or assigns. This document and the information contained 557 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 558 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 559 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 560 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 562 Expiration Date 564 This memo is filed as , and expires April 565 19, 2003.