idnits 2.17.1 draft-xu-dhc-authen-00.txt: -(348): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 95 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 IETF Trust and authors Copyright Line does not match the current year -- The document date (June 4, 2021) is 1029 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) == Missing Reference: 'RFC 3118' is mentioned on line 313, but not defined == Missing Reference: 'RFC3118' is mentioned on line 207, but not defined == Unused Reference: 'RFC2119' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 342, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 351, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 357, but no explicit reference was found in the text -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Y. Xu 3 W. Hao 4 J. Xie 5 Internet Draft Huawei Technologies 6 Expires: December 2021 June 4, 2021 8 Account based authentication for DHCP 9 draft-xu-dhc-authen-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on December 4, 2021. 34 Abstract 36 This document describes the mutual authentication between DHCP 37 server and DHCP client based on account information to mitigate the 38 security risk caused by rogue DHCP server, and the problem of 39 illegal DHCP client exhausting DHCP server address. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC-2119 [1]. 47 This document uses the terms "DHCP server" (or "server") and "DHCP 48 client" (or "client") as defined in RFC-2131 [2]. The term "DHCP 49 relay agent" refers to a "BOOTP relay agent" as defined in RFC-2131 50 [2]. 52 Table of Contents 54 1. Introduction ................................................ 3 55 2. Format of new options........................................ 3 56 2.1. User Name Option........................................ 3 57 2.2. Authentication Information Option....................... 3 58 2.2.1. Algorithm ......................................... 4 59 3. Two Keys .................................................... 5 60 3.1. Account key ............................................ 5 61 3.2. Share key .............................................. 5 62 4. Client side processing....................................... 5 63 4.1. INIT state ............................................. 5 64 4.2. INIT-REBOOT state....................................... 6 65 4.3. RENEWING state ......................................... 6 66 4.4. REBINDING state......................................... 6 67 4.5. DHCPINFORM message...................................... 6 68 4.6. DHCPRELEASE message..................................... 6 69 4.7. General considerations.................................. 6 70 5. Server considerations........................................ 7 71 5.1. General considerations.................................. 7 72 5.2. After receiving a DHCPDISCOVER message.................. 7 73 5.3. After receiving a DHCPREQUEST message................... 7 74 5.4. After receiving a DHCPINFORM message.................... 7 75 6. Security Considerations...................................... 7 76 7. IANA Considerations ......................................... 8 77 8. Acknowledgments ............................................. 8 78 8.1. Normative References.................................... 9 79 8.2. Informative References.................................. 9 80 Author's Addresses ............................................. 9 81 Copyright, Disclaimer, and Additional IPR Provisions........... 10 83 1. Introduction 85 This document describes the mutual authentication between DHCP 86 server and DHCP client based on account information like username 87 instead of Secret ID that is described in [RFC 3118] section5.2 to 88 mitigate the security risk caused by rogue DHCP server and the 89 problem of exhausting DHCP server address caused by illegal DHCP 90 client. 92 Compared with [RFC 3118], by leveraging username or other account 93 information for authentication, the following advantages could be 94 achieved: 96 1. Facilitate to manage the DHCP Client accounts on the DHCP server. 98 2. Better integrate the authentication process between DHCP server 99 and authentication server using the protocol of Radius, Active 100 Directory, and etc. 102 2. Format of new options 104 2.1. User Name Option 106 The following diagram defines the format of the user name option: 108 0 1 2 3 109 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 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Code | Length | User Name ~ 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 User Name Option 116 code: user name option. 118 length: Length of the 'User Name' field in octets; variable. 120 User Name: the user name of the DHCP Client. 122 2.2. Authentication Information Option 124 Compared with [RFC 3118], the Secret ID is removed in the option and 125 the format of this option will be changed into the following: 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Code | Length | Algorithm | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | RSV | RDM | Replay Detection(64bits) ~ 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Replay Detection cont. ~ 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 ~ ... | Authentication Information ~ 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Authentication Information Option 141 Code: authentication Information option. 143 Length: The length field includes the lengths of the algorithm, the 144 RSV, the RDM, the Replay Detection, the Replay Detection cont, the 145 Authentication information fields in octets. 147 Algorithm: The Algorithm field defines the algorithm used to 148 generate the authentication information. 150 RSV: Four bits are reserved for future use. These bits SHOULD be 151 set to zero and MUST NOT be used when the option is processed. 153 RDM: The Replay Detection Method field defines the method used to 154 generate the Replay Detection Data. 156 Replay Detection: The Replay Detection field contains a value used 157 to detect replayed messages, which are interpreted according to the 158 RDM. Four bits. 160 Authentication Information: The Authentication Information field is 161 usually a digest of the data in the DHCP packet and is computed 162 using the HASH method that is specified through the Algorithm field. 164 2.2.1. Algorithm 166 Algorithm 1 is assigned to the HMAC protocol by using the SHA-256 167 [3] hash function. 169 All implementations MUST support Algorithm 1, the HMAC-SHA256[3] 170 algorithm. New separate algorithm number could be specified for the 171 future use of a different HASH technique. 173 3. Two Keys 175 3.1. Account key 177 For the interaction between the DHCP server and the fixed DHCP 178 client, the key used is configured based on the user name on the 179 DHCP server, and the DHCP client configures the same user name and 180 key. This key is used to calculate authentication information for 181 all messages of DHCP client no matter the message is unicast, 182 broadcast or multicast, while for the DHCP server only the unicast 183 message to the client needs to be authenticated based on the key. 185 3.2. Share key 187 For the non-unicast messages sent by DHCP server to non-specific 188 clients, the shared key is used. DHCP server and DHCP client MUST 189 configure the same share key. 191 4. Client side processing 193 Similar to the authentication behavior defined in [RFC 3118], the 194 authentication behavior of a DHCP client based on account 195 information is described as below: 197 4.1. INIT state 199 When in INIT state, the client uses Account authentication as 200 follows: 202 1. The client MUST include the User Name option and Authentication 203 Information option in its DHCPDISCOVER message along with a client 204 identifier option [5] to identify itself uniquely to the server. 206 2. The client MUST perform the Message validation described in 207 [RFC3118] on any DHCPOFFER messages that include authentication 208 information. If one or more DHCPOFFER messages pass the validation, 209 the client chooses one of the offered DHCP server. If no DHCPOFFER 210 messages include authentication information or pass the validation 211 test, the processing of the client is the same as that of not 212 receiving DHCPOFFER. 214 3. The client replies with a DHCPREQUEST message that MUST include 215 the user name option and authentication information option. 217 4. If the client authenticated the DHCPOFFER it accepted, the client 218 MUST validate the DHCPACK message from the server. The client MUST 219 discard the DHCPACK if the message fails to pass validation and MAY 220 log the validation failure. If the DHCPACK fails to pass 221 validation, the client MUST revert to INIT state and returns to step 222 1. If the client accepted a DHCPOFFER message that did not include 223 authentication information or did not pass the validation test, the 224 client MAY accept an unauthenticated DHCPACK message from the 225 server. 227 4.2. INIT-REBOOT state 229 When in INIT-REBOOT state, the client MUST include the user name 230 option and authentication information option in its DHCPREQUEST 231 message. 233 4.3. RENEWING state 235 When in RENEWING state, the client MUST include the user name option 236 and authentication information option in its DHCPREQUEST message. 238 4.4. REBINDING state 240 When in REBINDING state, the client MUST include the user name 241 option and authentication information option in its DHCPREQUEST 242 message. 244 4.5. DHCPINFORM message 246 The client MUST include the user name option and authentication 247 information option in its DHCPREQUEST message. 249 4.6. DHCPRELEASE message 251 The client MUST include the user name option and authentication 252 information option in its DHCPREQUEST message. 254 4.7. General considerations 256 Both the user name option and authentication information option must 257 be carried in all the messages sent by the DHCP client to the 258 server. 260 If there is only a user name without a password or only a password 261 without a user name, the user name option and authentication 262 information option are not carried, and the received message is not 263 verified. 265 When the client receives a broadcast or multicast message, the 266 client uses server share key as specified in section 3 to compute 267 authentication information. If no share key is configured locally in 268 the client side, the authentication phase should be skipped. 270 5. Server considerations 272 Similar to the authentication behavior defined in [RFC 3118], the 273 authentication behavior of a DHCP server based on account 274 information is described as below: 276 5.1. General considerations 278 1. Each DHCP server maintains a list of account keys for each DHCP 279 client. 281 2. The unicast message sent by the DHCP server to a specific 282 client uses the account key of the client. If there is no account 283 key, there is no need to encapsulate the authentication information 284 option. If it is a broadcast and multicast message sent to a non- 285 specific client, the server's share key should be used. If there is 286 no share key, there is no need to further encapsulate the 287 authentication information option. 289 5.2. After receiving a DHCPDISCOVER message 291 When the server receives a DHCP DISCOVER message from the client, 292 firstly it finds the corresponding key according to the user name 293 option, then computes the authentication information based on the 294 key, and finally get the validation result for the message. If the 295 message is legal, it will respond to DHCPOFFER message and use the 296 same key to computes authentication information. 298 5.3. After receiving a DHCPREQUEST message 300 Compared with [RFC 3118] message validation process, the only 301 difference is that the server should validate the message based on 302 user name instead of secret ID. 304 5.4. After receiving a DHCPINFORM message 306 If the message fails to pass validation or the server did not get 307 the key corresponding to the user name, the server MUST discard the 308 message and MAY choose to log the validation failure. 310 6. Security Considerations 312 No additional security Considerations are introduced here besides 313 the corresponding description that is defined in [RFC 3118], it only 314 provides an alternative DHCP authentication method to alleviate the 315 security risk of server counterfeiting, illegal client attack and 316 exhaustion of server address could be alleviated. 318 7. IANA Considerations 320 Two new number spaces for the Authentication information option's 321 'Algorithm' and 'Replay Detection Method' fields need to be newly 322 introduced. 324 8. Acknowledgments 326 The authors wish to acknowledge the important contributions of 327 Zengke Wei and Jian Wang. 329 References 331 8.1. Normative References 333 [1] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 337 March 1997. 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, March 1997. 342 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 343 Syntax Specifications: ABNF", RFC 2234, Internet Mail 344 Consortium and Demon Internet Ltd., November 1997. 346 8.2. Informative References 348 [3] R. Droms, W. Arbaugh, “Authentication for DHCP Messages”, RFC 349 3118, June 2001 351 [4] National Institute of Standards and Technology, "Secure Hash 352 Standard", FIPS PUB 180-2, August 2002. 354 [5] Patrick, M., "DHCP Relay Agent Information Option", RFC 355 3046,January 2001. 357 [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 358 Extensions", RFC 2132, March 1997. 360 Author's Addresses 362 Yibin Xu 363 Huawei Technologies 364 101 Software Avenue, 365 Nanjing 210012 China 367 Email: xuyibin@huawei.com 369 Weiguo Hao 370 Huawei Technologies 371 101 Software Avenue, 372 Nanjing 210012 China 374 Email: haoweiguo@huawei.com 376 Jianping Xie 377 Huawei Technologies 378 101 Software Avenue, 379 Nanjing 210012 China 381 Email: xiejianping@huawei.com 383 Copyright, Disclaimer, and Additional IPR Provisions 385 Copyright (c) 2021 IETF Trust and the persons identified as the 386 document authors. All rights reserved. 388 This document is subject to BCP 78 and the IETF Trust's Legal 389 Provisions Relating to IETF Documents 390 (http://trustee.ietf.org/license-info) in effect on the date of 391 publication of this document. Please review these documents 392 carefully, as they describe your rights and restrictions with 393 respect to this document. Code Components extracted from this 394 document must include Simplified BSD License text as described in 395 Section 4.e of the Trust Legal Provisions and are provided without 396 warranty as described in the Simplified BSD License.