idnits 2.17.1 draft-ietf-dhc-forcerenew-nonce-03.txt: 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: ---------------------------------------------------------------------------- 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 (December 21, 2011) is 4502 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 softwire D. Miles 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track W. Dec 5 Expires: June 23, 2012 Cisco Systems 6 J. Bristow 7 Swisscom Schweiz AG 8 R. Maglione 9 Telecom Italia 10 December 21, 2011 12 Forcerenew Nonce Authentication 13 draft-ietf-dhc-forcerenew-nonce-03 15 Abstract 17 DHCP Forcerenew allows for the reconfiguration of a single host by 18 forcing the DHCP client into a Renew state on a trigger from the DHCP 19 server. In Forcerenew Nonce Authentication the server sends a nonce 20 with the client on the initial DHCP ACK that is used for subsequent 21 validation of a Forcerenew message. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 23, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Message authentication . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Forcerenew Nonce Authentication . . . . . . . . . . . . . 3 61 3.1.1. Forcerenew Nonce Protocol Capability Option . . . . . 4 62 3.1.2. Forcerenew Nonce Protocol . . . . . . . . . . . . . . 6 63 3.1.3. Server considerations for Forcerenew Nonce 64 Authentication . . . . . . . . . . . . . . . . . . . . 7 65 3.1.4. Client considerations for Forcerenew Nonce 66 Authentication . . . . . . . . . . . . . . . . . . . . 8 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 6.1. Protocol vulnerabilities . . . . . . . . . . . . . . . . . 9 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 The DHCP Reconfigure Extension defined in [RFC3203] is a useful 79 mechanism allowing dynamic reconfiguration of a single host triggered 80 by the DHCP server. Its application is currently limited by a 81 requirement that FORCERENEW message is always authenticated using 82 procedures as described in [RFC3118]. Authentication for DHCP 83 [RFC3118] is mandatory for Forcerenew, however as it is currently 84 defined [RFC3118] requires distribution of constant token or shared- 85 secret out-of-band to DHCP clients. The mandatory authentication was 86 originally motivated by a legitimate security concern whereby in some 87 network environments a FORCERENEW message can be spoofed. However, 88 in some networks native security mechanisms already provide 89 sufficient protection against spoofing of DHCP traffic. An example 90 of such network is a Broadband Forum TR-101 [TR-101i2] compliant 91 access network. In such environments the mandatory coupling between 92 FORCERENEW and DHCP Authentication [RFC3118] can be relaxed. This 93 document defines extensions to Authentication for DHCP(v4) Messages 94 [RFC3118] to create a new authentication protocol for DHCPv4 95 Forcerenew [RFC3203] messages; this method does not require out-of- 96 band key distribution to DHCP clients. The Forcerenew Nonce is 97 exchanged between server and client on initial DHCP ACK and is used 98 for verification of any subsequent Forcerenew message. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Message authentication 108 The FORCERENEW message must be authenticated using either [RFC3118] 109 or the proposed Forcerenew Nonce Authentication protocol. 111 3.1. Forcerenew Nonce Authentication 113 The Forcerenew nonce authentication protocol provides protection 114 against misconfiguration of a client caused by a Forcerenew message 115 sent by a malicious DHCP server. In this protocol, a DHCP server 116 sends a Forcerenew nonce to the client in the initial exchange of 117 DHCP messages. The client records the Forcerenew nonce for use in 118 authenticating subsequent Forcerenew messages from that server. The 119 server then includes an HMAC computed from the Forcerenew nonce in 120 subsequent Forcerenew messages. 122 Both the Forcerenew nonce sent from the server to the client and the 123 HMAC in subsequent Forcerenew messages are carried as the 124 Authentication information in a DHCP Authentication option. The 125 format of the Authentication information is defined in the following 126 section. 128 The Forcerenew nonce protocol is used (initiated by the server) only 129 if the client and server are not using any other authentication 130 protocol and the client and server have negotiated to use the 131 Forcerenew Nonce Authentication protocol. 133 3.1.1. Forcerenew Nonce Protocol Capability Option 135 A DHCP client indicates DHCP Forcerenew Nonce Protocol capability by 136 including a FORCERENEW_NONCE_CAPABLE() option in DHCP Discover 137 and Request messages sent to the server. 139 A DHCP server that does not support Forcerenew Nonce Protocol 140 authentication should ignore the FORCERENEW_NONCE_CAPABLE() 141 option. A DHCP server indicates DHCP Forcerenew Nonce Protocol 142 preference by including a FORCERENEW_NONCE_CAPABLE() option in 143 any DHCP Offer messages sent to the client. 145 A DHCP client MUST NOT send DHCP messages with authentication options 146 where the protocol value is Forcerenew Nonce Authentication(). 148 The FORCERENEW_NONCE_CAPABLE option is a zero length option with code 149 of and format as follows: 151 Code Len 152 +-----+-----+ 153 | TBD | 0 | 154 +-----+-----+ 156 The client would indicate that it supports the functionality by 157 inserting the FORCERENEW_NONCE_CAPABLE option in the DHCP Discover 158 and Request messages. If the server supports Forcerenew nonce 159 authentication and is configured to require Forcerenew nonce 160 authentication, it will insert the FORCERENEW_NONCE_CAPABLE option in 161 the DHCP Offer message. 163 Server Client Server 164 (not selected) (selected) 166 v v v 167 | | | 168 | Begins initialization | 169 | | | 170 | _____________/|\____________ | 171 |/DHCPDISCOVER | DHCPDISCOVER \| 172 | w/Forcerenew- | w/Forcerenew- | 173 | Nonce-Capable | Nonce-Capable | 174 | | | 175 Determines | Determines 176 configuration | configuration 177 | | | 178 |\ | /| 179 | \__________ | _________/ | 180 | DHCPOFFER \ | /DHCPOFFER | 181 |w/Forcerenew \ | /w/Forcerenew| 182 |Nonce-Capable \| /Nonce-Capable| 183 | | | 184 | Collects replies | 185 | | | 186 | Selects configuration | 187 | | | 188 | _____________/|\____________ | 189 |/ DHCPREQUEST | DHCPREQUEST\ | 190 | w/Forcerenew- | w/Forcerenew- | 191 | Nonce-Capable | Nonce-Capable | 192 | | | 193 | | Commits configuration 194 | | | 195 | |Creates 128-bit Forcerenew Nonce 196 | | | 197 | | _____________/| 198 | |/ DHCPACK | 199 | | w/Auth-Proto= | 200 | | Forcerenew- | 201 | | Nonce | 202 | | | 203 |Client stores Forcerenew Nonce | 204 | | | 205 | Initialization complete | 206 | | | 207 . . . 208 . . . 209 | | | 210 | Forcerenew | 211 | | _____________/| 212 | |/ DHCPFORCE | 213 | | w/Auth-Proto= | 214 | | Forcerenew- | 215 | | Digest(HMAC)| 216 | | | 217 | Client checks HMAC digest | 218 | using stored Forcerenew Nonce | 219 | | | 220 | |\____________ | 221 | | DHCPREQUEST\ | 222 | | w/Forcerenew- | 223 | | Nonce-Capable | 224 | | | 225 | | Commits configuration 226 | | | 227 | |Creates 128-bit Forcerenew Nonce 228 | | | 229 | | _____________/| 230 | |/ DHCPACK | 231 | | w/Auth-Proto= | 232 | | Forcerenew- | 233 | | Nonce | 234 | | | 235 | | | 236 | | | 237 . . . 238 . . . 239 | | | 240 | Graceful shutdown | 241 | | | 242 | |\ ____________ | 243 | | DHCPRELEASE \| 244 | | | 245 | | Discards lease 246 | | | 247 v v v 249 3.1.2. Forcerenew Nonce Protocol 251 The Forcerenew Nonce Protocol makes use of both the DHCP 252 authentication option defined in [RFC3118] re-using the option format 253 and of the Reconfigure Key Authentication Protocol defined in 254 [RFC3315]. 256 The following fields are set in an DHCP authentication option for the 257 Forcerenew Nonce Authentication Protocol: 259 protocol 3 260 algorithm 1 262 RDM 0 264 The format of the Authentication information for the Forcerenew Nonce 265 Authentication Protocol is: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type | Value (128 bits) | 271 +-+-+-+-+-+-+-+-+ | 272 . . 273 . . 274 . +-+-+-+-+-+-+-+-+ 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Type Type of data in Value field carried in this option: 280 1 Reconfigure Key value (used in ACK message) 282 2 HMAC-MD5 digest of the message (FORCERENEW message) 284 Value Data as defined by field 286 3.1.3. Server considerations for Forcerenew Nonce Authentication 288 The use of Forcerenew Nonce Protocol is dependent on the client 289 indicating its capability through the FORCERENEW_NONCE_CAPABLE() 290 DHCP option in any DHCP Discover or Request messages. The DHCP 291 Discovery or Request message from the client MUST contain the 292 FORCERENEW_NONCE_CAPABLE() option if the Forcerenew Nonce 293 Protocol is to be used by the server. The absence of the 294 FORCERENEW_NONCE_CAPABLE() option indicates to the server that 295 the Forcerenew Nonce Authentication protocol is not supported and 296 thus the server MUST NOT include a Forcerenew Nonce Protocol 297 Authentication option in the DHCP Ack. 299 The server indicates its support of the Forcerenew Nonce Protocol 300 authentication by including the DHCP FORCERENEW_NONCE_CAPABLE() 301 option in the DHCP Offer message. The server SHOULD NOT include this 302 option unless the client has indicated its capability in a DHCP 303 Discovery message . The presence of the 304 FORCERENEW_NONCE_CAPABLE() option in the DHCP offer may be used 305 by clients to prefer Forcerenew nonce Protocol authentication-capable 306 DHCP servers over those servers which do not support such capability. 308 The server selects a Forcerenew nonce for a client only during 309 Request/Ack message exchange. The server records the Forcerenew 310 nonce and transmits that nonce to the client in an Authentication 311 option in the DHCP Ack message. 313 The Forcerenew nonce is 128 bits long, and MUST be a 314 cryptographically strong random or pseudo-random number that cannot 315 easily be predicted. The nonce is imbedded as a 128-bit value of the 316 Authentication information where type is set to 1 (Forcerenew nonce 317 Value). 319 To provide authentication for a Forcerenew message, the server 320 selects a replay detection value according to the RDM selected by the 321 server, and computes an HMAC-MD5 of the Forcerenew message using the 322 Forcerenew nonce for the client. The server computes the HMAC-MD5 323 over the entire DHCP Forcerenew message, including the Authentication 324 option; the HMAC-MD5 field in the Authentication option is set to 325 zero for the HMAC-MD5 computation. The server includes the HMAC-MD5 326 in the authentication information field in an Authentication option 327 included in the Forcerenew message sent to the client with type set 328 to 2 (HMAC-MD5 digest). 330 3.1.4. Client considerations for Forcerenew Nonce Authentication 332 The client MUST indicate Forcerenew nonce Capability by including the 333 FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all 334 DHCP Discover and Request messages. DHCP servers that support 335 Forcerenew nonce Protocol authentication MUST include the DHCP 336 Forcerenew Nonce protocol authentication option in DHCP Offers with 337 type set to zero(0), allowing the client to use this capability in 338 selecting DHCP servers should multiple Offers arrive. 340 A DHCP server has indicates its support through the inclusion of the 341 FORCERENEW_NONCE_CAPABLE() option in the DHCP Offer. The client 342 MUST validate the DHCP Ack message contains a Forcerenew Nonce in a 343 DHCP authentication option. If the server has indicated capability 344 for Forcerenew Nonce Protocol authentication in the DHCP Offer and a 345 subsequent Ack omits a valid DHCP authentication option for the 346 Forcerenew Nonce Protocol, the client MUST send a DHCP Decline 347 message and return to the DHCP Init state. 349 The client will receive a Forcerenew Nonce from the server in the 350 initial DHCP Ack message from the server. The client records the 351 Forcerenew Nonce for use in authenticating subsequent Forcerenew 352 messages. 354 To authenticate a Forcerenew message, the client computes an HMAC-MD5 355 over the DHCP Forcerenew message, using the Forcerenew Nonce received 356 from the server. If this computed HMAC-MD5 matches the value in the 357 Authentication option, the client accepts the Forcerenew message. 359 4. Acknowledgements 361 Comments are solicited and should be addressed to the DHC WG mailing 362 list (dhcwg@ietf.org) and/or the authors. This contribution is based 363 on work by Vitali Vinokour. Major sections of this draft use 364 modified text from [RFC3315]. The authors wish to thank Ted Lemon 365 and Bernie Volz for their support. 367 5. IANA Considerations 369 This document requests IANA to assign the following new DHCPv4 option 370 code from the registry "BOOTP Vendor Extensions and DHCP Options" 371 maintained at http://www.iana.org/assignments/bootp-dhcp-parameters: 373 an option code of TBD1 for FORCERENEW_NONCE_CAPABALE 375 6. Security Considerations 377 As in some network environments FORCERENEW can be used to snoop and 378 spoof traffic, the FORCERENEW message MUST be authenticated using the 379 procedures as described in [RFC3118] or this proposal. In this 380 proposal any party able intercept the nonce exchange could 381 impersonate a server and thus offers no protection from man-in-the- 382 middle attacks. FORCERENEW messages failing the authentication 383 should be silently discarded by the client. 385 6.1. Protocol vulnerabilities 387 The mechanism described in this document is vulnerable to a denial of 388 service attack through flooding a client with bogus FORCERENEW 389 messages. The calculations involved in authenticating the bogus 390 FORECERENEW messages may overwhelm the device on which the client is 391 running. 393 The mechanism described provides protection against the use of a 394 FORCERENEW message by a malicious DHCP server to mount a denial of 395 service or man-in-the-middle attack on a client. This protocol can 396 be compromised by an attacker that can intercept the initial message 397 in which the DHCP server sends the nonce to the client. 399 7. References 400 7.1. Normative References 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, March 1997. 405 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 406 Messages", RFC 3118, June 2001. 408 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 409 reconfigure extension", RFC 3203, December 2001. 411 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 412 and M. Carney, "Dynamic Host Configuration Protocol for 413 IPv6 (DHCPv6)", RFC 3315, July 2003. 415 7.2. Informative References 417 [TR-101i2] 418 Anschutz, T., "Migration to Ethernet-Based Broadband 419 Aggregation Broadband Forum TR-101 Issue 2", July 2011. 421 Authors' Addresses 423 David Miles 424 Alcatel-Lucent 425 L3 / 215 Spring St 426 Melbourne, Victoria 3000, 427 Australia 429 Phone: +61 3 9664 3308 430 Fax: 431 Email: david.miles@alcatel-lucent.com 432 URI: 434 Wojciech Dec 435 Cisco Systems 436 Haarlerbergpark Haarlerbergweg 13-19 437 Amsterdam, NOORD-HOLLAND 1101 CH 438 Netherlands 440 Phone: 441 Fax: 442 Email: wdec@cisco.com 443 URI: 445 James Bristow 446 Swisscom Schweiz AG 447 Zentweg 9 448 Bern, 3050, 449 Switzerland 451 Phone: 452 Fax: 453 Email: James.Bristow@swisscom.com 454 URI: 456 Roberta Maglione 457 Telecom Italia 458 Via Reiss Romoli 274 459 Torino 10148 460 Italy 462 Phone: 463 Email: roberta.maglione@telecomitalia.it