idnits 2.17.1 draft-dpotter-pppext-eap-mschap-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (January 2002) is 8135 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2716 (ref. '2') (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 2284 (ref. '3') (Obsoleted by RFC 3748) == Outdated reference: A later version (-05) exists of draft-ietf-pppext-mppe-04 Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Potter 3 INTERNET-DRAFT J. Zamick 4 Category: Informational Cisco Systems 5 January 2002 7 PPP EAP MS-CHAP-V2 Authentication Protocol 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 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 made obsolete by other documents at 20 any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as work in progress. 23 The list of current Internet-Drafts may be found at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories may be found at 27 http://www.ietf.org/shadow.html. 29 1. Abstract 31 This document specifies an Extensible Authentication Protocol (EAP) 32 mechanism for authentication using the Microsoft Challenge-Handshake 33 Authentication Protocol (Version 2). 35 MS-CHAP-v2 provides authentication functionality consistent 36 with LAN-based methods including password change sequences. Mutual 37 authentication is provided for by the inclusion of an authenticator 38 packet returned to the client after a successful server 39 authentication. 41 2. Introduction 43 Prior to EAP [3] network access support for a specific authentication 44 protocol had to be engineered in at least three places, the peer, 45 the access device (AAA client) and the AAA server. EAP has 46 significantly simplified this scheme by making the password protocol 47 'opaque' to the access device - support for EAP by an access device 48 therefore infers support for all EAP types. The 802.1x protocol which 49 facilitates the deployment of user AAA on broadcast media networks 50 such as wireless and Ethernet relies upon EAP as its password 51 protocol vehicle as there is no point-to-point protocol negotiation 52 as with conventional dial-in or VPN clients. 54 EAP prescribes mandatory support for EAP-MD5-CHAP and whilst this 55 has been used widely in the past, the implementational requirement 56 for the back-end server to hold the users password either in clear 57 text or a reversible encryption is seen as a potential drawback. 59 EAP-TLS [2] is likely to achieve widespread adoption in the future, 60 however there are currently issues over the cost and ease of 61 deployment into existing network infrastructure. 63 Another very widely used authentication protocol that is not 64 currently addressed by EAP is MS-CHAP [6]. The lack of support for 65 MS-CHAP in EAP significantly reduces the utility of EAP since MS-CHAP 66 provides an additional facility for password change and expiry 67 notification (aging). 69 This document describes a method for encapsulating MS-CHAP v2 in EAP 70 and extends MS-CHAP by allowing the peer to request a password change 71 after a successful authentication. 73 2.1. Requirements language 75 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 76 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 77 described in [4]. 79 2.2 Definitions 81 AAA Server 82 Authentication, Authorisation and Accounting Server 84 Authenticator 85 Access device to which client desires connection 87 EAP 88 Extensible Authentication Protocol [3] 90 EAP Server 91 For the purpose of this document, see AAA Server 93 Peer/Client 94 Device (software or hardware) requiring access to/via the 95 Authenticator. 97 3. Protocol overview 99 3.1. Overview of the EAP-MS-CHAP-V2 Authentication 101 As described in [3], the EAP-MS-CHAP-V2 conversation will typically 102 begin with the authenticator and the peer negotiating EAP. The 103 authenticator will then typically send an EAP-Request/Identity 104 packet to the peer, and the peer will respond with an 105 EAP-Response/Identity packet to the authenticator, containing the 106 clients userId. 108 Unless otherwise stated, all EAP challenge/response messages MUST 109 have an EAP-Type of EAP-MS-CHAP-V2. EAP Success and Failure messages 110 have the EAP Message Code set to one of these values respectively. 112 Upon receipt of the users identity the EAP Server MUST respond with 113 a EAP-MS-CHAP-V2 Challenge request. The MS-CHAP Challenge as defined 114 in [6] should be cryptographically random. The EAP Server remembers 115 the challenge for later authentication of the computed MS-CHAP 116 Response. 118 The EAP Client MUST then reply with the MS-CHAP Response generated 119 from the users credentials. The EAP Server re-computes the MS-CHAP 120 Response, or devolves this operation to another back-end server. The 121 EAP Server MUST then send an EAP Request with either MS-CHAP Success 122 or MS-CHAP Failure packets depending on the result of the 123 authentication. 125 The EAP Server SHOULD ensure the MS-CHAP Response is actually a 126 version 2 formatted response and not version 1. In the version 2 127 packet the first 16 octets of the response contain a random challenge 128 from the the client. The next 8 octets MUST be zero, otherwise the 129 EAP Server SHOULD immediately send an EAP Failure message. 131 3.1.1 Successful Authentication 133 If the MS-CHAP Response was valid the EAP Server MAY send the 134 MS-CHAP Success packet, however it may apply other local policy 135 conditions resulting in a rejection (see 3.1.2) 137 To provide mutual authentication the MS-CHAP Success packet MUST be 138 validated by the client as per 3.1.5. If the MS-CHAP Success packet 139 is valid the client MUST send an EAP Response containing an Ack 140 packet. 142 The EAP server MUST then send an EAP-Success message to the 143 client/peer. The EAP authentication is now complete. 145 3.1.2 Failed Authentication (or Authorisation) 147 If the MS-CHAP Response was invalid the EAP Server MUST send the 148 MS-CHAP Failure packet indicating the rejection (MS-CHAP error code 149 691 - ERROR_AUTHENTICATION_FAILURE) 151 If the MS-CHAP Response was actually valid but the user has failed 152 some other authorisation policy then the EAP Server MAY indicate one 153 of other MS-CHAP failure codes: 155 646 ERROR_RESTRICTED_LOGON_HOURS 156 647 ERROR_ACCT_DISABLED 157 649 ERROR_NO_DIALIN_PERMISSION 159 Upon receipt of the MS-CHAP Failure packet the client MUST send an 160 EAP Response containing the MS-CHAP Ack packet. After receiving an 161 MS-CHAP Ack to the MS-CHAP Failure packet, the EAP server MUST then 162 send an EAP-Failure message to the client/peer. 164 The EAP authentication is now complete. 166 3.1.3 Password Expired 168 If the users password has expired, the EAP Server MAY send an MS-CHAP 169 Failure packet indicating that the users password has expired 170 (MS-CHAP error code 648 - ERROR_PASSWD_EXPIRED). If the EAP Server 171 does not support password change then it MUST send a failed 172 authentication result instead (MS-CHAP error code 691 - 173 ERROR_AUTHENTICATION_FAILURE). 175 On receipt of the MS-CHAP Failure packet indicating that a password 176 change is required, the client MUST send an EAP Response containing 177 the MS-CHAP Ack packet. 179 The EAP Server MUST then generate a new random challenge and issue 180 an EAP Request containing an MS-CHAP Challenge packet. 182 The client will then obtain a new password (in most cases directly 183 from the user) and use the algorithms described in [6] to create a 184 MS-CHAP Change Password packet. This is then sent in an 185 EAP-Response message. 187 The EAP Server will then process the MS-CHAP Change Password packet 188 and MUST issue an MS-CHAP Success or Failure packet. If the password 189 change was unsuccessful, the MS-CHAP Failure packet MUST indicate 190 this using MS-CHAP error code 709 (ERROR_CHANGING_PASSWORD). The EAP 191 Server MAY start a new password change sequence by formatting the 192 MS-CHAP Failure packet to indicate password expiry (MS-CHAP error 193 code 648 - ERROR_PASSWD_EXPIRED). 195 In response to the MS-CHAP Success or MS-CHAP Failure packets, the 196 client MUST send an EAP Response containing the MS-CHAP Ack packet. 197 Additionally, an MS-CHAP Success packet must be validated as 198 per 3.1.5. 200 If the password change sequence was successful, the EAP Server MUST 201 then send an EAP-Success message. If the password change sequence was 202 unsuccessful the EAP Server MUST send an EAP-Failure message. If the 203 EAP Server had decided to start a new password change sequence then 204 it MUST generate a new random challenge and issue an EAP Request 205 containing an MS-CHAP Challenge packet. 207 3.1.4 Successful Authentication - Client Wishes to Change Password 209 Upon receipt of the MS-CHAP Success packet (following a valid MS-CHAP 210 authentication and validation of the Success packet as per 3.1.5) the 211 client MAY optionally request that the users password is changed. In 212 response to the MS-CHAP Success packet the client MAY send an EAP 213 Response containing an MS-CHAP Failure packet indicating a password 214 change is required (MS-CHAP error code 648 - ERROR_PASSWD_EXPIRED). 216 The EAP Server MAY choose to honour the request, in which case it 217 starts a password change sequence by creating a random challenge and 218 sending an EAP Request with a MS-CHAP Challenge packet as per 3.1.3. 219 This ultimately ends with the EAP Server sending an EAP-Success or 220 EAP-Failure message depending on the result of the password change 221 sequence. 223 If the EAP Server does not support client requested password changes 224 it MUST respond with an MS-CHAP Failure packet indicating the 225 password change request has not been allowed (MS-CHAP error code 226 709 - ERROR_CHANGING_PASSWORD). The Client MUST then respond with an 227 Ack packet. Finally the EAP Server SHOULD send an EAP-Success 228 message. 230 3.1.5 Mutual Authentication 232 As described in [6] the MS-CHAP Success packet MUST be validated by 233 the client in accordance with the algorithms described therein. If 234 the Success packet is invalid the client MUST end the session. 236 3.2. Fragmentation 238 The maximum size of an EAP-MSCHAP-V2 record will be 586 bytes (during 239 a password change conversation [6]) and therefore does not require a 240 specific fragmentation scheme other than what is provided for in [8] 242 3.3. Session Encryption/Compression 244 PPP [1] encryption and compression are catered for using MPPE-based 245 methods [5,7,9]. In general terms the AAA/EAP server will generate an 246 MPPE session key during the MSCHAP-v2 authentication process [7]. The 247 MPPE key information is then returned to the Authenticator [5]. 249 3.4. Examples 251 In the case where the EAP-MS-CHAP-V2 authentication is successful, 252 the conversation will appear as follows: 254 Authenticating Peer Authenticator 255 ------------------- ------------- 256 <- PPP EAP-Request/ 257 Identity 258 PPP EAP-Response/ 259 Identity (MyID) -> 260 <- PPP EAP-Request/ 261 EAP-Type=EAP-MS-CHAP-V2 262 (Challenge) 263 PPP EAP-Response/ 264 EAP-Type=EAP-MS-CHAP-V2 265 (Response)-> 266 <- PPP EAP-Request/ 267 EAP-Type=EAP-MS-CHAP-V2 268 (Success) 270 PPP EAP-Response/ 271 EAP-Type=EAP-MS-CHAP-V2 272 (Ack) -> 274 <- PPP EAP-Success 276 In the case where the EAP-MS-CHAP-V2 authentication not successful, 277 the conversation will appear as follows: 279 Authenticating Peer Authenticator 280 ------------------- ------------- 281 <- PPP EAP-Request/ 282 Identity 283 PPP EAP-Response/ 284 Identity (MyID) -> 285 <- PPP EAP-Request/ 286 EAP-Type=EAP-MS-CHAP-V2 287 (Challenge) 289 PPP EAP-Response/ 290 EAP-Type=EAP-MS-CHAP-V2 291 (Response)-> 292 <- PPP EAP-Request/ 293 EAP-Type=EAP-MS-CHAP-V2 294 (Failure = failed) 296 PPP EAP-Response/ 297 EAP-Type=EAP-MS-CHAP-V2 298 (Ack) -> 300 <- PPP EAP-Failure 302 In the case where the users password has expired, the conversation 303 will appear as follows: 305 Authenticating Peer Authenticator 306 ------------------- ------------- 307 <- PPP EAP-Request/ 308 Identity 309 PPP EAP-Response/ 310 Identity (MyID) -> 311 <- PPP EAP-Request/ 312 EAP-Type=EAP-MS-CHAP-V2 313 (Challenge) 314 PPP EAP-Response/ 315 EAP-Type=EAP-MS-CHAP-V2 316 (Response)-> 318 <- PPP EAP-Request/ 319 EAP-Type=EAP-MS-CHAP-V2 320 (Failure = password expired) 322 PPP EAP-Response/ 323 EAP-Type=EAP-MS-CHAP-V2 324 (Ack) -> 325 <- PPP EAP-Request/ 326 EAP-Type=EAP-MS-CHAP-V2 327 (Challenge) 329 PPP EAP-Response/ 330 EAP-Type=EAP-MS-CHAP-V2 331 (Change Password)-> 332 <- PPP EAP-Request/ 333 EAP-Type=EAP-MS-CHAP-V2 334 (Success) 336 PPP EAP-Response/ 337 EAP-Type=EAP-MS-CHAP-V2 338 (Ack) -> 339 <- PPP EAP-Success 341 Note that the AAA/EAP Server may choose to re-iterate around the 342 password change cycle if required, for example if the new password 343 did not meet some password validation policy. 345 In the case where the EAP-MS-CHAP-V2 authentication was successful, 346 and the client wishes to change the users password, the conversation 347 will appear as follows: 349 Authenticating Peer Authenticator 350 ------------------- ------------- 351 <- PPP EAP-Request/ 352 Identity 353 PPP EAP-Response/ 354 Identity (MyID) -> 355 <- PPP EAP-Request/ 356 EAP-Type=EAP-MS-CHAP-V2 357 (Challenge) 358 PPP EAP-Response/ 359 EAP-Type=EAP-MS-CHAP-V2 360 (Response)-> 362 <- PPP EAP-Request/ 363 EAP-Type=EAP-MS-CHAP-V2 364 (Success) 366 PPP EAP-Response/ 367 EAP-Type=EAP-MS-CHAP-V2 368 (Failure = password expired) -> 370 <- PPP EAP-Request/ 371 EAP-Type=EAP-MS-CHAP-V2 372 (Challenge) 374 PPP EAP-Response/ 375 EAP-Type=EAP-MS-CHAP-V2 376 (Change Password)-> 377 <- PPP EAP-Request/ 378 EAP-Type=EAP-MS-CHAP-V2 379 (Success) 380 PPP EAP-Response/ 381 EAP-Type=EAP-MS-CHAP-V2 382 (Ack) -> 383 <- PPP EAP-Success 385 4. Detailed description of the EAP-MS-CHAP-V2 protocol 387 4.1. PPP EAP MS-CHAP-V2 Packet Format 389 A summary of the PPP EAP MS-CHAP-V2 Request/Response packet format is 390 shown below. The fields are transmitted from left to right. 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Code | Identifier | Length | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Type | Data... 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Code 402 1 - Request 403 2 - Response 405 Identifier 407 The identifier field is one octet and aids in matching responses 408 with requests. 410 Length 412 The Length field is two octets and indicates the length of the EAP 413 packet including the Code, Identifier, Length, Type, and Data 414 fields. Octets outside the range of the Length field should be 415 treated as Data Link Layer padding and should be ignored on 416 reception. 418 Type 420 29 - EAP MS-CHAP V2 422 Data 424 The format of the Data field is determined by the Code field. 426 4.2. PPP EAP MS-CHAP-V2 Request Packet 428 A summary of the PPP EAP MS-CHAP-V2 Request packet format is shown 429 below. The fields are transmitted from left to right. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Code | Identifier | Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type | MS-CHAP Type | MS-CHAP Data... 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 Code 441 1 443 Identifier 445 The Identifier field is one octet and aids in matching responses 446 with requests. The Identifier field MUST be changed on each 447 Request packet. 449 Length 451 The Length field is two octets and indicates the length of the EAP 452 packet including the Code, Identifier, Length, Type, MS-CHAP Type 453 and MS-CHAP Data fields. 455 Type 457 29 - EAP MS-CHAP V2 459 MS-CHAP Type 461 This value defines the content of the MS-CHAP Data defined in [6] 462 with the exception of Ack which is added for the purposes of 463 synchronisation between the peer and the AAA/EAP Server. 465 To aid clarity the RADIUS VSA names from [5] are given in 466 parenthesis. 468 0 for Ack - length of MS-CHAP data is 0 469 1 for Challenge Packet (MS-CHAP-Challenge) 470 2 for Success Packet (MS-CHAP2-Success) 471 3 for Failure Packet (MS-CHAP-Error) 473 MS-CHAP Data 475 The MS-CHAP data consists of an encapsulated MS-CHAP-V2 packet as 476 defined in [6] 478 4.3. PPP EAP MS-CHAP-V2 Response Packet 480 A summary of the PPP EAP MS-CHAP-V2 Response packet format is shown 481 below. The fields are transmitted from left to right. 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Code | Identifier | Length | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Type | MS-CHAP Type | MS-CHAP Data 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Code 493 2 495 Identifier 497 The Identifier field is one octet and MUST match the Identifier 498 field from the corresponding request. 500 Length 502 The Length field is two octets and indicates the length of the 503 EAP packet including the Code, Identifier, Length, Type, MS-CHAP 504 Type and MS-CHAP Data fields. 506 Type 508 29 - EAP MS-CHAP V2 510 MS-CHAP Type 512 This value defines the content of the MS-CHAP Data defined in [6]. 513 To aid clarity the RADIUS VSA names from [5] are given in 514 parenthesis. 516 1 for Response Packet (MS-CHAP2-Response) 517 2 for Change Password Packet (MS-CHAP-CPW + MS-CHAP-NT-Enc-PW) 518 3 for Failure Packet (MS-CHAP-Error) 520 5. Security Considerations 522 Various cryptanalysis have been published on MS-CHAP versions 1 and 2 523 and most conclude that version 2 has overcome most of the weaknesses 524 originally found in version 1. As noted in [6] a major issue is the 525 use of weak passwords making the protocol more vulnerable to 526 dictionary based attacks. 528 Version rollback (to MSCHAP v1) is avoided by the EAP/AAA Server 529 ensuring the format of the MS-CHAP response matches that defined 530 in [6]. 532 Using a toolkit to generate cryptographically random challenges 533 should also increase the overall security of the protocol. 535 The use of MPPE for session keys will not be as strong as those 536 generated by some other EAP protocols such as EAP-TLS. 538 6. References 540 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 541 51, RFC 1661, July 1994. 543 [2] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol" 544 RFC 2716, October 1999. 546 [3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 547 Protocol (EAP)", RFC 2284, March 1998. 549 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 550 Levels", BCP 14, RFC 2119, March 1997. 552 [5] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 553 RFC 2548, March 1999. 555 [6] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 556 RFC 2759, January 2000. 558 [7] Zorn, G., "MPPE Key Derivation", 559 draft-ietf-pppext-mppe-keys-03, October 2000. 561 [8] Rigney, C, et al, "RADIUS Extensions", 562 RFC 2869, June 2000. 564 [9] Zorn, G., Pall G., "Microsoft Point-To-Point Encryption (MPPE) 565 Protocol", draft-ietf-pppext-mppe-04, October 1999. 567 7. Acknowledgments 569 Thanks to Chris Murray, Ilan Frenkel, John Schnizlein and Glen Zorn 570 for their comments and help. 572 8. Authors' Addresses 574 Darran Potter 575 Cisco Systems Ltd 576 New Square Park 577 Bedfont Lakes 578 Middlesex, TW14 8HA 579 UK 581 EMail: dpotter@cisco.com 583 John Zamick 584 Cisco Systems Ltd 585 New Square Park 586 Bedfont Lakes 587 Middlesex, TW14 8HA 588 UK 590 EMail: jzamick@cisco.com 592 Full Copyright Statement 594 Copyright (C) The Internet Society (2002). All Rights Reserved. 596 This document and translations of it may be copied and furnished to 597 others, and derivative works that comment on or otherwise explain it 598 or assist in its implementation may be prepared, copied, published 599 and distributed, in whole or in part, without restriction of any 600 kind, provided that the above copyright notice and this paragraph are 601 included on all such copies and derivative works. However, this 602 document itself may not be modified in any way, such as by removing 603 the copyright notice or references to the Internet Society or other 604 Internet organizations, except as needed for the purpose of 605 developing Internet standards in which case the procedures for 606 copyrights defined in the Internet Standards process must be 607 followed, or as required to translate it into languages other than 608 English. 610 The limited permissions granted above are perpetual and will not be 611 revoked by the Internet Society or its successors or assigns. 613 This document and the information contained herein is provided on an 614 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 615 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 616 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 617 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 618 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 620 Acknowledgement 622 Funding for the RFC Editor function is currently provided by the 623 Internet Society.