idnits 2.17.1 draft-ietf-dhc-forcerenew-nonce-07.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 (June 14, 2012) is 4327 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: December 16, 2012 J. Bristow 7 Swisscom Schweiz AG 8 R. Maglione 9 Telecom Italia 10 June 14, 2012 12 Forcerenew Nonce Authentication 13 draft-ietf-dhc-forcerenew-nonce-07 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 December 16, 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 . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 11 71 6.1. Protocol vulnerabilities . . . . . . . . . . . . . . . . . 11 72 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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 contains code , length n and 159 a sequence of algorithms the client supports: 161 Code Len Algorithms 162 +-----+-----+----+----+----+ 163 | TBD | n | A1 | A2 | A3 | .... 164 +-----+-----+----+----+----+ 166 This document, in section Section 3.1.2, defines the Forcerenew Nonce 167 Protocol for algorithm equal to 1 and type equal to 2; future 168 documents will specify the other values for algorithm !=1 and type 169 !=2, allowing a different algorithm to be used with shorter/longer 170 values. 172 The client would indicate that it supports the functionality by 173 inserting the FORCERENEW_NONCE_CAPABLE option in the DHCP Discover 174 and Request messages. If the server supports Forcerenew nonce 175 authentication and requires Forcerenew nonce authentication, it will 176 insert the FORCERENEW_NONCE_CAPABLE option in the DHCP Offer message. 178 Server Client Server 179 (not selected) (selected) 181 v v v 182 | | | 183 | Begins initialization | 184 | | | 185 | _____________/|\____________ | 186 |/DHCPDISCOVER | DHCPDISCOVER \| 187 | w/Forcerenew- | w/Forcerenew- | 188 | Nonce-Capable | Nonce-Capable | 189 | | | 190 Determines | Determines 191 configuration | configuration 192 | | | 193 |\ | /| 194 | \__________ | _________/ | 195 | DHCPOFFER \ | /DHCPOFFER | 196 |w/Forcerenew \ | /w/Forcerenew| 197 |Nonce-Capable \| /Nonce-Capable| 198 | | | 199 | Collects replies | 200 | | | 201 | Selects configuration | 202 | | | 203 | _____________/|\____________ | 204 |/ DHCPREQUEST | DHCPREQUEST\ | 205 | w/Forcerenew- | w/Forcerenew- | 206 | Nonce-Capable | Nonce-Capable | 207 | | | 208 | | Commits configuration 209 | | | 210 | |Creates 128-bit Forcerenew Nonce 211 | | | 212 | | _____________/| 213 | |/ DHCPACK | 214 | | w/Auth-Proto= | 215 | | Forcerenew- | 216 | | Nonce | 217 | | | 218 |Client stores Forcerenew Nonce | 219 | | | 220 | Initialization complete | 221 | | | 222 . . . 223 . . . 224 | | | 225 | Forcerenew | 226 | | _____________/| 227 | |/ DHCPFORCE | 228 | | w/Auth-Proto= | 229 | | Forcerenew- | 230 | | Digest(HMAC)| 231 | | | 232 | Client checks HMAC digest | 233 | using stored Forcerenew Nonce | 234 | | | 235 | |\____________ | 236 | | DHCPREQUEST\ | 237 | | w/Forcerenew- | 238 | | Nonce-Capable | 239 | | | 240 | | Commits configuration 241 | | | 242 | |Creates 128-bit Forcerenew Nonce 243 | | | 244 | | _____________/| 245 | |/ DHCPACK | 246 | | w/Auth-Proto= | 247 | | Forcerenew- | 248 | | Nonce | 249 | | | 250 | | | 251 | | | 252 . . . 253 . . . 254 | | | 255 | Graceful shutdown | 256 | | | 257 | |\ ____________ | 258 | | DHCPRELEASE \| 259 | | | 260 | | Discards lease 261 | | | 262 v v v 264 3.1.2. Forcerenew Nonce Protocol 266 The Forcerenew Nonce Protocol makes use of both the DHCP 267 authentication option defined in [RFC3118] re-using the option format 268 and of the Reconfigure Key Authentication Protocol defined in 269 [RFC3315]. 271 The following diagram defines the format of the DHCP authentication 272 option: 274 0 1 2 3 275 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Code | Length | Protocol | Algorithm | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | RDM | Replay Detection (64 bits) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Replay cont. | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Replay cont. | | 285 +-+-+-+-+-+-+-+-+ | 286 | | 287 | Authentication Information | 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 The following fields are set in an DHCP authentication option for the 292 Forcerenew Nonce Authentication Protocol: 294 code 90 296 length field contains the length of the protocol 298 protocol 3 300 algorithm 1 302 Replay Detection field is per the Replay Detection Method (RDM) 303 Replay Detection Method (RDM) 0 305 Authentication Information: specified below 307 The format of the Authentication information for the Forcerenew Nonce 308 Authentication Protocol is: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Type | Value (128 bits) | 314 +-+-+-+-+-+-+-+-+ | 315 . . 316 . . 317 . +-+-+-+-+-+-+-+-+ 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Type Type of data in Value field carried in this option: 323 1 Forcerenew nonce Value (used in ACK message) 325 2 HMAC-MD5 digest of the message (FORCERENEW message) 327 Value Data as defined by field 329 3.1.3. Server considerations for Forcerenew Nonce Authentication 331 The use of Forcerenew Nonce Protocol is dependent on the client 332 indicating its capability through the FORCERENEW_NONCE_CAPABLE() 333 DHCP option in any DHCP Discover or Request messages. The DHCP 334 Discovery or Request message from the client MUST contain the 335 FORCERENEW_NONCE_CAPABLE() option if the Forcerenew Nonce 336 Protocol is to be used by the server. The absence of the 337 FORCERENEW_NONCE_CAPABLE() option indicates to the server that 338 the Forcerenew Nonce Authentication protocol is not supported and 339 thus the server MUST NOT include a Forcerenew Nonce Protocol 340 Authentication option in the DHCP Ack. 342 The server indicates its support of the Forcerenew Nonce Protocol 343 authentication by including the DHCP FORCERENEW_NONCE_CAPABLE() 344 option in the DHCP Offer message. The server SHOULD NOT include this 345 option unless the client has indicated its capability in a DHCP 346 Discovery message . The presence of the 347 FORCERENEW_NONCE_CAPABLE() option in the DHCP offer may be used 348 by clients to prefer Forcerenew nonce Protocol authentication-capable 349 DHCP servers over those servers which do not support such capability. 351 If a capable server receives a DISCOVER or REQUEST (any type) that 352 indicates the client is capable, and the server has no previous nonce 353 recorded, it MUST generate a nonce and include it in the ACK. 355 The server selects a Forcerenew nonce for a client only during 356 Request/Ack message exchange. The server records the Forcerenew 357 nonce and transmits that nonce to the client in an Authentication 358 option in the DHCP Ack message. 360 The server SHOULD NOT include the nonce in an ACK when responding to 361 a renew unless a new nonce was generated. This minimizes the number 362 of times the nonce is sent over the wire. 364 If the server to which the DHCP Request message was sent at time T1 365 has not responded, the client enters the REBINDING state and attempts 366 to contact any server. The new Server receiving the DHCP message 367 MUST generate a new nonce. 369 The Forcerenew nonce is 128 bits long, and MUST be a 370 cryptographically strong random or pseudo-random number that cannot 371 easily be predicted. The nonce is embedded as a 128-bit value of the 372 Authentication information where type is set to 1 (Forcerenew nonce 373 Value). 375 To provide authentication for a Forcerenew message, the server 376 selects a replay detection value according to the RDM selected by the 377 server, and computes an HMAC-MD5 of the Forcerenew message, based on 378 the procedure specified in section 21.5 of [RFC3315], using the 379 Forcerenew nonce for the client. The server computes the HMAC-MD5, 380 based on the procedure specified in section 21.5 of [RFC3315], over 381 the entire DHCP Forcerenew message, including the Authentication 382 option; the HMAC-MD5 field in the Authentication option is set to 383 zero for the HMAC-MD5 computation. The server includes the HMAC-MD5 384 in the authentication information field in an Authentication option 385 included in the Forcerenew message sent to the client with type set 386 to 2 (HMAC-MD5 digest). 388 3.1.4. Client considerations for Forcerenew Nonce Authentication 390 A client that supports this mechanism MUST indicate Forcerenew nonce 391 Capability by including the FORCERENEW_NONCE_CAPABLE() DHCP 392 option defined in Section 3.1.1 in all DHCP Discover and Request 393 messages. DHCP servers that support Forcerenew nonce Protocol 394 authentication MUST include the FORCERENEW_NONCE_CAPABLE() DHCP 395 option in all DHCP Offers, allowing the client to use this capability 396 in selecting DHCP servers should multiple Offers arrive. 398 The client MUST validate the DHCP Ack message contains a Forcerenew 399 Nonce in a DHCP authentication option. If the server has indicated 400 capability for Forcerenew Nonce Protocol authentication in the DHCP 401 OFFER and the subsequent ACK received by the client while in the 402 selecting state omits a valid DHCP authentication option for the 403 Forcerenew Nonce Protocol, the client MUST discard the message and 404 return to the INIT stat 406 The client MUST record the Forcerenew Nonce from any valid ACK it 407 receives, if the ACK contains one. 409 To authenticate a Forcerenew message, the client computes an HMAC- 410 MD5, based on the procedure specified in section 21.5 of [RFC3315], 411 over the DHCP FORCERENEW message (after setting the HMAC-MD5 field in 412 the Authentication option to zero), using the Forcerenew Nonce 413 received from the server. If this computed HMAC-MD5 matches the 414 value in the Authentication option, the client accepts the FORCERENEW 415 message. 417 4. Acknowledgements 419 Comments are solicited and should be addressed to the DHC WG mailing 420 list (dhcwg@ietf.org) and/or the authors. This contribution is based 421 on work by Vitali Vinokour. Major sections of this draft use 422 modified text from [RFC3315]. The authors wish to thank Ted Lemon, 423 Matthew Ryan and Bernie Volz for their support. 425 5. IANA Considerations 427 This document requests IANA to assign the following new DHCPv4 option 428 code from the registry "BOOTP Vendor Extensions and DHCP Options" 429 maintained at http://www.iana.org/assignments/bootp-dhcp-parameters: 431 Tag: TBD 433 Name: FORCERENEW_NONCE_CAPABALE 435 Data lenght: 1 437 Description: Forcerenew Nonce Capable 439 Reference: this document 441 6. Security Considerations 443 As in some network environments FORCERENEW can be used to snoop and 444 spoof traffic, the FORCERENEW message MUST be authenticated using the 445 procedures as described in [RFC3118] or the mechanism described in 446 this document. 448 The mechanism in [RFC3315] for DHCPv6, which this document mirrors 449 for DHCPv4, uses a nonce to prevent an off-link attacker from 450 successfully triggering a renewal on a client by sending 451 DHCPFORCERENEW; since the attacker is off-link, it doesn't have the 452 nonce, and can't force a renewal. 454 An on-link attacker can always simply watch the DHCP renewal message 455 go out and respond to it, so this mechanism is useless for preventing 456 on-link attacks, and hence the security of the nonce in the case of 457 on-link attacks isn't relevant. Therefore HMAC-MD5 is by definition 458 adequate for the purpose, and there is no need for an extensible HMAC 459 mechanism. FORCERENEW messages failing the authentication should be 460 silently discarded by the client. 462 6.1. Protocol vulnerabilities 464 The mechanism described in this document is vulnerable to a denial of 465 service attack through flooding a client with bogus FORCERENEW 466 messages. The calculations involved in authenticating the bogus 467 FORECERENEW messages may overwhelm the device on which the client is 468 running. 470 The mechanism described provides protection against the use of a 471 FORCERENEW message by a malicious DHCP server to mount a denial of 472 service or man-in-the-middle attack on a client. This protocol can 473 be compromised by an attacker that can intercept the initial message 474 in which the DHCP server sends the nonce to the client. 476 7. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 482 Messages", RFC 3118, June 2001. 484 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 485 reconfigure extension", RFC 3203, December 2001. 487 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 488 and M. Carney, "Dynamic Host Configuration Protocol for 489 IPv6 (DHCPv6)", RFC 3315, July 2003. 491 Authors' Addresses 493 David Miles 494 Google 496 Phone: 497 Fax: 498 Email: 499 URI: 501 Wojciech Dec 502 Cisco Systems 503 Haarlerbergpark Haarlerbergweg 13-19 504 Amsterdam, NOORD-HOLLAND 1101 CH 505 Netherlands 507 Phone: 508 Fax: 509 Email: wdec@cisco.com 510 URI: 512 James Bristow 513 Swisscom Schweiz AG 514 Zentweg 9 515 Bern, 3050, 516 Switzerland 518 Phone: 519 Fax: 520 Email: James.Bristow@swisscom.com 521 URI: 523 Roberta Maglione 524 Telecom Italia 525 Via Reiss Romoli 274 526 Torino 10148 527 Italy 529 Phone: 530 Email: roberta.maglione@telecomitalia.it