idnits 2.17.1 draft-ietf-dhc-forcerenew-nonce-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.i 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 (June 3, 2009) is 5440 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 informational reference (is this intentional?): 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 WG D. Miles 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track W. Dec 5 Expires: December 5, 2009 Cisco Systems 6 J. Bristow 7 Swisscom Schweiz AG 8 R. Maglione 9 Telecom Italia 10 June 3, 2009 12 Forcerenew Nonce Authentication 13 draft-ietf-dhc-forcerenew-nonce-00 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 5, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 DHCP Forcerenew allows for the reconfiguration of a single host by 52 forcing the DHCP client into a Renew state on a trigger from the DHCP 53 server. In Forcerenew Nonce Authentication the server exchanges a 54 nonce with the client on the initial DHCP ACK that is used for 55 subsequent validation of a Forcerenew message. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Message authentication . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Forcerenew Nonce Authentication . . . . . . . . . . . . . 3 63 2.1.1. Forcerenew Nonce Protocol Capability Option . . . . . 4 64 2.1.2. Forcerenew Nonce Protocol . . . . . . . . . . . . . . 6 65 2.1.3. Server considerations for Forcerenew Nonce 66 Authentication . . . . . . . . . . . . . . . . . . . . 7 67 2.1.4. Client considerations for Forcerenew Nonce 68 Authentication . . . . . . . . . . . . . . . . . . . . 8 69 3. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 5.1. Protocol vulnerabilities . . . . . . . . . . . . . . . . . 9 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 This document defines extensions to Authentication for DHCP(v4) 81 Messages [RFC3118] to create a new authentication protocol for DHCPv4 82 Forcerenew [RFC3203] messages. Authentication for DHCP [RFC3118] is 83 mandatory for Forcerenew, however as it is currently defined 84 [RFC3118] requires distribution of constant token or shared-secret 85 out-of-band to DHCP clients. The Forcerenew Nonce is exchanged 86 between server and client on initial DHCP ACK and is used for 87 verification of any subsequent Forcerenew message. 89 Forcerenew Nonce Authentication follows the model set forward in 90 DHCPv6 [RFC3315] as the Reconfigure Key Authentication Protocol. 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 2. Message authentication 100 The FORCERENEW message must be authenticated using either [RFC3118] 101 or the proposed Forcerenew Nonce Authentication protocol. 103 2.1. Forcerenew Nonce Authentication 105 The Forcerenew nonce authentication protocol provides protection 106 against misconfiguration of a client caused by a Forcerenew message 107 sent by a malicious DHCP server. In this protocol, a DHCP server 108 sends a Forcerenew nonce to the client in the initial exchange of 109 DHCP messages. The client records the Forcerenew nonce for use in 110 authenticating subsequent Forcerenew messages from that server. The 111 server then includes an HMAC computed from the Forcerenew nonce in 112 subsequent Forcerenew messages. 114 Both the Forcerenew nonce sent from the server to the client and the 115 HMAC in subsequent Forcerenew messages are carried as the 116 Authentication information in a DHCP Authentication option. The 117 format of the Authentication information is defined in the following 118 section. 120 The Forcerenew nonce protocol is used (initiated by the server) only 121 if the client and server are not using any other authentication 122 protocol and the client and server have negotiated to use the 123 Forcerenew Nonce Authentication protocol. 125 2.1.1. Forcerenew Nonce Protocol Capability Option 127 A DHCP client indicates DHCP Forcerenew Nonce Protocol capability by 128 including a FORCERENEW_NONCE_CAPABLE() option in DHCP Discover 129 and Request messages sent to the server. 131 A DHCP server that does not support Forcerenew Nonce Protocol 132 authentication should ignore the FORCERENEW_NONCE_CAPABLE() 133 option. A DHCP server indicates DHCP Forcerenew Nonce Protocol 134 preference by including a FORCERENEW_NONCE_CAPABLE() option in 135 any DHCP Offer messages sent to the client. 137 A DHCP client MUST NOT send DHCP messages with authentication options 138 where the protocol value is Forcerenew Nonce Authentication(). 140 The FORCERENEW_NONCE_CAPABLE option is a zero length option with code 141 of and format as follows: 142 Code Len 143 +-----+-----+ 144 | TBD | 0 | 145 +-----+-----+ 147 The client would indicate that it supports the functionality by 148 inserting the FORCERENEW_NONCE_CAPABLE option in the DHCP Discover 149 and Request messages. If the server supports Forcerenew nonce 150 authentication and is configured to require Forcerenew nonce 151 authentication, it will insert the FORCERENEW_NONCE_CAPABLE option in 152 the DHCP Offer message. 153 Server Client Server 154 (not selected) (selected) 156 v v v 157 | | | 158 | Begins initialization | 159 | | | 160 | _____________/|\____________ | 161 |/DHCPDISCOVER | DHCPDISCOVER \| 162 | w/Forcerenew- | w/Forcerenew- | 163 | Nonce-Capable | Nonce-Capable | 164 | | | 165 Determines | Determines 166 configuration | configuration 167 | | | 168 |\ | /| 169 | \__________ | _________/ | 170 | DHCPOFFER \ | /DHCPOFFER | 171 |w/Forcerenew \ | /w/Forcerenew| 172 |Nonce-Capable \| /Nonce-Capable| 173 | | | 174 | Collects replies | 175 | | | 176 | Selects configuration | 177 | | | 178 | _____________/|\____________ | 179 |/ DHCPREQUEST | DHCPREQUEST\ | 180 | w/Forcerenew- | w/Forcerenew- | 181 | Nonce-Capable | Nonce-Capable | 182 | | | 183 | | Commits configuration 184 | | | 185 | |Creates 128-bit Forcerenew Nonce 186 | | | 187 | | _____________/| 188 | |/ DHCPACK | 189 | | w/Auth-Proto= | 190 | | Forcerenew- | 191 | | Nonce | 192 | | | 193 |Client stores Forcerenew Nonce | 194 | | | 195 | Initialization complete | 196 | | | 197 . . . 198 . . . 199 | | | 200 | Forcerenew | 201 | | _____________/| 202 | |/ DHCPFORCE | 203 | | w/Auth-Proto= | 204 | | Forcerenew- | 205 | | Digest(HMAC)| 206 | | | 207 | Client checks HMAC digest | 208 | using stored Forcerenew Nonce | 209 | | | 210 | |\____________ | 211 | | DHCPREQUEST\ | 212 | | w/Forcerenew- | 213 | | Nonce-Capable | 214 | | | 215 | | Commits configuration 216 | | | 217 | |Creates 128-bit Forcerenew Nonce 218 | | | 219 | | _____________/| 220 | |/ DHCPACK | 221 | | w/Auth-Proto= | 222 | | Forcerenew- | 223 | | Nonce | 224 | | | 225 | | | 226 | | | 227 . . . 228 . . . 229 | | | 230 | Graceful shutdown | 231 | | | 232 | |\ ____________ | 233 | | DHCPRELEASE \| 234 | | | 235 | | Discards lease 236 | | | 237 v v v 239 2.1.2. Forcerenew Nonce Protocol 241 [RFC3118] defined an extensible DHCPv4 authentication option which 242 supports multiple protocols. The Forcerenew Nonce Protocol makes use 243 of the DHCP authentication option defined in [RFC3118] re-using the 244 option format. 246 The following fields are set in an DHCP authentication option for the 247 Forcerenew Nonce Authentication Protocol: 249 protocol 251 algorithm 1 253 RDM 0 255 The format of the Authentication information for the Forcerenew Nonce 256 Authentication Protocol is: 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Value (128 bits) | 262 +-+-+-+-+-+-+-+-+ | 263 . . 264 . . 265 . +-+-+-+-+-+-+-+-+ 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Type Type of data in Value field carried in this option: 271 1 Forcerenew Nonce value (used in ACK message). 273 2 HMAC-MD5 digest of the message (FORCERENEW 274 message). 276 Value Data as defined by field. 278 2.1.3. Server considerations for Forcerenew Nonce Authentication 280 The use of Forcerenew Nonce Protocol is dependent on the client 281 indicating its capability through the FORCERENEW_NONCE_CAPABLE() 282 DHCP option in any DHCP Discover or Request messages. The DHCP 283 Discovery or Request message from the client MUST contain the 284 FORCERENEW_NONCE_CAPABLE() option if the Forcerenew Nonce 285 Protocol is to be used by the server. The absence of the 286 FORCERENEW_NONCE_CAPABLE() option indicates to the server that 287 the Forcerenew Nonce Authentication protocol is not supported and 288 thus the server MUST NOT include a Forcerenew Nonce Protocol 289 Authentication option in the DHCP Ack. 291 The server indicates its support of the Forcerenew Nonce Protocol 292 authentication by including the DHCP FORCERENEW_NONCE_CAPABLE() 293 option in the DHCP Offer message. The server SHOULD NOT include this 294 option unless the client has indicated its capability in a DHCP 295 Discovery message . The presence of the 296 FORCERENEW_NONCE_CAPABLE() option in the DHCP offer may be used 297 by clients to prefer Forcerenew nonce Protocol authentication-capable 298 DHCP servers over those servers which do not support such capability. 300 The server selects a Forcerenew nonce for a client only during 301 Request/Ack message exchange. The server records the Forcerenew 302 nonce and transmits that nonce to the client in an Authentication 303 option in the DHCP Ack message. 305 The Forcerenew nonce is 128 bits long, and MUST be a 306 cryptographically strong random or pseudo-random number that cannot 307 easily be predicted. The nonce is imbedded as a 128-bit value of the 308 Authentication information where type is set to 1 (Forcerenew nonce 309 Value). 311 To provide authentication for a Forcerenew message, the server 312 selects a replay detection value according to the RDM selected by the 313 server, and computes an HMAC-MD5 of the Forcerenew message using the 314 Forcerenew nonce for the client. The server computes the HMAC-MD5 315 over the entire DHCP Forcerenew message, including the Authentication 316 option; the HMAC-MD5 field in the Authentication option is set to 317 zero for the HMAC-MD5 computation. The server includes the HMAC-MD5 318 in the authentication information field in an Authentication option 319 included in the Forcerenew message sent to the client with type set 320 to 2 (HMAC-MD5 digest). 322 2.1.4. Client considerations for Forcerenew Nonce Authentication 324 The client MUST indicate Forcerenew nonce Capability by including the 325 FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all 326 DHCP Discover and Request messages. DHCP servers that support 327 Forcerenew nonce Protocol authentication MUST include the DHCP 328 Forcerenew Nonce protocol authentication option in DHCP Offers with 329 type set to zero(0), allowing the client to use this capability in 330 selecting DHCP servers should multiple Offers arrive. 332 A DHCP server has indicates its support through the inclusion of the 333 FORCERENEW_NONCE_CAPABLE() option in the DHCP Offer. The client 334 MUST validate the DHCP Ack message contains a Forcerenew Nonce in a 335 DHCP authentication option. If the server has indicated capability 336 for Forcerenew Nonce Protocol authentication in the DHCP Offer and a 337 subsequent Ack omits a valid DHCP authentication option for the 338 Forcerenew Nonce Protocol, the client MUST send a DHCP Decline 339 message and return to the DHCP Init state. 341 The client will receive a Forcerenew Nonce from the server in the 342 initial DHCP Ack message from the server. The client records the 343 Forcerenew Nonce for use in authenticating subsequent Forcerenew 344 messages. 346 To authenticate a Forcerenew message, the client computes an HMAC-MD5 347 over the DHCP Forcerenew message, using the Forcerenew Nonce received 348 from the server. If this computed HMAC-MD5 matches the value in the 349 Authentication option, the client accepts the Forcerenew message. 351 3. Contributors 353 Comments are solicited and should be addressed to the DHC WG mailing 354 list (dhcwg@ietf.org) and/or the authors. This contribution is based 355 on work by Vitali Vinokour. Major sections of this draft use 356 modified text from [RFC3315]. The authors wish to thank Ted Lemon 357 and Bernie Volz for their support. 359 4. IANA Considerations 361 This document requests IANA to allocate an option code for the newly 362 defined DHCP option FORCERENEW_NONCE_CAPABALE as described in the 363 text. 365 This document requests IANA to allocate a DHCP Authentication 366 Option(90) protocol number be assigned for Forcerenew Nonce 367 Authentication, per [RFC3118]. 369 This document requests IANA to create a new namespace associated with 370 the Forcerenew Nonce Authentication protocol: algorithm, per 371 [RFC3118]. 373 5. Security Considerations 375 As in some network environments FORCERENEW can be used to snoop and 376 spoof traffic, the FORCERENEW message MUST be authenticated using the 377 procedures as described in [RFC3118] or this proposal. In this 378 proposal any party able intercept the nonce exchange could 379 impersonate a server and thus offers no protection from man-in-the- 380 middle attacks. FORCERENEW messages failing the authentication 381 should be silently discarded by the client. 383 5.1. Protocol vulnerabilities 385 The mechanism described in this document is vulnerable to a denial of 386 service attack through flooding a client with bogus FORCERENEW 387 messages. The calculations involved in authenticating the bogus 388 FORECERENEW messages may overwhelm the device on which the client is 389 running. 391 The mechanism described provides protection against the use of a 392 FORCERENEW message by a malicious DHCP server to mount a denial of 393 service or man-in-the-middle attack on a client. This protocol can 394 be compromised by an attacker that can intercept the initial message 395 in which the DHCP server sends the nonce to the client. 397 6. References 399 6.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", RFC 2119, March 1997. 404 [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP 405 Messages", RFC 3118, June 2001. 407 [RFC3203] T'joens, Y., Hublet, C., and P. De Schrijver, "DHCP 408 reconfigure extension", RFC 3203, December 2001. 410 6.2. Informative References 412 [RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6 413 (DHCPv6)", RFC 3315, July 2003. 415 Authors' Addresses 417 David Miles 418 Alcatel-Lucent 419 L3 / 215 Spring St 420 Melbourne, Victoria 3000 421 Australia 423 Phone: +61 3 9664 3308 424 Email: david.miles@alcatel-lucent.com 426 Wojciech Dec 427 Cisco Systems 428 Haarlerbergpark Haarlerbergweg 13-19 429 Amsterdam, NOORD-HOLLAND 1101 CH 430 Netherlands 432 Phone: 433 Email: wdec@cisco.com 434 James Bristow 435 Swisscom Schweiz AG 436 Zentweg 9 437 Bern, 3050 438 Switzerland 440 Phone: 441 Email: James.Bristow@swisscom.com 443 Roberta Maglione 444 Telecom Italia 445 Via Reiss Romoli 274 446 Torino, 10148 447 Italy 449 Phone: 450 Email: roberta.maglione@telecomitalia.it