idnits 2.17.1 draft-ietf-dhc-forcerenew-nonce-06.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 (Using the creation date from RFC3203, updated by this document, for RFC5378 checks: 2000-03-03) -- 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 (March 11, 2012) is 4430 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc D. Miles 3 Internet-Draft Google 4 Updates: 3203 (if approved) W. Dec 5 Intended status: Standards Track Cisco Systems 6 Expires: September 12, 2012 J. Bristow 7 Swisscom Schweiz AG 8 R. Maglione 9 Telecom Italia 10 March 11, 2012 12 Forcerenew Nonce Authentication 13 draft-ietf-dhc-forcerenew-nonce-06 15 Abstract 17 Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the 18 reconfiguration of a single host by forcing the DHCP client into a 19 Renew state on a trigger from the DHCP server. In Forcerenew Nonce 20 Authentication the server sends a nonce to the client in the initial 21 DHCP ACK that is used for subsequent validation of a FORCERENEW 22 message. This document updates RFC 3203. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 12, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. Message authentication . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Forcerenew Nonce Authentication . . . . . . . . . . . . . 4 62 3.1.1. Forcerenew Nonce Protocol Capability Option . . . . . 4 63 3.1.2. Forcerenew Nonce Protocol . . . . . . . . . . . . . . 6 64 3.1.3. Server considerations for Forcerenew Nonce 65 Authentication . . . . . . . . . . . . . . . . . . . . 8 66 3.1.4. Client considerations for Forcerenew Nonce 67 Authentication . . . . . . . . . . . . . . . . . . . . 9 68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 6.1. Protocol vulnerabilities . . . . . . . . . . . . . . . . . 11 72 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 The DHCP Reconfigure Extension defined in [RFC3203] is a useful 78 mechanism allowing dynamic reconfiguration of a single host triggered 79 by the DHCP server. Its application is currently limited by a 80 requirement that FORCERENEW message is always authenticated using 81 procedures as described in [RFC3118]. Authentication for DHCP 82 [RFC3118] is mandatory for FORCERENEW, however as it is currently 83 defined [RFC3118] requires distribution of constant token or shared- 84 secret out-of-band to DHCP clients. 86 The motivation for making authentication mandatory in DHCP FORCERENEW 87 was to prevent an off-network attacker from taking advantage of DHCP 88 FORCERENEW to accurately predict the timing of a DHCP renewal. 89 Without DHCP FORCERENEW, DHCP renewal timing is under the control of 90 the client, and an off-network attacker has no way of predicting when 91 it will happen, since it doesn't have access to the exchange between 92 the DHCP client and DHCP server. 94 However, the requirement to use the DHCP authentication described in 95 [RFC3118] is more stringent than is required for this use case, and 96 has limited adoption of DHCP FORCERENEW. [RFC3315] defines an 97 authentication protocol using a nonce to prevent off-network 98 attackers from successfully causing clients to renew. Since the off- 99 network attacker doesn't have access to the nonce, it can't trick the 100 client into renewing at a time of its choosing. 102 This document defines extensions to Authentication for DHCPv4 103 Messages [RFC3118] to create a new authentication protocol for DHCPv4 104 FORCERENEW [RFC3203] messages; this method does not require out-of- 105 band key distribution to DHCP clients. The Forcerenew Nonce is 106 exchanged between server and client on initial DHCP ACK and is used 107 for verification of any subsequent FORCERENEW message. This document 108 updates [RFC3203] 110 2. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Message authentication 118 The FORCERENEW message MUST be authenticated using either [RFC3118] 119 or the proposed Forcerenew Nonce Authentication protocol. 121 3.1. Forcerenew Nonce Authentication 123 The Forcerenew nonce authentication protocol provides protection 124 against misconfiguration of a client caused by a FORCERENEW message 125 sent by a malicious DHCP server. In this protocol, a DHCP server 126 sends a Forcerenew nonce to the client in the initial exchange of 127 DHCP messages. The client records the Forcerenew nonce for use in 128 authenticating subsequent Forcerenew messages from that server. The 129 server then includes an HMAC computed from the Forcerenew nonce in 130 subsequent FORCERENEW messages. 132 Both the Forcerenew nonce sent from the server to the client and the 133 HMAC in subsequent FORCERENEW messages are carried as the 134 Authentication information in a DHCP Authentication option. The 135 format of the Authentication information is defined in the following 136 section. 138 The Forcerenew nonce protocol is used (initiated by the server) only 139 if the client and server are not using the authentication mechanism 140 specified in [RFC3118] and the client and server have negotiated to 141 use the Forcerenew Nonce Authentication protocol. 143 3.1.1. Forcerenew Nonce Protocol Capability Option 145 A DHCP client indicates DHCP Forcerenew Nonce Protocol capability by 146 including a FORCERENEW_NONCE_CAPABLE() option in DHCP Discover 147 and Request messages sent to the server. 149 A DHCP server that does not support Forcerenew Nonce Protocol 150 authentication SHOULD ignore the FORCERENEW_NONCE_CAPABLE() 151 option. A DHCP server indicates DHCP Forcerenew Nonce Protocol 152 preference by including a FORCERENEW_NONCE_CAPABLE() option in 153 any DHCP Offer messages sent to the client. 155 A DHCP client MUST NOT send DHCP messages with authentication options 156 where the protocol value is Forcerenew Nonce Authentication(). 158 The FORCERENEW_NONCE_CAPABLE option is a zero length option with code 159 of and format as follows: 161 Code Len 162 +-----+-----+ 163 | TBD | 0 | 164 +-----+-----+ 166 The client would indicate that it supports the functionality by 167 inserting the FORCERENEW_NONCE_CAPABLE option in the DHCP Discover 168 and Request messages. If the server supports Forcerenew nonce 169 authentication and requires Forcerenew nonce authentication, it will 170 insert the FORCERENEW_NONCE_CAPABLE option in the DHCP Offer message. 172 Server Client Server 173 (not selected) (selected) 175 v v v 176 | | | 177 | Begins initialization | 178 | | | 179 | _____________/|\____________ | 180 |/DHCPDISCOVER | DHCPDISCOVER \| 181 | w/Forcerenew- | w/Forcerenew- | 182 | Nonce-Capable | Nonce-Capable | 183 | | | 184 Determines | Determines 185 configuration | configuration 186 | | | 187 |\ | /| 188 | \__________ | _________/ | 189 | DHCPOFFER \ | /DHCPOFFER | 190 |w/Forcerenew \ | /w/Forcerenew| 191 |Nonce-Capable \| /Nonce-Capable| 192 | | | 193 | Collects replies | 194 | | | 195 | Selects configuration | 196 | | | 197 | _____________/|\____________ | 198 |/ DHCPREQUEST | DHCPREQUEST\ | 199 | w/Forcerenew- | w/Forcerenew- | 200 | Nonce-Capable | Nonce-Capable | 201 | | | 202 | | Commits configuration 203 | | | 204 | |Creates 128-bit Forcerenew Nonce 205 | | | 206 | | _____________/| 207 | |/ DHCPACK | 208 | | w/Auth-Proto= | 209 | | Forcerenew- | 210 | | Nonce | 211 | | | 212 |Client stores Forcerenew Nonce | 213 | | | 214 | Initialization complete | 215 | | | 216 . . . 218 . . . 219 | | | 220 | Forcerenew | 221 | | _____________/| 222 | |/ DHCPFORCE | 223 | | w/Auth-Proto= | 224 | | Forcerenew- | 225 | | Digest(HMAC)| 226 | | | 227 | Client checks HMAC digest | 228 | using stored Forcerenew Nonce | 229 | | | 230 | |\____________ | 231 | | DHCPREQUEST\ | 232 | | w/Forcerenew- | 233 | | Nonce-Capable | 234 | | | 235 | | Commits configuration 236 | | | 237 | |Creates 128-bit Forcerenew Nonce 238 | | | 239 | | _____________/| 240 | |/ DHCPACK | 241 | | w/Auth-Proto= | 242 | | Forcerenew- | 243 | | Nonce | 244 | | | 245 | | | 246 | | | 247 . . . 248 . . . 249 | | | 250 | Graceful shutdown | 251 | | | 252 | |\ ____________ | 253 | | DHCPRELEASE \| 254 | | | 255 | | Discards lease 256 | | | 257 v v v 259 3.1.2. Forcerenew Nonce Protocol 261 The Forcerenew Nonce Protocol makes use of both the DHCP 262 authentication option defined in [RFC3118] re-using the option format 263 and of the Reconfigure Key Authentication Protocol defined in 264 [RFC3315]. 266 The following diagram defines the format of the DHCP authentication 267 option: 269 0 1 2 3 270 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Code | Length | Protocol | Algorithm | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | RDM | Replay Detection (64 bits) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Replay cont. | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Replay cont. | | 280 +-+-+-+-+-+-+-+-+ | 281 | | 282 | Authentication Information | 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 The following fields are set in an DHCP authentication option for the 287 Forcerenew Nonce Authentication Protocol: 289 code 90 291 length field contains the length of the protocol 293 protocol 3 295 algorithm 1 297 Replay Detection field is per the Replay Detection Method (RDM) 299 Replay Detection Method (RDM) 0 301 Authentication Information: specified below 303 The format of the Authentication information for the Forcerenew Nonce 304 Authentication Protocol is: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Value (128 bits) | 310 +-+-+-+-+-+-+-+-+ | 311 . . 312 . . 313 . +-+-+-+-+-+-+-+-+ 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Type Type of data in Value field carried in this option: 319 1 Forcerenew nonce Value (used in ACK message) 321 2 HMAC-MD5 digest of the message (FORCERENEW message) 323 Value Data as defined by field 325 3.1.3. Server considerations for Forcerenew Nonce Authentication 327 The use of Forcerenew Nonce Protocol is dependent on the client 328 indicating its capability through the FORCERENEW_NONCE_CAPABLE() 329 DHCP option in any DHCP Discover or Request messages. The DHCP 330 Discovery or Request message from the client MUST contain the 331 FORCERENEW_NONCE_CAPABLE() option if the Forcerenew Nonce 332 Protocol is to be used by the server. The absence of the 333 FORCERENEW_NONCE_CAPABLE() option indicates to the server that 334 the Forcerenew Nonce Authentication protocol is not supported and 335 thus the server MUST NOT include a Forcerenew Nonce Protocol 336 Authentication option in the DHCP Ack. 338 The server indicates its support of the Forcerenew Nonce Protocol 339 authentication by including the DHCP FORCERENEW_NONCE_CAPABLE() 340 option in the DHCP Offer message. The server SHOULD NOT include this 341 option unless the client has indicated its capability in a DHCP 342 Discovery message . The presence of the 343 FORCERENEW_NONCE_CAPABLE() option in the DHCP offer may be used 344 by clients to prefer Forcerenew nonce Protocol authentication-capable 345 DHCP servers over those servers which do not support such capability. 347 If a capable server receives a DISCOVER or REQUEST (any type) that 348 indicates the client is capable, and the server has no previous nonce 349 recorded, it MUST generate a nonce and include it in the ACK. 351 The server selects a Forcerenew nonce for a client only during 352 Request/Ack message exchange. The server records the Forcerenew 353 nonce and transmits that nonce to the client in an Authentication 354 option in the DHCP Ack message. 356 The server SHOULD NOT include the nonce in an ACK when responding to 357 a renew unless a new nonce was generated. This minimizes the number 358 of times the nonce is sent over the wire. 360 If the server to which the DHCP Request message was sent at time T1 361 has not responded, the client enters the REBINDING state and attempts 362 to contact any server. The new Server receiving the DHCP message 363 MUST generate a new nonce. 365 The Forcerenew nonce is 128 bits long, and MUST be a 366 cryptographically strong random or pseudo-random number that cannot 367 easily be predicted. The nonce is embedded as a 128-bit value of the 368 Authentication information where type is set to 1 (Forcerenew nonce 369 Value). 371 To provide authentication for a Forcerenew message, the server 372 selects a replay detection value according to the RDM selected by the 373 server, and computes an HMAC-MD5 of the Forcerenew message, based on 374 the procedure specified in section 21.5 of [RFC3315], using the 375 Forcerenew nonce for the client. The server computes the HMAC-MD5, 376 based on the procedure specified in section 21.5 of [RFC3315], over 377 the entire DHCP Forcerenew message, including the Authentication 378 option; the HMAC-MD5 field in the Authentication option is set to 379 zero for the HMAC-MD5 computation. The server includes the HMAC-MD5 380 in the authentication information field in an Authentication option 381 included in the Forcerenew message sent to the client with type set 382 to 2 (HMAC-MD5 digest). 384 3.1.4. Client considerations for Forcerenew Nonce Authentication 386 A client that supports this mechanism MUST indicate Forcerenew nonce 387 Capability by including the FORCERENEW_NONCE_CAPABLE() DHCP 388 option defined in Section 3.1.1 in all DHCP Discover and Request 389 messages. DHCP servers that support Forcerenew nonce Protocol 390 authentication MUST include the FORCERENEW_NONCE_CAPABLE() DHCP 391 option in all DHCP Offers, allowing the client to use this capability 392 in selecting DHCP servers should multiple Offers arrive. 394 The client MUST validate the DHCP Ack message contains a Forcerenew 395 Nonce in a DHCP authentication option. If the server has indicated 396 capability for Forcerenew Nonce Protocol authentication in the DHCP 397 OFFER and the subsequent ACK received by the client while in the 398 selecting state omits a valid DHCP authentication option for the 399 Forcerenew Nonce Protocol, the client MUST discard the message and 400 return to the INIT stat 401 The client MUST record the Forcerenew Nonce from any valid ACK it 402 receives, if the ACK contains one. 404 To authenticate a Forcerenew message, the client computes an HMAC- 405 MD5, based on the procedure specified in section 21.5 of [RFC3315], 406 over the DHCP FORCERENEW message (after setting the HMAC-MD5 field in 407 the Authentication option to zero), using the Forcerenew Nonce 408 received from the server. If this computed HMAC-MD5 matches the 409 value in the Authentication option, the client accepts the FORCERENEW 410 message. 412 4. Acknowledgements 414 Comments are solicited and should be addressed to the DHC WG mailing 415 list (dhcwg@ietf.org) and/or the authors. This contribution is based 416 on work by Vitali Vinokour. Major sections of this draft use 417 modified text from [RFC3315]. The authors wish to thank Ted Lemon, 418 Matthew Ryan and Bernie Volz for their support. 420 5. IANA Considerations 422 This document requests IANA to assign the following new DHCPv4 option 423 code from the registry "BOOTP Vendor Extensions and DHCP Options" 424 maintained at http://www.iana.org/assignments/bootp-dhcp-parameters: 426 Tag: TBD 428 Name: FORCERENEW_NONCE_CAPABALE 430 Data lenght: 1 432 Description: Forcerenew Nonce Capable 434 Reference: this document 436 6. Security Considerations 438 As in some network environments FORCERENEW can be used to snoop and 439 spoof traffic, the FORCERENEW message MUST be authenticated using the 440 procedures as described in [RFC3118] or the mechanism described in 441 this document. 443 The mechanism in [RFC3315] for DHCPv6, which this document mirrors 444 for DHCPv4, uses a nonce to prevent an off-link attacker from 445 successfully triggering a renewal on a client by sending 446 DHCPFORCERENEW; since the attacker is off-link, it doesn't have the 447 nonce, and can't force a renewal. 449 An on-link attacker can always simply watch the DHCP renewal message 450 go out and respond to it, so this mechanism is useless for preventing 451 on-link attacks, and hence the security of the nonce in the case of 452 on-link attacks isn't relevant. Therefore HMAC-MD5 is by definition 453 adequate for the purpose, and there is no need for an extensible HMAC 454 mechanism. FORCERENEW messages failing the authentication should be 455 silently discarded by the client. 457 6.1. Protocol vulnerabilities 459 The mechanism described in this document is vulnerable to a denial of 460 service attack through flooding a client with bogus FORCERENEW 461 messages. The calculations involved in authenticating the bogus 462 FORECERENEW messages may overwhelm the device on which the client is 463 running. 465 The mechanism described provides protection against the use of a 466 FORCERENEW message by a malicious DHCP server to mount a denial of 467 service or man-in-the-middle attack on a client. This protocol can 468 be compromised by an attacker that can intercept the initial message 469 in which the DHCP server sends the nonce to the client. 471 7. Normative References 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 477 Messages", RFC 3118, June 2001. 479 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 480 reconfigure extension", RFC 3203, December 2001. 482 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 483 and M. Carney, "Dynamic Host Configuration Protocol for 484 IPv6 (DHCPv6)", RFC 3315, July 2003. 486 Authors' Addresses 488 David Miles 489 Google 491 Phone: 492 Fax: 493 Email: 494 URI: 496 Wojciech Dec 497 Cisco Systems 498 Haarlerbergpark Haarlerbergweg 13-19 499 Amsterdam, NOORD-HOLLAND 1101 CH 500 Netherlands 502 Phone: 503 Fax: 504 Email: wdec@cisco.com 505 URI: 507 James Bristow 508 Swisscom Schweiz AG 509 Zentweg 9 510 Bern, 3050, 511 Switzerland 513 Phone: 514 Fax: 515 Email: James.Bristow@swisscom.com 516 URI: 518 Roberta Maglione 519 Telecom Italia 520 Via Reiss Romoli 274 521 Torino 10148 522 Italy 524 Phone: 525 Email: roberta.maglione@telecomitalia.it