idnits 2.17.00 (12 Aug 2021) /tmp/idnits59951/draft-calhoun-diameter-eap-03.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: ---------------------------------------------------------------------------- ** 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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? == The page length should not exceed 58 lines per page, but there was 23 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 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 660 has weird spacing: '... sends the ...' == Line 661 has weird spacing: '...dentity packe...' == Line 735 has weird spacing: '... In the ca...' == Line 1014 has weird spacing: '... copied and ...' == Line 1015 has weird spacing: '...s, and deriv...' == (8 more instances...) == 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.) -- 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) == Unused Reference: '3' is defined on line 950, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 953, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 966, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 969, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 973, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2284 (ref. '1') (Obsoleted by RFC 3748) -- No information found for draft-calhoun-diameter-auth - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2138 (ref. '3') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '5') == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-08 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2434 (ref. '10') (Obsoleted by RFC 5226) == Outdated reference: A later version (-04) exists of draft-calhoun-diameter-proxy-02 -- Possible downref: Normative reference to a draft: ref. '13' Summary: 12 errors (**), 0 flaws (~~), 17 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Microsystems, Inc. 3 Title: draft-calhoun-diameter-eap-03.txt Allan Rubens 4 Date: August 1999 Ascend Networks Inc. 5 Jeff Haag 6 Cisco Systems 8 DIAMETER 9 Extensible Authentication Protocol (EAP) Extensions 11 Status of this Memo 13 This document is an individual contribution for consideration by the 14 AAA Working Group of the Internet Engineering Task Force. Comments 15 should be submitted to the diameter@ipass.com mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at: 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at: 36 http://www.ietf.org/shadow.html. 38 Abstract 40 The Extensible Authentication Protocol (EAP) is a PPP extension that 41 provides support for additional authentication methods within PPP. 42 This document describes how EAP can be carried within the DIAMETER 43 protocol to provide end to end authentication. 45 Table of Contents 47 1.0 Introduction 48 1.1 Copyright Statement 49 1.2 Requirements language 50 1.3 Changes in version -02 51 2.0 Command Codes 52 2.1 DIAMETER-EAP-Request 53 2.2 DIAMETER-EAP-Answer 54 2.3 DIAMETER-EAP-Ind 55 3.0 DIAMETER AVPs 56 3.1 EAP-Packet 57 4.0 Protocol overview 58 4.1 Retransmission and Timers 59 4.2 Example of an OTP Authentication 60 4.2.1 Successful Authentication 61 4.2.2 NAS Initiated EAP Authentication 62 4.2.3 Server-Initiated Authentication 63 4.2.4 Example of failed EAP Authentication 64 4.2.5 Example of DIAMETER not supporting EAP 65 4.2.6 Example of DIAMETER Proxy not supporting EAP 66 4.2.7 Example of PPP Client not supporting EAP 67 4.3 Feature Advertisement/Discovery 68 5.0 Alternative uses 69 6.0 IANA Considerations 70 7.0 Acknowledgments 71 8.0 References 72 9.0 Authors' Addresses 73 10.0 Full Copyright Statement 75 1.0 Introduction 77 The Extensible Authentication Protocol (EAP), described in [1], 78 provides a standard mechanism for support of additional 79 authentication methods within PPP. Through the use of EAP, support 80 for a number of authentication schemes may be added, including token 81 cards, Kerberos, Public Key, One Time Passwords, and others. In order 82 to provide for support of EAP within DIAMETER, two new attributes, 83 EAP-Message and Signature, were introduced as DIAMETER extensions in 84 [5]. This document describes how these new attributes may be used for 85 providing EAP support within DIAMETER. 87 The scheme described here is similar to that proposed in [2], in that 88 the DIAMETER server is used to shuttle DIAMETER-encapsulated EAP 89 Packets between the NAS and a backend security server. While the 90 conversation between the DIAMETER server and the backend security 91 server will typically occur using a proprietary protocol developed by 92 the backend security server vendor, it is also possible to use 93 DIAMETER-encapsulated EAP via the EAP-Packet AVP. This has the 94 advantage of allowing the DIAMETER server to support EAP without the 95 need for authentication- specific code, which can instead reside on a 96 backend security server. 98 This proposal serves three purposes: 100 1. It provides for end-to-end authentication, between the user and 101 his/her home DIAMETER server. End-to-End authentication, as 102 described in this specification, greatly reduces the possibility 103 for fraudulent authentication, such as replay attacks. 105 2. It allows for mutual (bi-directional) authentication. When PPP 106 or CHAP are used as the PPP authentication mechanism, it is not 107 possible to perform bi-directional authentication since the 108 authenticator (e.g. the NAS) does not have access to the DIAMETER 109 Server's authentication information. Although it would be 110 possible for the DIAMETER server to "download" the authentication 111 information to the NAS, even encrypted, it would be quite unwise 112 to do so in roaming environments where the NAS and the 113 authenticating DIAMETER server are not owned by the same 114 Administrative Domain. 116 3. It allows for home DIAMETER server initiated authentication. 117 Since the Home DIAMETER server may initially authenticate and 118 authorize the user for a finite period, it may periodically send 119 an authentication request to the user to ensure that the user is 120 still active. Furthermore, this will allow the Home DIAMETER 121 server to re-authorize the user for access for a finite amount of 122 time. See [8] for more information. 124 The Extension number for this draft is three (3). This value is 125 used in the Extension-Id Attribute value Pair (AVP) as defined in 126 [7]. 128 1.1 Copyright Statement 130 Copyright (C) The Internet Society 1999. All Rights Reserved. 132 1.2 Requirements language 134 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 135 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 136 described in [6]. 138 1.3 Changes in version -03 140 The following changes were made in this revision of the document: 142 - The document introduces the DIAMETER-EAP-Ind to allow the server 143 to initiate an unsolicited authentication session with the PPP 144 client as described in [8]. 146 - The AVP Header formats have changed since the last version of 147 this draft. 149 - IANA considerations were added, as well as many new useful 150 references. 152 - Well, to be honest, the list of changes are just too great list. 153 This document needed a good re-write. Here it is. 155 2.0 Command Codes 157 This section will define the Commands [1] for DIAMETER 158 implementations supporting the Mobile IP extension. 160 Command Name Command Code 161 ----------------------------------- 162 DIAMETER-EAP-Request ??? 163 DIAMETER-EAP-Answer ??? 164 DIAMETER-EAP-Ind ??? 166 2.1 DIAMETER-EAP-Request 168 Description 170 The DIAMETER-EAP-Request command is sent by a DIAMETER Client to a 171 DIAMETER Server and conveys an EAP-Response [1] from the dial-up 172 PPP Client. The DIAMETER-EAP-Request MUST contain one EAP-Packet 173 AVP, which contains the actual EAP payload. A EAP-Packet AVP with 174 no data MAY be sent to the DIAMETER Server to initiate an EAP 175 authentication session. 177 Upon receipt of a DIAMETER-EAP-Request, A DIAMETER Server MUST 178 issue a reply. The reply may be either: 180 1) a DIAMETER-EAP-Answer containing an EAP-Request in at lease 181 one EAP-Packet attribute 183 2) a DIAMETER-EAP-Answer containing an EAP-Packet of type 184 "success" and a Result Code AVP indicating success 186 3) a DIAMETER-EAP-Answer containing an EAP-Packet of type 187 "failure" and a Result-Code AVP indicating failure. 189 4) A Message-Reject-Ind packet is returned if the server does 190 not support the EAP extensions. 192 Message Format 194 ::= 195 196 197 [] 198 199 200 201 202 { || 203 ::= 277 278 279 281 [] 282 283 284 285 286 287 { || 288 ::= 356 357 358 [] 359 360 361 362 363 { || 364 621 DIAMETER- 622 EAP-Request/ 623 EAP-Packet/Start -> 624 <- DIAMETER- 625 EAP-Answer/ 626 EAP-Packet/Identity 627 <- PPP EAP-Request/ 628 Identity 629 PPP EAP-Response/ 630 Identity (MyID) -> 631 DIAMETER- 632 EAP-Request/ 633 EAP-Packet/ 634 EAP-Response/ 635 (MyID) -> 636 <- DIAMETER- 637 EAP-Answer/ 638 EAP-Packet/EAP-Request 639 OTP/OTP Challenge 640 <- PPP EAP-Request/ 641 OTP/OTP Challenge 642 PPP EAP-Response/ 643 OTP, OTPpw -> 644 DIAMETER- 645 EAP-Request/ 646 EAP-Packet/ 647 EAP-Response/ 648 OTP, OTPpw -> 649 <- DIAMETER- 650 EAP-Answer/ 651 EAP-Packet/EAP-Success 652 (other attributes) 653 <- PPP EAP-Success 654 PPP Authentication 655 Phase complete, 656 NCP Phase starts 658 4.2.2 NAS Initiated EAP Authentication 660 In the case where the NAS sends the authenticating peer an 661 EAP- Request/Identity packet without first sending an EAP-Start 662 packet to the DIAMETER server, the conversation would appear as 663 follows: 665 Authenticating Peer NAS DIAMETER Server 666 ------------------- --- --------------- 668 <- PPP LCP Request-EAP 669 auth 670 PPP LCP ACK-EAP 671 auth -> 672 <- PPP EAP-Request/ 673 Identity 674 PPP EAP-Response/ 675 Identity (MyID) -> 676 DIAMETER- 677 EAP-Request/ 678 EAP-Packet/ 679 EAP-Response/ 680 (MyID) -> 681 <- DIAMETER- 682 EAP-Answer/ 683 EAP-Packet/EAP-Request 684 OTP/OTP Challenge 685 <- PPP EAP-Request/ 686 OTP/OTP Challenge 687 PPP EAP-Response/ 688 OTP, OTPpw -> 689 DIAMETER- 690 EAP-Request/ 691 EAP-Packet/ 692 EAP-Response/ 693 OTP, OTPpw -> 694 <- DIAMETER- 695 EAP-Answer/ 696 EAP-Packet/EAP-Success 697 (other attributes) 698 <- PPP EAP-Success 699 PPP Authentication 700 Phase complete, 701 NCP Phase starts 703 4.2.3 Server-Initiated Authentication 705 As described in [8], when a server has successfully authenticated and 706 authorized a user, it may include a timeout period to the 707 authorization. The server can later initiate an unsolicited re- 708 authentication request to the user, through the NAS. This method has 709 the advantage of reducing the number of round trips required for re- 710 authentication/authorization. 712 Authenticating Peer NAS DIAMETER Server 713 ------------------- --- --------------- 715 <- DIAMETER-EAP-Ind/ 716 EAP-Packet/EAP-Request 717 OTP/OTP Challenge 718 <- PPP EAP-Request/ 719 OTP/OTP Challenge 720 PPP EAP-Response/ 721 OTP, OTPpw -> 722 DIAMETER- 723 EAP-Request/ 724 EAP-Packet/ 725 EAP-Response/ 726 OTP, OTPpw -> 727 <- DIAMETER- 728 EAP-Answer/ 729 EAP-Packet/EAP-Success 730 (other attributes) 731 <- PPP EAP-Success 733 4.2.4 Example of failed EAP Authentication 735 In the case where the client fails EAP authentication, 736 the conversation would appear as follows: 738 Authenticating Peer NAS DIAMETER Server 739 ------------------- --- --------------- 741 <- PPP LCP Request-EAP 742 auth 743 PPP LCP ACK-EAP 744 auth -> 745 DIAMETER- 746 EAP-Request/ 747 EAP-Packet/Start -> 748 <- DIAMETER- 749 EAP-Answer/ 750 EAP-Packet/Identity 751 <- PPP EAP-Request/ 752 Identity 753 PPP EAP-Response/ 754 Identity (MyID) -> 755 DIAMETER- 756 EAP-Request/ 757 EAP-Packet/ 758 EAP-Response/ 759 (MyID) -> 760 <- DIAMETER- 761 EAP-Answer/ 762 EAP-Packet/EAP-Request 763 OTP/OTP Challenge 764 <- PPP EAP-Request/ 765 OTP/OTP Challenge 766 PPP EAP-Response/ 767 OTP, OTPpw -> 768 DIAMETER- 769 EAP-Request/ 770 EAP-Packet/ 771 EAP-Response/ 772 OTP, OTPpw -> 773 <- DIAMETER- 774 EAP-Answer/ 775 EAP-Packet/EAP-Failure 776 <- PPP EAP-Failure 778 <- LCP Terminate 780 4.2.5 Example of DIAMETER not supporting EAP 782 In the case that the DIAMETER server or proxy does not support EAP 783 extensions the conversation would appear as follows: 785 Authenticating Peer NAS DIAMETER Server 786 ------------------- --- --------------- 788 <- PPP LCP Request-EAP 789 auth 790 PPP LCP ACK-EAP 791 auth -> 792 DIAMETER 793 EAP-Request/ 794 EAP-Packet/Start -> 795 <- DIAMETER 796 Command-Unrecognized 797 <- PPP LCP Request-CHAP 798 auth 800 PPP LCP ACK-CHAP 801 auth -> 802 <- PPP CHAP Challenge 803 PPP CHAP Response -> 804 DIAMETER 805 AA-Request-> 806 <- DIAMETER 807 AA-Answer 808 <- PPP LCP 809 CHAP-Success 810 PPP Authentication 811 Phase complete, 812 NCP Phase starts 814 4.2.6 Example of DIAMETER Proxy not supporting EAP 816 In the case where the local DIAMETER Server does support the EAP 817 extensions but the remote DIAMETER Server does not, the conversation 818 would appear as follows: 820 Authenticating Peer NAS DIAMETER Server 821 ------------------- --- --------------- 823 <- PPP LCP Request-EAP 824 auth 825 PPP LCP ACK-EAP 826 auth -> 827 DIAMETER- 828 EAP-Request/ 829 EAP-Packet/Start -> 830 <- DIAMETER- 831 EAP-Answer/ 832 EAP-Packet/Identity 833 <- PPP EAP-Request/ 834 Identity 835 PPP EAP-Response/ 836 Identity 837 (MyID) -> 838 DIAMETER- 839 EAP-Request/ 840 EAP-Packet/EAP-Response/ 841 (MyID) -> 842 <- DIAMETER- 843 EAP-Answer 844 (proxied from remote 845 DIAMETER Server) 846 <- PPP LCP Request-CHAP 847 auth 848 PPP LCP ACK-CHAP 849 auth -> 850 <- PPP CHAP Challenge 851 PPP CHAP Response -> 852 DIAMETER 853 AA-Request-> 854 <- DIAMETER 855 AA-Answer 856 (proxied from remote 857 DIAMETER Server) 858 <- PPP LCP 859 CHAP-Success 860 PPP Authentication 861 Phase complete, 862 NCP Phase starts 864 4.2.7 Example of PPP Client not supporting EAP 866 In the case where the authenticating peer does not support EAP, but 867 where EAP is required for that user, the conversation would appear as 868 follows: 870 Authenticating Peer NAS DIAMETER Server 871 ------------------- --- --------------- 873 <- PPP LCP Request-EAP 874 auth 875 PPP LCP NAK-EAP 876 auth -> 877 <- PPP LCP Request-EAP 878 auth 879 PPP LCP NAK-EAP 880 auth -> 881 <- PPP LCP Request-CHAP 882 auth 883 PPP LCP ACK-CHAP 884 auth -> 885 <- PPP CHAP Challenge 886 PPP CHAP Response -> 888 DIAMETER- 889 AA-Request/ 890 User-Name, 891 CHAP-Password -> 892 <- DIAMETER- 893 EAP-Answer/ 894 EAP-Packet 895 <- LCP Terminate Req 897 4.3 Feature Advertisement/Discovery 899 As defined in [8], the Reboot-Ind and Device-Feature-Query messages 900 can be used to inform a peer about locally supported DIAMETER 901 Extensions. In order to advertise support of this extension, the 902 Extension-Id AVP must be transmitted with a value of three (3). 904 5.0 Alternative uses 906 Currently the conversation between the backend security server and 907 the DIAMETER server is proprietary because of lack of 908 standardization. In order to increase standardization and provide 909 interoperability between DIAMETER vendors and backend security 910 vendors, it is recommended that DIAMETER-encapsulated EAP be used for 911 this conversation. 913 This has the advantage of allowing the DIAMETER server to support EAP 914 without the need for authentication-specific code within the DIAMETER 915 server. Authentication-specific code can then reside on a backend 916 security server instead. 918 In the case where DIAMETER-encapsulated EAP is used in a conversation 919 between a DIAMETER server and a backend security server, the Security 920 Server will typically return an DIAMETER-EAP-Aanswer/EAP-Packet/EAP- 921 Success message without inclusion of the expected attributes 922 currently returned in a successful AA-Answer [2]. This means that the 923 DIAMETER server MUST add these attributes prior to sending an 924 DIAMETER-EAP- Answer/EAP-Packet/EAP-Success message to the NAS. 926 6.0 IANA Considerations 928 The numbers for the Command Code AVPs (section 3) is taken from the 929 numbering space defined for Command Codes in [2]. The numbers for the 930 various AVPs defined in section 4 were taken from the AVP numbering 931 space defined in [2]. The numbering for the AVP and Command Codes 932 MUST NOT conflict with values specified in [2] and other DIAMETER 933 related Internet Drafts. 935 This document also introduces two new bits to the AVP Header, which 936 MUST NOT conflict with the base protocol [2] and any other DIAMETER 937 extension. 939 7.0 Acknowledgments 941 Thanks for Bernard Aboba for his contribution to [9]. Much of the 942 text found in this draft was taken directly from the said draft. 944 8.0 References 946 [1] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication 947 Protocol (EAP)." RFC 2284, March 1998. 948 [2] P. R. Calhoun, "DIAMETER Authentication Extension", 949 draft-calhoun-diameter-auth-06.txt, August 1999. 950 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 951 Authentication Dial In User Service (RADIUS)." RFC 2138, 952 April 1997. 953 [4] C. Rigney, "RADIUS Accounting." RFC 2139, April 1997. 954 [5] R. Rivest, S. Dusse, "The MD5 Message-Digest Algorithm", 955 RFC 1321, April 1992 956 [6] S. Bradner, "Key words for use in RFCs to Indicate 957 Requirement Levels", BCP 14, RFC 2119, March 1997. 959 [7] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", 960 draft-calhoun-diameter-08.txt, August 1999. 961 [8] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming", 962 draft-ietf-roamops-fraud-limit-00.txt, May 1999. 963 [9] P. R. Calhoun, A. Rubens, B. Aboba, "Extensible Authentication 964 Protocol Support in RADIUS", draft-ietf-radius-eap-05.txt, 965 Work in Progress, May 1998. 966 [10] Narten, Alvestrand,"Guidelines for Writing an IANA 967 Considerations Section in RFCs", BCP 26, RFC 2434, 968 October 1998 969 [11] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 970 July 1994. 971 [12] N Haller, C. Metz, P. Nesset, M. Straw, "A One-Time 972 Password (OTP) System", RFC 2289, February 1998. 973 [13] P. Calhoun, W. Bulley, "DIAMETER Proxy Server Extensions", 974 draft-calhoun-diameter-proxy-02.txt, Work in Progress, 975 August 1999. 977 9.0 Authors' Addresses 979 Questions about this memo can be directed to: 981 Pat R. Calhoun 982 Network and Security Research Center, Sun Labs 983 Sun Microsystems, Inc. 984 15 Network Circle 985 Menlo Park, California, 94025 986 USA 988 Phone: 1-650-786-7733 989 Fax: 1-650-786-6445 990 E-mail: pcalhoun@eng.sun.com 992 Allan C. Rubens 993 Ascend Communications 994 1678 Broadway 995 Ann Arbor, MI 48105-1812 996 USA 998 Phone: 1-734-761-6025 999 E-Mail: acr@del.com 1001 Jeff Haag 1002 Cisco Systems 1003 7025 Kit Creek Road 1004 PO Box 14987 1005 Research Triangle Park, NC 27709 1007 Phone: 1-919-392-2353 1008 E-Mail: haag@cisco.com 1010 10.0 Full Copyright Statement 1012 Copyright (C) The Internet Society (1999). All Rights Reserved. 1014 This document and translations of it may be copied and furnished 1015 to others, and derivative works that comment on or otherwise 1016 explain it or assist in its implmentation may be prepared, copied, 1017 published and distributed, in whole or in part, without 1018 restriction of any kind, provided that the above copyright notice 1019 and this paragraph are included on all such copies and derivative 1020 works. However, this docu- ment itself may not be modified in any 1021 way, such as by removing the copyright notice or references to the 1022 Internet Society or other Inter- net organizations, except as needed 1023 for the purpose of developing Internet standards in which case 1024 the procedures for copyrights defined in the Internet Standards 1025 process must be followed, or as required to translate it into 1026 languages other than English. The limited permis- sions granted 1027 above are perpetual and will not be revoked by the Internet 1028 Society or its successors or assigns. This document and the 1029 information contained herein is provided on an "AS IS" basis and 1030 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 1031 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1032 LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN 1033 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1034 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."