idnits 2.17.1 draft-hiller-eap-tlv-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 7 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 8 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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 29 has weird spacing: '...>, and expir...' == Line 271 has weird spacing: '...imed to perta...' == Line 315 has weird spacing: '...>, and expir...' == 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) == Missing Reference: 'RFC2284' is mentioned on line 132, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) == Unused Reference: 'RFC2246' is defined on line 235, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2284 (ref. 'RFC2246') (Obsoleted by RFC 3748) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hiller 3 INTERNET-DRAFT Lucent Technologies 4 Category: Standards Track A. Palekar 5 Microsoft Corporation 6 28 October 2002 G. Zorn 7 Cisco Systems 9 A Container Type for the Extensible Authentication Protocol (EAP) 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 This memo is filed as , and expires April 30 28, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 The Extensible Authentication Protocol (EAP), defined in RFC 2284, 39 provides for support of multiple authentication methods. While EAP was 40 originally created for use with PPP, it has since been adopted for use 41 with IEEE 802.1X "Network Port Authentication". 43 Since its deployment, a number of weaknesses in EAP have become 44 apparent. These include the lack of protection for, and acknowledgement 45 of Success and Failure messages. 47 This memo describes an approach that may be taken to solve these 48 problems and others by defining a new EAP type which includes as payload 49 standard Type-Length-Value (TLV) objects. 51 1. Introduction 53 The Extensible Authentication Protocol (EAP), described in [RFC2284], 54 provides a standard mechanism for support of multiple authentication 55 methods. Through the use of EAP, support for a number of authentication 56 schemes may be added, including smart cards, Kerberos, Public Key, One 57 Time Passwords, and others. 59 One of the goals of EAP is to enable development of new authentication 60 methods without requiring deployment of new code on the Network Access 61 Server (NAS). As a result, the NAS acts as a "passthrough", and need not 62 understand specific EAP methods. 64 Figure 1 describes the relationship between the EAP peer, NAS and 65 backend authentication server. As described in the figure, the EAP 66 conversation "passes through" the NAS on its way between the client and 67 the backend authentication server. While the authentication 68 conversation is between the EAP peer and backend authentication server, 69 the NAS and backend authentication server need to have established trust 70 for the conversation to proceed. 72 +-+-+-+-+-+ +-+-+-+-+-+ 73 | Link | | Link | 74 | Layer | | Layer | 75 | Cipher- | | Cipher- | 76 | Suite | | Suite | 77 | | | | 78 +-+-+-+-+-+ +-+-+-+-+-+ 79 ^ ^ 80 | | 81 | | 82 | | 83 V V 84 +-+-+-+-+-+ +-+-+-+-+-+ Trust +-+-+-+-+-+ 85 | | EAP | |<======>| | 86 | | Conversation | | | | 87 | EAP |<================================>| EAP | 88 | Peer | (over PPP, | NAS | | Server | 89 | | 802.11,etc.) | |<=======| | 90 | | | | Keys | | 91 | | | | | | 92 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 93 ^ ^ 94 | | 95 | EAP API | EAP API 96 | | 97 V V 98 +-+-+-+-+-+ +-+-+-+-+-+ 99 | | | | 100 | | | | 101 | EAP | | EAP | 102 | Method | | Method | 103 | | | | 104 +-+-+-+-+-+ +-+-+-+-+-+ 106 Figure 1 - Relationship between EAP client, backend authentication 107 server and NAS. 109 Using EAP-TLV, it is possible for various type of data to be passed 110 directly between the backend authentication server and the EAP peer, and 111 to provide functionality not included in RFC 2284 without defining a 112 multiplicity of new EAP Types. 114 [Editor's Note: In fact, I'm not sure why we couldn't just redefine the 115 whole of EAP in terms of this type...] 117 This memo is offered to the EAP WG for discussion and possible adoption 118 as a solution to issues #10, 26 and 40. 120 2. Requirements language 122 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 123 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 124 described in [RFC2119]. 126 3. The EAP Type-Length-Value (EAP-TLV) Type 128 Description 130 EAP-TLV is a "special case" Type, more akin to the Identity and 131 Notification Types than the authentication Types such as 132 MD5-Challenge [RFC2284]. EAP-TLV differs from the Identity and 133 Notification Types, however, in that a Peer MAY respond to an EAP- 134 TLV Request with a Nak Response. This is allowed for backward 135 compatability with implementations that do not support the EAP-TLV 136 Type. 138 Type 140 33 142 Type-Data 144 The Data field is variable length, and contains Type-Length-Value 145 objects (TLVs). 147 3.1. TLV Format 149 TLVs are defined as follows: 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 |M|R| Type | Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Value... 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 M 161 0 - Non-mandatory TLV 162 1 - Mandatory TLV 164 R 165 Reserved, set to zero (0) 167 Type 169 A 14-bit field, denoting the attribute type. Allocated AVP Types 170 include: 171 0 - Reserved 172 1 - Reserved 173 2 - Reserved 174 3 - Acknowledged Result 176 Length 178 The length of the Value field in octets. 180 Value 182 The value of the object. 184 3.2. Result TLV 186 The Result TLV provides support for acknowledged Success and Failure 187 messages within EAP. It is defined as follows: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 |M|R| Type | Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Status | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 M 199 1 - Mandatory TLV 201 R 203 Reserved, set to zero (0) 205 AVP Type 207 3 - Success/Failure 209 Length 211 2 213 Status 215 The status field is two octets. Values include: 217 1 - Success 218 2 - Failure 220 4. Discussion 222 It's not hard to come up with other uses for the EAP-TLV Type. For 223 example, it could be used in the negotiation of language and charset for 224 Notification messages; a MAC TLV might be defined to cryptographically 225 protect the message (and incidentally enable mutual authentication for 226 types that might not otherwise support it); a Response might contain an 227 IPv6 Binding Update and the corresponding protected Success message 228 include the address of a dynamically assigned home agent, etc. 230 5. Normative references 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC2246] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 236 Protocol (EAP)", RFC 2284, March 1998. 238 Author's Addresses 240 Tom Hiller 241 Lucent Technologies 242 1960 Lucent Lane 243 Naperville, IL 60566 244 USA 246 Phone: +1 630 979 7673 247 Email: tom.hiller@lucent.com 249 Ashwin Palekar 250 Microsoft Corporation 251 One Microsoft Way 252 Redmond, WA 98052 253 USA 255 Phone: +1 425 882 8080 256 EMail: ashwinp@microsoft.com 257 Glen Zorn 258 Cisco Systems 259 500 108th Avenue N.E. 260 Suite 500 261 Bellevue, Washington 98004 262 USA 264 Phone: +1 425 344 8113 265 Fax: +1 425 740 0168 266 EMail: gwz@cisco.com 268 Intellectual Property Statement 270 The IETF takes no position regarding the validity or scope of any 271 intellectual property or other rights that might be claimed to pertain 272 to the implementation or use of the technology described in this 273 document or the extent to which any license under such rights might or 274 might not be available; neither does it represent that it has made any 275 effort to identify any such rights. Information on the IETF's 276 procedures with respect to rights in standards-track and standards- 277 related documentation can be found in BCP-11. Copies of claims of 278 rights made available for publication and any assurances of licenses to 279 be made available, or the result of an attempt made to obtain a general 280 license or permission for the use of such proprietary rights by 281 implementors or users of this specification can be obtained from the 282 IETF Secretariat. 284 The IETF invites any interested party to bring to its attention any 285 copyrights, patents or patent applications, or other proprietary rights 286 which may cover technology that may be required to practice this 287 standard. Please address the information to the IETF Executive 288 Director. 290 Full Copyright Statement 292 Copyright (C) The Internet Society (2002). All Rights Reserved. 293 This document and translations of it may be copied and furnished to 294 others, and derivative works that comment on or otherwise explain it or 295 assist in its implementation may be prepared, copied, published and 296 distributed, in whole or in part, without restriction of any kind, 297 provided that the above copyright notice and this paragraph are included 298 on all such copies and derivative works. However, this document itself 299 may not be modified in any way, such as by removing the copyright notice 300 or references to the Internet Society or other Internet organizations, 301 except as needed for the purpose of developing Internet standards in 302 which case the procedures for copyrights defined in the Internet 303 Standards process must be followed, or as required to translate it into 304 languages other than English. The limited permissions granted above are 305 perpetual and will not be revoked by the Internet Society or its 306 successors or assigns. This document and the information contained 307 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 308 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 309 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 310 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 311 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 313 Expiration Date 315 This memo is filed as , and expires April 316 28, 2003.