idnits 2.17.1 draft-ietf-dhc-forcerenew-nonce-01.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2011) is 4796 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: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: September 11, 2011 Cisco Systems 6 J. Bristow 7 Swisscom Schweiz AG 8 R. Maglione 9 Telecom Italia 10 March 10, 2011 12 Forcerenew Nonce Authentication 13 draft-ietf-dhc-forcerenew-nonce-01 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 exchanges a 20 nonce with the client on the initial DHCP ACK that is used for 21 subsequent 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 September 11, 2011. 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 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 71 3. Message authentication . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Forcerenew Nonce Authentication . . . . . . . . . . . . . 4 73 3.1.1. Forcerenew Nonce Protocol Capability Option . . . . . 5 74 3.1.2. Forcerenew Nonce Protocol . . . . . . . . . . . . . . 7 75 3.1.3. Server considerations for Forcerenew Nonce 76 Authentication . . . . . . . . . . . . . . . . . . . . 8 77 3.1.4. Client considerations for Forcerenew Nonce 78 Authentication . . . . . . . . . . . . . . . . . . . . 9 79 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 6.1. Protocol vulnerabilities . . . . . . . . . . . . . . . . . 10 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 The DHCP Reconfigure Extension defined in [RFC3203] is a useful 91 mechanism allowing dynamic reconfiguration of a single host triggered 92 by the DHCP server. Its application is currently limited by a 93 requirement that FORCERENEW message is always authenticated using 94 procedures as described in [RFC3118]. Authentication for DHCP 95 [RFC3118] is mandatory for Forcerenew, however as it is currently 96 defined [RFC3118] requires distribution of constant token or shared- 97 secret out-of-band to DHCP clients. The mandatory authentication was 98 originally motivated by a legitimate security concern whereby in some 99 network environments a FORCERENEW message can be spoofed. However, 100 in some networks native security mechanisms already provide 101 sufficient protection against spoofing of DHCP traffic. An example 102 of such network is a DSL Forum TR-101 [TR-101] compliant access 103 network. In such environments the mandatory coupling between 104 FORCERENEW and DHCP Authentication [RFC3118] can be relaxed. This 105 document defines extensions to Authentication for DHCP(v4) Messages 106 [RFC3118] to create a new authentication protocol for DHCPv4 107 Forcerenew [RFC3203] messages; this method does not require out-of- 108 band key distribution to DHCP clients. The Forcerenew Nonce is 109 exchanged between server and client on initial DHCP ACK and is used 110 for verification of any subsequent Forcerenew message. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Message authentication 120 The FORCERENEW message must be authenticated using either [RFC3118] 121 or the proposed Forcerenew Nonce Authentication protocol. 123 3.1. Forcerenew Nonce Authentication 125 The Forcerenew nonce authentication protocol provides protection 126 against misconfiguration of a client caused by a Forcerenew message 127 sent by a malicious DHCP server. In this protocol, a DHCP server 128 sends a Forcerenew nonce to the client in the initial exchange of 129 DHCP messages. The client records the Forcerenew nonce for use in 130 authenticating subsequent Forcerenew messages from that server. The 131 server then includes an HMAC computed from the Forcerenew nonce in 132 subsequent Forcerenew messages. 134 Both the Forcerenew nonce sent from the server to the client and the 135 HMAC in subsequent Forcerenew messages are carried as the 136 Authentication information in a DHCP Authentication option. The 137 format of the Authentication information is defined in the following 138 section. 140 The Forcerenew nonce protocol is used (initiated by the server) only 141 if the client and server are not using any other authentication 142 protocol and the client and server have negotiated to use the 143 Forcerenew Nonce Authentication protocol. 145 3.1.1. Forcerenew Nonce Protocol Capability Option 147 A DHCP client indicates DHCP Forcerenew Nonce Protocol capability by 148 including a FORCERENEW_NONCE_CAPABLE() option in DHCP Discover 149 and Request messages sent to the server. 151 A DHCP server that does not support Forcerenew Nonce Protocol 152 authentication should ignore the FORCERENEW_NONCE_CAPABLE() 153 option. A DHCP server indicates DHCP Forcerenew Nonce Protocol 154 preference by including a FORCERENEW_NONCE_CAPABLE() option in 155 any DHCP Offer messages sent to the client. 157 A DHCP client MUST NOT send DHCP messages with authentication options 158 where the protocol value is Forcerenew Nonce Authentication(). 160 The FORCERENEW_NONCE_CAPABLE option is a zero length option with code 161 of and format as follows: 163 Code Len 164 +-----+-----+ 165 | TBD | 0 | 166 +-----+-----+ 168 The client would indicate that it supports the functionality by 169 inserting the FORCERENEW_NONCE_CAPABLE option in the DHCP Discover 170 and Request messages. If the server supports Forcerenew nonce 171 authentication and is configured to require Forcerenew nonce 172 authentication, it will insert the FORCERENEW_NONCE_CAPABLE option in 173 the DHCP Offer message. 175 Server Client Server 176 (not selected) (selected) 178 v v v 179 | | | 180 | Begins initialization | 181 | | | 182 | _____________/|\____________ | 183 |/DHCPDISCOVER | DHCPDISCOVER \| 184 | w/Forcerenew- | w/Forcerenew- | 185 | Nonce-Capable | Nonce-Capable | 186 | | | 187 Determines | Determines 188 configuration | configuration 189 | | | 190 |\ | /| 191 | \__________ | _________/ | 192 | DHCPOFFER \ | /DHCPOFFER | 193 |w/Forcerenew \ | /w/Forcerenew| 194 |Nonce-Capable \| /Nonce-Capable| 195 | | | 196 | Collects replies | 197 | | | 198 | Selects configuration | 199 | | | 200 | _____________/|\____________ | 201 |/ DHCPREQUEST | DHCPREQUEST\ | 202 | w/Forcerenew- | w/Forcerenew- | 203 | Nonce-Capable | Nonce-Capable | 204 | | | 205 | | Commits configuration 206 | | | 207 | |Creates 128-bit Forcerenew Nonce 208 | | | 209 | | _____________/| 210 | |/ DHCPACK | 211 | | w/Auth-Proto= | 212 | | Forcerenew- | 213 | | Nonce | 214 | | | 215 |Client stores Forcerenew Nonce | 216 | | | 217 | Initialization complete | 218 | | | 219 . . . 220 . . . 221 | | | 222 | Forcerenew | 223 | | _____________/| 224 | |/ DHCPFORCE | 225 | | w/Auth-Proto= | 226 | | Forcerenew- | 227 | | Digest(HMAC)| 228 | | | 229 | Client checks HMAC digest | 230 | using stored Forcerenew Nonce | 231 | | | 232 | |\____________ | 233 | | DHCPREQUEST\ | 234 | | w/Forcerenew- | 235 | | Nonce-Capable | 236 | | | 237 | | Commits configuration 238 | | | 239 | |Creates 128-bit Forcerenew Nonce 240 | | | 241 | | _____________/| 242 | |/ DHCPACK | 243 | | w/Auth-Proto= | 244 | | Forcerenew- | 245 | | Nonce | 246 | | | 247 | | | 248 | | | 249 . . . 250 . . . 251 | | | 252 | Graceful shutdown | 253 | | | 254 | |\ ____________ | 255 | | DHCPRELEASE \| 256 | | | 257 | | Discards lease 258 | | | 259 v v v 261 3.1.2. Forcerenew Nonce Protocol 263 [RFC3118] defined an extensible DHCPv4 authentication option which 264 supports multiple protocols. The Forcerenew Nonce Protocol makes use 265 of the DHCP authentication option defined in [RFC3118] re-using the 266 option format. 268 The following fields are set in an DHCP authentication option for the 269 Forcerenew Nonce Authentication Protocol: 271 protocol 272 algorithm 1 274 RDM 0 276 The format of the Authentication information for the Forcerenew Nonce 277 Authentication Protocol is: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Type | Value (128 bits) | 283 +-+-+-+-+-+-+-+-+ | 284 . . 285 . . 286 . +-+-+-+-+-+-+-+-+ 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Type Type of data in Value field carried in this option: 292 1 Forcerenew Nonce value (used in ACK message) 294 2 HMAC-MD5 digest of the message (FORCERENEW message) 296 Value Data as defined by field 298 3.1.3. Server considerations for Forcerenew Nonce Authentication 300 The use of Forcerenew Nonce Protocol is dependent on the client 301 indicating its capability through the FORCERENEW_NONCE_CAPABLE() 302 DHCP option in any DHCP Discover or Request messages. The DHCP 303 Discovery or Request message from the client MUST contain the 304 FORCERENEW_NONCE_CAPABLE() option if the Forcerenew Nonce 305 Protocol is to be used by the server. The absence of the 306 FORCERENEW_NONCE_CAPABLE() option indicates to the server that 307 the Forcerenew Nonce Authentication protocol is not supported and 308 thus the server MUST NOT include a Forcerenew Nonce Protocol 309 Authentication option in the DHCP Ack. 311 The server indicates its support of the Forcerenew Nonce Protocol 312 authentication by including the DHCP FORCERENEW_NONCE_CAPABLE() 313 option in the DHCP Offer message. The server SHOULD NOT include this 314 option unless the client has indicated its capability in a DHCP 315 Discovery message . The presence of the 316 FORCERENEW_NONCE_CAPABLE() option in the DHCP offer may be used 317 by clients to prefer Forcerenew nonce Protocol authentication-capable 318 DHCP servers over those servers which do not support such capability. 320 The server selects a Forcerenew nonce for a client only during 321 Request/Ack message exchange. The server records the Forcerenew 322 nonce and transmits that nonce to the client in an Authentication 323 option in the DHCP Ack message. 325 The Forcerenew nonce is 128 bits long, and MUST be a 326 cryptographically strong random or pseudo-random number that cannot 327 easily be predicted. The nonce is imbedded as a 128-bit value of the 328 Authentication information where type is set to 1 (Forcerenew nonce 329 Value). 331 To provide authentication for a Forcerenew message, the server 332 selects a replay detection value according to the RDM selected by the 333 server, and computes an HMAC-MD5 of the Forcerenew message using the 334 Forcerenew nonce for the client. The server computes the HMAC-MD5 335 over the entire DHCP Forcerenew message, including the Authentication 336 option; the HMAC-MD5 field in the Authentication option is set to 337 zero for the HMAC-MD5 computation. The server includes the HMAC-MD5 338 in the authentication information field in an Authentication option 339 included in the Forcerenew message sent to the client with type set 340 to 2 (HMAC-MD5 digest). 342 3.1.4. Client considerations for Forcerenew Nonce Authentication 344 The client MUST indicate Forcerenew nonce Capability by including the 345 FORCERENEW_NONCE_CAPABLE() DHCP option (Section 2.1.1) in all 346 DHCP Discover and Request messages. DHCP servers that support 347 Forcerenew nonce Protocol authentication MUST include the DHCP 348 Forcerenew Nonce protocol authentication option in DHCP Offers with 349 type set to zero(0), allowing the client to use this capability in 350 selecting DHCP servers should multiple Offers arrive. 352 A DHCP server has indicates its support through the inclusion of the 353 FORCERENEW_NONCE_CAPABLE() option in the DHCP Offer. The client 354 MUST validate the DHCP Ack message contains a Forcerenew Nonce in a 355 DHCP authentication option. If the server has indicated capability 356 for Forcerenew Nonce Protocol authentication in the DHCP Offer and a 357 subsequent Ack omits a valid DHCP authentication option for the 358 Forcerenew Nonce Protocol, the client MUST send a DHCP Decline 359 message and return to the DHCP Init state. 361 The client will receive a Forcerenew Nonce from the server in the 362 initial DHCP Ack message from the server. The client records the 363 Forcerenew Nonce for use in authenticating subsequent Forcerenew 364 messages. 366 To authenticate a Forcerenew message, the client computes an HMAC-MD5 367 over the DHCP Forcerenew message, using the Forcerenew Nonce received 368 from the server. If this computed HMAC-MD5 matches the value in the 369 Authentication option, the client accepts the Forcerenew message. 371 4. Acknowledgements 373 Comments are solicited and should be addressed to the DHC WG mailing 374 list (dhcwg@ietf.org) and/or the authors. This contribution is based 375 on work by Vitali Vinokour. Major sections of this draft use 376 modified text from [RFC3315]. The authors wish to thank Ted Lemon 377 and Bernie Volz for their support. 379 5. IANA Considerations 381 This document requests IANA to allocate an option code for the newly 382 defined DHCP option FORCERENEW_NONCE_CAPABALE as described in the 383 text. 385 This document requests IANA to allocate a DHCP Authentication 386 Option(90) protocol number be assigned for Forcerenew Nonce 387 Authentication, per [RFC3118]. 389 This document requests IANA to create a new namespace associated with 390 the Forcerenew Nonce Authentication protocol: algorithm, per 391 [RFC3118]. 393 6. Security Considerations 395 As in some network environments FORCERENEW can be used to snoop and 396 spoof traffic, the FORCERENEW message MUST be authenticated using the 397 procedures as described in [RFC3118] or this proposal. In this 398 proposal any party able intercept the nonce exchange could 399 impersonate a server and thus offers no protection from man-in-the- 400 middle attacks. FORCERENEW messages failing the authentication 401 should be silently discarded by the client. 403 6.1. Protocol vulnerabilities 405 The mechanism described in this document is vulnerable to a denial of 406 service attack through flooding a client with bogus FORCERENEW 407 messages. The calculations involved in authenticating the bogus 408 FORECERENEW messages may overwhelm the device on which the client is 409 running. 411 The mechanism described provides protection against the use of a 412 FORCERENEW message by a malicious DHCP server to mount a denial of 413 service or man-in-the-middle attack on a client. This protocol can 414 be compromised by an attacker that can intercept the initial message 415 in which the DHCP server sends the nonce to the client. 417 7. References 419 7.1. Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 425 Messages", RFC 3118, June 2001. 427 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 428 reconfigure extension", RFC 3203, December 2001. 430 7.2. Informative References 432 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 433 and M. Carney, "Dynamic Host Configuration Protocol for 434 IPv6 (DHCPv6)", RFC 3315, July 2003. 436 [TR-101] Cohen et al, "Architecture & Transport: "Migration to 437 Ethernet Based DSL Aggregation, DSL Forum TR-101", 2005. 439 Authors' Addresses 441 David Miles 442 Alcatel-Lucent 443 L3 / 215 Spring St 444 Melbourne, Victoria 3000, 445 Australia 447 Phone: +61 3 9664 3308 448 Fax: 449 Email: david.miles@alcatel-lucent.com 450 URI: 452 Wojciech Dec 453 Cisco Systems 454 Haarlerbergpark Haarlerbergweg 13-19 455 Amsterdam, NOORD-HOLLAND 1101 CH 456 Netherlands 458 Phone: 459 Fax: 460 Email: wdec@cisco.com 461 URI: 463 James Bristow 464 Swisscom Schweiz AG 465 Zentweg 9 466 Bern, 3050, 467 Switzerland 469 Phone: 470 Fax: 471 Email: James.Bristow@swisscom.com 472 URI: 474 Roberta Maglione 475 Telecom Italia 476 Via Reiss Romoli 274 477 Torino 10148 478 Italy 480 Phone: 481 Email: roberta.maglione@telecomitalia.it