idnits 2.17.00 (12 Aug 2021) /tmp/idnits21761/draft-aboba-pppext-eap-vendor-01.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 4 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 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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. 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 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 (24 February 2002) is 7384 days in the past. Is this intentional? 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: 'RFC2434' is defined on line 157, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE80211' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021X' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group B. Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Standards Track 5 6 24 February 2002 7 Updates: RFC 2284 9 The Vendor-Specific EAP Method 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC 2026. 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 This document defines a Vendor-Specific Method for the Extensible 36 Authentication Protocol (EAP), defined in RFC 2284. 38 1. Introduction 40 The Extensible Authentication Protocol (EAP), defined in [RFC2284] is a 41 general protocol for authentication which supports multiple 42 authentication mechanisms. EAP may be used on dedicated links as well 43 as switched circuits, and wired as well as wireless links. 45 To date, EAP has been implemented with hosts and routers that connect 46 via switched circuits or dial-up lines using PPP [RFC1661]. It also also 47 been implemented with switches and wireless access points [IEEE80211] 48 over IEEE 802 local area networks [IEEE802] implementing IEEE 802.1X 49 [IEEE8021X]. 51 Due to EAP's popularity, the original Method Type space, which only 52 provides for 255 values, is being allocated at a pace, which if 53 continued, would result in exhaustion within a few years. Since many of 54 the existing uses of EAP are vendor-specific, the Vendor-Specific Method 55 Type is available to allow vendors to support their own extended Types 56 not suitable for general usage. The Vendor-specific Type may also be 57 used to expand the global Method Type space beyond the original 255 58 values. 60 1.1. Specification of Requirements 62 In this document, several words are used to signify the requirements of 63 the specification. These words are often capitalized. The key words 64 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 65 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 66 interpreted as described in [RFC2119]. 68 2. EAP Vendor Specific Method 70 Description 72 This Method Type is available to allow vendors to support their own 73 extended Types not suitable for general usage. The Vendor-specific 74 Type may also be used to expand the global Method Type space beyond 75 the original 255 values. 77 Peers not equipped to interpret the vendor-specific information sent 78 by an authenticator MUST send a NAK, and negotiate a more suitable 79 authentication method. 81 A summary of the Vendor-specific Type format is shown below. The 82 fields are transmitted from left to right. 84 0 1 2 3 85 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 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 | Type | Vendor-Id | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | String... 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 Type 94 255 for Vendor-specific 96 Vendor-Id 98 The Vendor-Id is 3 octets and represents the SMI Network Management 99 Private Enterprise Code of the Vendor in network byte order, as 100 allocated by IANA. A Vendor-Id of zero is reserved for use by the 101 IETF in providing an expanded global EAP Type space. 103 String 105 The String field is one or more octets. The actual format of the 106 information is site or application specific, and a robust 107 implementation SHOULD support the field as undistinguished octets. 109 The codification of the range of allowed usage of this field is 110 outside the scope of this specification. 112 It SHOULD be encoded as follows. The Vendor-Specific field is 113 dependent on the vendor's definition of that attribute. An example 114 encoding of the Vendor-Specific attribute using this method follows. 116 Example Implementation 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Type | Vendor-Id | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Vendor-Type | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Vendor-Specific... 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Vendor-Type 130 The Vendor-Type field is four octets and represents the vendor- 131 specific Method Type. Where a Vendor-Id of zero is present, the 132 Vendor-Type field provides an expanded global EAP Type space, 133 beginning with EAP Type values of 256. 135 Vendor-Specific 137 The Vendor-Specific field is dependent on the vendor's definition of 138 that attribute. Where a Vendor-Id of zero is present, the Vendor- 139 Specific field will be used for transporting the contents of EAP 140 Methods of Types 256 or greater. 142 3. IANA Considerations 144 This document requires allocation of EAP Method Type 255 for vendor- 145 specific use. 147 4. Normative references 149 [RFC1661] 150 Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 151 July 1994. 153 [RFC2119] 154 Bradner, S., "Key words for use in RFCs to Indicate Requirement 155 Levels", RFC 2119, March 1997. 157 [RFC2434] 158 Alvestrand, H. and Narten, T., "Guidelines for Writing an IANA 159 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 161 [RFC2284] 162 Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 163 (EAP)", RFC 2284, March 1998. 165 [IEEE802] 166 IEEE Standards for Local and Metropolitan Area Networks: Overview 167 and Architecture, ANSI/IEEE Std 802, 1990. 169 [IEEE80211] 170 Information technology - Telecommunications and information 171 exchange between systems - Local and metropolitan area networks - 172 Specific Requirements Part 11: Wireless LAN Medium Access Control 173 (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 174 802.11-1997, 1997. 176 [IEEE8021X] 177 IEEE Standards for Local and Metropolitan Area Networks: Port based 178 Network Access Control, IEEE Std 802.1X-2001, June 2001. 180 5. Security Considerations 182 Since support for the Vendor-specific type is optional, it cannot be 183 used to support methods whose use is mandatory in a given situation. As 184 a result, EAP methods that are expected to find common use should be 185 allocated Method Types of 254 or less. 187 Acknowledgments 189 Thanks to John Vollbrecht of Interlink Networks and Tim Moore of 190 Microsoft for discussions relating to this document. 192 Authors' Addresses 194 Bernard Aboba 195 Microsoft Corporation 196 One Microsoft Way 197 Redmond, WA 98052 199 EMail: bernarda@microsoft.com 200 Phone: +1 425 706 6605 201 Fax: +1 425 706 7329 203 Full Copyright Statement 205 Copyright (C) The Internet Society (2002). All Rights Reserved. 206 This document and translations of it may be copied and furnished to 207 others, and derivative works that comment on or otherwise explain it or 208 assist in its implementation may be prepared, copied, published and 209 distributed, in whole or in part, without restriction of any kind, 210 provided that the above copyright notice and this paragraph are included 211 on all such copies and derivative works. However, this document itself 212 may not be modified in any way, such as by removing the copyright notice 213 or references to the Internet Society or other Internet organizations, 214 except as needed for the purpose of developing Internet standards in 215 which case the procedures for copyrights defined in the Internet 216 Standards process must be followed, or as required to translate it into 217 languages other than English. The limited permissions granted above are 218 perpetual and will not be revoked by the Internet Society or its 219 successors or assigns. This document and the information contained 220 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 221 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 222 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 223 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 224 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 226 Expiration Date 228 This memo is filed as , and 229 expires August 19, 2002.