idnits 2.17.00 (12 Aug 2021) /tmp/idnits52117/draft-brzozowski-dhcp-eap-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2009) is 4798 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4014' is mentioned on line 226, but not defined == Unused Reference: 'RFC2132' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC3396' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 319, but no explicit reference was found in the text == Outdated reference: draft-narten-iana-considerations-rfc2434bis has been published as RFC 5226 -- No information found for draft-pruss-dhcp-auth-dsl - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Brzozowski 3 Internet-Draft Comcast Cable Communications 4 Intended status: Informational T. Lemon 5 Expires: September 26, 2009 Nominum 6 G. Hollan 7 Telus 8 March 25, 2009 10 DHCP Authentication Analysis 11 draft-brzozowski-dhcp-eap-analysis-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 26, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document analyzes and technically evaluate the techniques 50 proposed to support end-user authentication using extensions to DHCP. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Message and Option Definition . . . . . . . . . . . . . . . . . 3 58 3.1. Message and Option Parity . . . . . . . . . . . . . . . . . 4 59 3.2. Use of Vendor Options and Messages . . . . . . . . . . . . 4 60 3.3. Message and Option Sizing . . . . . . . . . . . . . . . . . 4 61 3.4. RADIUS Message Requiments . . . . . . . . . . . . . . . . . 5 62 4. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. DHCP Clients . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. DHCP Relay Agents . . . . . . . . . . . . . . . . . . . . . 6 65 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 This document provides an independent analysis of the proposal to 78 support end-user authentication using extension to DHCP. While the 79 current proposal largley focuses on Broadband Digital Subscriber Line 80 scenarions the adhoc team that has been assembled will evaulate the 81 proposal generally from a DHCP point of view. This analysis will 82 also cite architectural and best practice considerations for the 83 authors to consider as part of this work. 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. Terminology 93 The following terms and acronyms are used in this document: 95 DHCPv4 - "Dynamic Host Configuration Protocol" [RFC2131] 97 DHCPv6 - "Dynamic Host Configuration Protocol for IPv6" [RFC3315] 99 DHCP - DHCPv4 and/or DHCPv6 101 3. Message and Option Definition 103 This section discusses considerations pertaining to how the DHCPEAP 104 messages have been defined in [I-D.pruss-dhcp-auth-dsl]. This 105 section also makes recommendations as to how messages may be defined. 107 The draft [I-D.pruss-dhcp-auth-dsl] specifies two new message types, 108 DHCPEAP-REQ and DHCPEAP-RES, which are the primary DHCP messages 109 required to support end-user DHCP-based authentication. However, 110 based on the desired protocol behavior and common practices we 111 recommend that additional DHCPEAP message be specified to represent 112 the appropriate interaction between clients, servers, and relay 113 agent, because in some cases the DHCPEAP-REQ and DHCPEAP-RES messages 114 are being overloaded. A four message model would be more in keeping 115 with standard practice as exemplified by the message types defined in 116 [RFC3315]. 118 3.1. Message and Option Parity 120 Throughout the document [I-D.pruss-dhcp-auth-dsl] references to 121 DHCPv4 and DHCPv6 messages and options DHCPv6 are intermingled in 122 ways that are not valid. In some cases, message and option 123 definitions for DHCPv4 or DHCPv6 are omitted entirely. DHCPv4 124 messages and options must be referenced only for IPv4, and DHCPv6 125 messages and options must be used only for IPv6, where applicable, to 126 support DHCP-based end-user authentication. Definition of the DHCP 127 Authentication Protocol Option and EAP message option must be 128 clarified and explicitly defined for both DHCPv4 and DHCPv6. 129 Further, the DHCPEAP-REQ and DHCPEAP-RES messages along with any 130 additional messages must be clarified and explicitly defined for both 131 DHCPv4 and DHCPv6. 133 3.2. Use of Vendor Options and Messages 135 Given the very specific target of the proposal-- Broadband Digital 136 Subscriber Line networks--it seems practical for this proposal to use 137 vendor specific options for DHCP options required by the draft, 138 specifically the EAP message option. Furthermore, depending on the 139 availability of support for DHCP Vendor Messages, and its 140 standardization, the use of DHCP vendor message should also be 141 considered as part of this specification for any messages required to 142 support DHCP-based end-user authentication. The use of vendor 143 messages and options should be considered for clients, servers, and 144 relay agents to support the desired protocol behavior. 146 3.3. Message and Option Sizing 148 [I-D.pruss-dhcp-auth-dsl] introduces the EAP message option, which is 149 specified to carry authentication information. This information is 150 necessary to support the desired protocol behavior. However, 151 including this data in a DHCP packet greatly increases the size of 152 the options. [I-D.pruss-dhcp-auth-dsl] does specify how large 153 options are to be handled. However, there are a number of remaining 154 concerns: 156 The Maximum Message Size option is rarely used by DHCP clients and 157 as such we have no real operational experience to reassure us that 158 DHCP packets larger than 576 bytes will be carried transparently 159 by the infrastructure. 161 DHCPv4 clients are not required to implement buffers larger than 162 576 bytes; this draft must explicitly make such a requirement for 163 conforming DHCPv4 clients. 165 DHCPv4 servers are required not to send DHCP packets to clients 166 that are larger than 576 bytes without prior negotiation with the 167 client. 169 We have not studied how widespread support for DHCP packets longer 170 than 576 bytes is among deployed DHCP relay agents. We are 171 concerned that some DHCP relay agents will not be capable of 172 relaying such packets, and that this may create obstacles to 173 deploying the proposed protocol extension. 175 The EAP option may crowd out other options needed by the DHCP 176 client for normal operation. 178 3.4. RADIUS Message Requiments 180 Per section 5.1 of [I-D.pruss-dhcp-auth-dsl] RADIUS attributes to 181 support this behavior are required and not included as part of 182 [RFC4014]. These messages do not exists and need to be specified. 184 4. Protocol behavior 186 Generally the draft [I-D.pruss-dhcp-auth-dsl] defines specific 187 protocol behavior to support end-user DHCP-based authentication using 188 IPv4 and IPv6; each are handled independently. [I-D.pruss-dhcp-auth- 189 dsl] is not clear as to how clients and servers handle conflicts 190 where both IPv4 and IPv6 are used simultaneously. The draft should 191 specify how such conflicts are resolved when this situation arises. 192 See section 5 of [I-D.pruss-dhcp-auth-dsl] 194 4.1. DHCP Clients 196 Packet size for DHCP clients that support end-user DHCP-based 197 authentication remains a concern. DHCP clients MUST advertise their 198 ability to support larger packet sizes. DHCP clients in this case 199 include but are not limited to those included with operating systems 200 and home networking equipment. 202 The behavior for home gateway (HG) as defined in [I-D.pruss-dhcp- 203 auth-dsl] has been specified. However, specification of standalone 204 client behavior remains absent. In order for this proposal to be 205 complete it must specify how standalone client are to behave to 206 support end-user authentication using DHCP. 208 if the NAS client indicates to the home gateway (HG) client that DHCP 209 Authentication is supported but in fact does not support it, this 210 will cause the HG client to attempt DHCP Authentication erroneously. 211 The home gateway client's behavior in this case must be specified. 213 4.2. DHCP Relay Agents 215 The impact of the enlarged DHCP packets that contain the DHCP options 216 specified in [I-D.pruss-dhcp-auth-dsl] specifically the formation and 217 transmission of messages destined for the DHCP server(s) must be 218 considered. DHCP relay agents that support this behavior must be 219 able to generate the appropriate DHCP message types in addition to 220 supporting the necessary options. 222 [I-D.pruss-dhcp-auth-dsl] proposes that DHCP relay agent will be 223 required to append information to DHCP client requests to support 224 DHCP-based end-user authentication. The current text suggests that 225 [RFC4014] defines the appropriate atributes that would need to be 226 appended. It is not clear that [RFC4014] explicitly specifies both 227 the DHCPv4 and DHCPv6 attributes to support this behavior. 229 5. Compatibility 231 The compatibility of clients, servers, and relay agents that 232 implement this behavior with legacy clients, servers, and relay 233 agents MUST be explicitly documented. The behavior of the remaining 234 elements that do not support this behavior while others do MUST be 235 considered, specifically, how will legacy element handle the presence 236 of the corresponding DHCP options when present. Consider the 237 following scenarios, for example: 239 Only one element among the DHCP client, DHCP server and DHCP relay 240 agent support authentication. 242 Two of these elements support authentication, one does not. 244 All three elements support authentication. 246 6. Naming 248 The draft is currently titled "Authentication Extensions for the 249 Dynamic Host Configuration Protocol." This title implies that the 250 draft is a generic authentication extension for DHCP. Despite 251 optimistic suggestions that it might actually turn out to be such a 252 thing, really this proposed extension is fairly sharply targeted. So 253 we recommend choosing a title that reflects this specificity, rather 254 than the current generic title. 256 7. Acknowledgements 258 This template was derived from an initial version written by Pekka 259 Savola and contributed by him to the xml2rfc project. 261 This document is part of a plan to make xml2rfc indispensable . 263 8. IANA Considerations 265 This memo includes no request to IANA. 267 All drafts are required to have an IANA considerations section (see 268 the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] 269 for a guide). If the draft does not require IANA to do anything, the 270 section contains an explicit statement that this is the case (as 271 above). If there are no requirements for IANA, the section will be 272 removed during conversion into an RFC by the RFC Editor. 274 9. Security Considerations 276 This draft does not propose the use of RFC3118-style options. It is 277 possible to use RFC3118 in conjunction with the protocol described in 278 this draft. Indeed, the draft suggests the possibility of 279 bootstrapping the RFC3118 authentication key using the DHCP/EAP 280 protocol. The use cases for that extension are hard to evaluate, so 281 it seems that this draft is neutral toward other DHCP security 282 mechanisms, with one small caveat: since it increases the DHCP 283 message size, it is competing for space in the DHCP packet with other 284 authentication options. 286 10. References 288 10.1. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 10.2. Informative References 295 [I-D.narten-iana-considerations-rfc2434bis] 296 Narten, T. and H. Alvestrand, "Guidelines for Writing an 297 IANA Considerations Section in RFCs", 298 draft-narten-iana-considerations-rfc2434bis-09 (work in 299 progress), March 2008. 301 [I-D.pruss-dhcp-auth-dsl] 302 Pruss, R., Zorn, G., Maglione, R., and Y. Li, 303 "Authentication Extensions for the Dynamic Host 304 Configuration Protocol", May 2008. 306 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 307 March 1997. 309 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 310 Extensions", March 1997. 312 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 313 and M. Carney, "Dynamic Host Configuration Protocol for 314 IPv6 (DHCPv6)", July 2003. 316 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 317 Dynamic Host Configuration Protocol", November 2002. 319 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 320 Text on Security Considerations", BCP 72, RFC 3552, 321 July 2003. 323 Authors' Addresses 325 John Jason Brzozowski 326 Comcast Cable Communications 327 1360 Goshen Parkway 328 West Chester, PA 19473 329 USA 331 Phone: +1-609-377-6594 332 Email: john_brzozowski@cable.comcast.com 334 Ted Lemon 335 Nominum 336 USA 338 Phone: 339 Email: mellon@nominum.com 340 Geoffrey Holan 341 Telus 342 Canada 344 Phone: 345 Email: geoffrey.holan@telus.com