idnits 2.17.1 draft-jiang-dhc-sedhcpv4-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 date (June 24, 2015) is 3227 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) == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-08 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group S. Jiang, Ed. 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Standards Track D. Zhang 5 Expires: December 26, 2015 June 24, 2015 7 Secure DHCPv4 8 draft-jiang-dhc-sedhcpv4-01 10 Abstract 12 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) enables 13 DHCPv4 servers to pass configuration parameters. It offers 14 configuration flexibility. If not being secured, DHCPv4 is 15 vulnerable to various attacks, particularly spoofing attacks. This 16 document analyzes the security issues of DHCPv4 and specifies a 17 Secure DHCPv4 mechanism for communications between DHCPv4 clients and 18 servers. This document provides a DHCPv4 client/server 19 authentication mechanism based on sender's public/private key pairs 20 or certificates with associated private keys. The DHCPv4 message 21 exchanges are protected by the signature option and the timestamp 22 option newly defined in this document. 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 26, 2015. 41 Copyright Notice 43 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language and Terminology . . . . . . . . . . . . 3 60 3. Security Overview of DHCPv4 . . . . . . . . . . . . . . . . . 3 61 4. Overview of Secure DHCPv4 Mechanism with Public Key . . . . . 4 62 4.1. New Components . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Support for Algorithm Agility . . . . . . . . . . . . . . 6 64 4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Extensions for Secure DHCPv4 . . . . . . . . . . . . . . . . 7 66 5.1. Public Key Option . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Certificate Option . . . . . . . . . . . . . . . . . . . 8 68 5.3. Signature Option . . . . . . . . . . . . . . . . . . . . 9 69 5.4. Timestamp Option . . . . . . . . . . . . . . . . . . . . 11 70 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 11 71 6. Processing Rules and Behaviors . . . . . . . . . . . . . . . 12 72 6.1. Processing Rules of Sender . . . . . . . . . . . . . . . 12 73 6.2. Processing Rules of Recipient . . . . . . . . . . . . . . 13 74 6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 16 75 6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 16 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 79 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 20 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 82 11.2. Informative References . . . . . . . . . . . . . . . . . 22 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 85 1. Introduction 87 The Dynamic Host Configuration Protocol version 4 (DHCPv4, [RFC2131]) 88 enables DHCPv4 servers to pass configuration parameters and offers 89 configuration flexibility. If not being secured, DHCPv4 is 90 vulnerable to various attacks, particularly spoofing attacks. 92 This document analyzes the security issues of DHCPv4 in details. 93 This document provides mechanisms for improving the security of 94 DHCPv4 between client and server: 96 o the identity of a DHCPv4 message sender, which can be a DHCPv4 97 server or a client, can be verified by a recipient. 99 o the integrity of DHCPv4 messages can be checked by the recipient 100 of the message. 102 o anti-replay protection based on timestamps. 104 Note: this secure mechanism in this document does not protect the 105 relay-relevant options, either added by a relay agent toward a server 106 or added by a server toward a relay agent, are considered less 107 vulnerable, because they are only transported within operator 108 networks. 110 The security mechanisms specified in this document is based on 111 sender's public/private key pairs or certificates with associated 112 private keys. It also integrates message signatures for the 113 integrity and timestamps for anti-replay. The sender authentication 114 procedure using certificates defined in this document depends on 115 deployed Public Key Infrastructure (PKI, [RFC5280]). However, the 116 deployment of PKI is out of the scope of this document. 118 Secure DHCPv4 is applicable in environments where physical security 119 on the link is not assured (such as over wireless) and attacks on 120 DHCPv4 are a concern. 122 2. Requirements Language and Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 [RFC2119] when they appear in ALL CAPS. When these words are not in 128 ALL CAPS (such as "should" or "Should"), they have their usual 129 English meanings, and are not to be interpreted as [RFC2119] key 130 words. 132 3. Security Overview of DHCPv4 134 DHCPv4 is a client/server protocol that provides managed 135 configuration of devices. It enables a DHCPv4 server to 136 automatically configure relevant network parameters on clients. 138 Although [RFC3118] provide an optional DHCPv4 authentication 139 mechanism. It depends on the client's key that is "initially 140 distributed to the client through some out-of-band mechanism", and 141 "the DHCPv4 server MUST know the keys for all authorized clients", 142 Section 5.4 of [RFC3118]. However, [RFC3118] does not provides no 143 mechanism for distributing the client's key. 145 For the keyed hash function, there are two key management mechanisms. 146 The first one is a key management done out of band, usually through 147 some manual process. The second approach is to use Public Key 148 Infrastructure (PKI). 150 As an example of the first approach, operators can set up a key 151 database for both servers and clients from which the client obtains a 152 key before running DHCPv4. Manual key distribution runs counter to 153 the goal of minimizing the configuration data needed at each host. 155 In comparison, the security mechanism defined in this document allows 156 the public key database on the client or sever to be populated 157 opportunistically or manually, depending on the degree of confidence 158 desired in a specific application. PKI security mechanism is simpler 159 in the local key management respect. 161 4. Overview of Secure DHCPv4 Mechanism with Public Key 163 This document introduces a mechanism that uses public key signatures 164 as a mechanism for securing the DHCPv4 protocol. In order to enable 165 DHCPv4 clients and servers to perform mutual authentication without 166 previous key deployment, this solution provides a DHCPv4 client/ 167 server authentication mechanism based on public/private key pairs 168 and, optionally, PKI certificates. The purpose of this design is to 169 make it easier to deploy DHCPv4 authentication and provides 170 protection of DHCPv4 message within the scope of whatever trust 171 relationship exists for the particular key used to authenticate the 172 message. 174 In this document, we introduce a public key option, a certificate 175 option, a signature option and a timestamp option with corresponding 176 verification mechanisms. A DHCPv4 message can include a public key 177 option, and carrying a digital signature and a timestamp option. The 178 signature can be verified using the supplied public key. The 179 recipient processes the payload of the DHCPv4 message only if the 180 validation is successful: the signature validates, and a trust 181 relationship exists for the key. Alternatively, a DHCPv4 message can 182 include a certificate option, and also carrying a digital signature 183 and a timestamp option. The signature can be verified by the 184 recipient. The recipient processes the payload of the DHCPv4 message 185 only if the validation is successful: the certificate validates, and 186 some trust relationship exists on the recipient for the provided 187 certificate. The end-to-end security protection can be 188 bidirectional, covering messages from servers to clients and from 189 clients to servers. Additionally, the optional timestamp mechanism 190 provides anti-replay protection. 192 A trust relationship for a public key can be the result either of a 193 Trust-on-first-use (TOFU) policy, or a list of trusted keys 194 configured on the recipient. 196 A trust relationship for a certificate could also be treated either 197 as TOFU or configured in a list of trusted certificate authorities, 198 depending on the application. 200 TOFU can be used by a client to authenticate a server and its 201 messages. It can be deployed without a pre-established trust 202 relationship between the client and the server. It can be used for 203 all DHCPv4 messages, and the same single key can be used for all 204 clients since the server does not send a secret in plain text on the 205 wire. Overall this will provide a reasonable balance of easy 206 deployment and moderate level of security, as long as the risk of the 207 attack window on the first use is acceptable. 209 TOFU can also be used by a server to protect an existing DHCPv4 210 session with a particular client by preventing a malicious client 211 from hijacking the session. In this case the server does not even 212 have to store the client's public key or certificate after the 213 session; it only has to remember the public key during that 214 particular session and check if it can verify received messages with 215 that key. This type of authentication can be deployed without a pre- 216 established trust relationship. 218 If authentication has to be provided from the initial use, the Secure 219 DHCPv4 mechanism needs some infrastructure such as PKI so the 220 recipient of a public key or certificate can verify it securely. It 221 is currently a subject of further study how such an infrastructure 222 can be integrated to DHCPv4 in a way it makes the deployment easier. 224 The signature on a Secure DHCPv4 message can be expected to 225 significantly increase the size of the message. One example is 226 normal DHCPv4 message length plus a 1 KB for a X.509 certificate and 227 signature and 256 Byte for a signature. Packet fragments are highly 228 possible. In practise, the total length would be various in a large 229 range. Hence, deployment of Secure DHCPv4 should also consider the 230 issues of IP fragment, PMTU, etc. 232 4.1. New Components 234 The components of the solution specified in this document are as 235 follows: 237 o Servers and clients using public keys in their secure DHCPv4 238 messages generate a public/private key pair. A new DHCPv4 option 239 that carries the public key is defined. 241 o Servers and clients that use certificates first generate a public/ 242 private key pair and then obtain a public key certificate from a 243 Certificate Authority that signs the public key. Another new 244 DHCPv4 option is defined to carry the certificate. 246 o A signature generated using the private key which is used by the 247 receiver to verify the integrity of the DHCPv4 messages and then 248 the identity of the sender. 250 o A timestamp, to detect replayed packet. The secure DHCPv4 nodes 251 need to meet some accuracy requirements and be synced to global 252 time, while the timestamp checking mechanism allows a configurable 253 time value for clock drift. The real time provision is out of 254 scope of this document. 256 4.2. Support for Algorithm Agility 258 Hash functions are used to provide message integrity checks. In 259 order to provide a means of addressing problems that may emerge in 260 the future with existing hash algorithms, as recommended in 261 [RFC4270], this document provides a mechanism for negotiating the use 262 of more secure hashes in the future. 264 In addition to hash algorithm agility, this document also provides a 265 mechanism for signature algorithm agility. 267 The support for algorithm agility in this document is mainly a 268 unilateral notification mechanism from sender to recipient. A 269 recipient MAY support various algorithms simultaneously among 270 different senders, and the different senders in a same administrative 271 domain may be allowed to use various algorithms simultaneously. It 272 is NOT RECOMMENDED that the same sender and recipient use various 273 algorithms in a single communication session. 275 If the recipient does not support the algorithm used by the sender, 276 it cannot authenticate the message. In the client-to-server case, 277 the server SHOULD reply with an AlgorithmNotSupported status code 278 (defined in Section 5.5). Upon receiving this status code, the 279 client MAY resend the message protected with the mandatory algorithm 280 (defined in Section 5.3). 282 4.3. Applicability 284 By default, a secure DHCPv4 enabled client or server SHOULD start 285 with secure mode by sending secure DHCPv4 messages. If the recipient 286 is secure DHCPv4 enabled and the key or certificate authority is 287 trusted by the recipient, then their communication would be in secure 288 mode. In the scenario where the secure DHCPv4 enabled client and 289 server fail to build up secure communication between them, the secure 290 DHCPv4 enabled client MAY choose to send unsecured DHCPv4 message 291 towards the server according to its local policies. 293 In the scenario where the recipient is a legacy DHCPv4 server that 294 does not support secure mechanism, the DHCPv4 server (for all of 295 known DHCPv4 implementations) would just omit or disregard unknown 296 options (secure options defined in this document) and still process 297 the known options. The reply message would be unsecured, of course. 298 It is up to the local policy of the client whether to accept such 299 messages. If the client accepts the unsecured messages from the 300 DHCPv4 server, the subsequent exchanges will be in the unsecured 301 mode. 303 In the scenario where a legacy client sends an unsecured message to a 304 secure DHCPv4 enabled server, there are two possibilities depending 305 on the server policy. If the server's policy requires the 306 authentication, an UnspecFail (value 1, [RFC6926]) error status code, 307 SHOULD be returned. In such case, the client cannot build up the 308 connection with the server. If the server has been configured to 309 support unsecured clients, the server MAY fall back to the unsecured 310 DHCPv4 mode, and reply unsecured messages toward the client; 311 depending on the local policy, the server MAY continue to send the 312 secured reply messages with the consumption of computing resource. 313 The resources allocated for unsecured clients SHOULD be separated and 314 restricted. 316 These are all examples of how interactions can go, but there is 317 nothing to prevent clients from behaving adaptively in response to 318 secure messages from servers. 320 5. Extensions for Secure DHCPv4 322 This section describes the extensions to DHCPv4. Four new options 323 have been defined. The new options MUST be supported in the Secure 324 DHCPv4 message exchange. 326 5.1. Public Key Option 328 The Public Key option carries the public key of the sender. The 329 format of the Public Key option is described as follows: 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | option-code | option-len | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 336 | | 337 . Public Key (variable length) . 338 . . 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 option-code OPTION_PUBLIC_KEY (TBA1). 343 option-len Length of public key in octets. 345 Public Key A variable-length field containing a 346 SubjectPublicKeyInfo object specified in [RFC5280]. 347 The SubjectPublicKeyInfo structure is comprised with 348 a public key and an AlgorithmIdentifier object 349 which is specified in section 4.1.1.2, [RFC5280]. The 350 object identifiers for the supported algorithms and 351 the methods for encoding the public key materials 352 (public key and parameters) are specified in 353 [RFC3279], [RFC4055], and [RFC4491]. 355 Note: when the option exceeds 255 octets in size (the maximum size of 356 a single option), multiple instances of the same option are generated 357 acording to [RFC3396]. And they should be put in sequential order in 358 the same DHCPv4 message. 360 5.2. Certificate Option 362 The Certificate option carries the public key certificate of the 363 client. The format of the Certificate option is described as 364 follows: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | option-code | option-len | | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 371 | | 372 . Certificate (variable length) . 373 . . 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 option-code OPTION_CERTIFICATE (TBA2). 378 option-len Length of certificate in octets. 380 Certificate A variable-length field containing certificate. The 381 encoding of certificate and certificate data MUST 382 be in format as defined in Section 3.6, [RFC7296]. 383 The support of X.509 certificate - Signature (4) 384 is mandatory. 386 Note: when the option exceeds 255 octets in size (the maximum size of 387 a single option), multiple instances of the same option are generated 388 acording to [RFC3396]. And they should be put in sequential order in 389 the same DHCPv4 message. 391 5.3. Signature Option 393 The Signature option allows a signature that is signed by the private 394 key to be attached to a DHCPv4 message. The Signature option could 395 be any place within the DHCPv4 message while it is logically created 396 after the entire DHCPv4 header and options, except for the 397 Authentication Option. It protects the entire DHCPv4 header and 398 options, including itself, except for the 'giaddr' field, the 'hops' 399 fields, the Authentication Option [RFC3118] and the Relay Agent 400 Information Option [RFC3046]. The format of the Signature option is 401 described as follows: 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | option-code | option-len | HA-id | SA-id | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | | 409 | Signature (variable length) | 410 . . 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 option-code OPTION_SIGNATURE (TBA3). 415 option-len 2 + Length of Signature field in octets. 417 HA-id Hash Algorithm id. The hash algorithm is used for 418 computing the signature result. This design is 419 adopted in order to provide hash algorithm agility. 420 The value is from the Hash Algorithm for Secure 421 DHCPv4 registry in IANA. The support of SHA-256 is 422 mandatory. A registry of the initial assigned values 423 is defined in Section 8. 425 SA-id Signature Algorithm id. The signature algorithm is 426 used for computing the signature result. This 427 design is adopted in order to provide signature 428 algorithm agility. The value is from the Signature 429 Algorithm for Secure DHCPv4 registry in IANA. The 430 support of RSASSA-PKCS1-v1_5 is mandatory. A 431 registry of the initial assigned values is defined 432 in Section 8. 434 Signature A variable-length field containing a digital 435 signature. The signature value is computed with 436 the hash algorithm and the signature algorithm, 437 as described in HA-id and SA-id. The signature 438 constructed by using the sender's private key 439 protects the following sequence of octets: 441 1. The DHCPv4 message header with the 'giaddr' and 442 'hops' fields are set to all 0. It is because 443 DHCPv4 relay agents may change their values. 445 2. All DHCPv4 options including the Signature 446 option (fill the signature field with zeroes) 447 except for the Authentication Option and the Relay 448 Agent Information Option, if there are any. 450 The signature field MUST be padded, with all 0, to 451 the next octet boundary if its size is not an even 452 multiple of 8 bits. The padding length depends on 453 the signature algorithm, which is indicated in the 454 SA-id field. 456 Note: when the option exceeds 255 octets in size (the maximum size of 457 a single option), multiple instances of the same option are generated 458 acording to [RFC3396]. And they should be put in sequential order in 459 the same DHCPv4 message. 461 Note: if both signature and authentication option are present, 462 signature option does not protect the Authentication Option. It is 463 because both options need to apply hash algorithm to whole message, 464 so there must be a clear order and there could be only one last- 465 created option. In order to avoid update auth option, the authors 466 chose not include authentication option in the signature. This 467 design allows the Authentication Option to be created after signature 468 has been calculated and filled with the valid message authentication 469 code (MAC). 471 5.4. Timestamp Option 473 The Timestamp option carries the current time on the sender. It adds 474 the anti-replay protection to the DHCPv4 messages. It is optional. 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | option-code | option-len | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 481 | | 482 | Timestamp (64-bit) | 483 | | 484 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 option-code OPTION_TIMESTAMP (TBA4). 490 option-len 8, in octets. 492 Timestamp The current time of day (NTP-format timestamp 493 [RFC5905] in UTC (Coordinated Universal Time), a 494 64-bit unsigned fixed-point number, in seconds 495 relative to 0h on 1 January 1900.). It can reduce 496 the danger of replay attacks. 498 5.5. Status Codes 500 The following new status codes, see [RFC6926], are defined. They are 501 carried by the Status Code Option (value 151, [RFC6926]). 503 o AlgorithmNotSupported (TBD5): indicates that the DHCPv4 server 504 does not support algorithms that sender used. 506 o AuthenticationFail (TBD6): indicates that the DHCPv4 client fails 507 authentication check. 509 o TimestampFail (TBD7): indicates the message from DHCPv4 client 510 fails the timestamp check. 512 o SignatureFail (TBD8): indicates the message from DHCPv4 client 513 fails the signature check. 515 6. Processing Rules and Behaviors 517 This section only covers the scenario where both DHCPv4 client and 518 server are secure enabled. 520 6.1. Processing Rules of Sender 522 The sender of a Secure DHCPv4 message could be a DHCPv4 server or a 523 DHCPv4 client. 525 The sender must have a public/private key pair in order to create 526 Secure DHCPv4 messages. The sender may also have a public key 527 certificate, which is signed by a CA assumed to be trusted by the 528 receipient, and its corresponding private key. 530 To support Secure DHCPv4, the Secure DHCPv4 enabled sender MUST 531 construct the DHCPv4 message following the rules defined in 532 [RFC2131]. 534 A Secure DHCPv4 message sent by a DHCPv4 server or client MUST either 535 contain a Public Key option, which MUST be constructed as explained 536 in Section 5.1, or a Certificate option, which MUST be constructed as 537 explained in Section 5.2. 539 A Secure DHCPv4 message MUST contain one and only one Signature 540 option, which MUST be constructed as explained in Section 5.3. It 541 protects the message header and all DHCPv4 options except for the 542 'giaddr' field, the 'hops' fields, the Authentication Option and the 543 Relay Agent Information Option. 545 A Secure DHCPv4 message SHOULD contain one and only one Timestamp 546 option, which MUST be constructed as explained in Section 5.4. The 547 Timestamp field SHOULD be set to the current time, according to 548 sender's real time clock. 550 If the sender is a DHCPv4 server and also sends back Relay Agent 551 Information Options to relay agents, it MUST NOT include the Relay 552 Agent Information Options in the computation of signature, as defined 553 in Section 5.3. 555 If the sender is a DHCPv4 client, in the failure cases, it receives a 556 Reply message with an error status code. The error status code 557 indicates the failure reason on the server side. According to the 558 received status code, the client MAY take follow-up action: 560 o Upon receiving an AlgorithmNotSupported error status code, the 561 client SHOULD resend the message protected with one of the 562 mandatory algorithms. 564 o Upon receiving an AuthenticationFail error status code, the client 565 is not able to build up the secure communication with the 566 recipient. However, there may be more than one DHCPv4 servers, 567 one of which may send AuthenticationFail and the other of which 568 may succeed. The client MAY use the AuthenticationFail as a hint 569 and switch to other public key certificate if it has another one; 570 but otherwise treat the message containing the status code as if 571 it had not been received. But it SHOULD NOT retry with the same 572 certificate. However, if the client decides to retransmit using 573 the same certificate after receiving AuthenticationFail, it MUST 574 NOT retransmit immediately. Section 4.1 of [RFC2131] has enforced 575 that "the client MUST adopt a retransmission strategy that 576 incorporates a randomized exponential backoff algorithm to 577 determine the delay between retransmissions." 579 o Upon receiving a TimestampFail error status code, the client MAY 580 resend the message with an adjusted timestamp according to the 581 returned clock from the DHCPv4 server. The client SHOULD NOT 582 change its own clock, but only compute an offset for the 583 communication session. 585 o Upon receiving a SignatureFail error status code, the client MAY 586 resend the message following normal retransmission routines. 588 6.2. Processing Rules of Recipient 590 The recipient of a Secure DHCPv4 message could be a DHCPv4 server or 591 a DHCPv4 client. In the failure cases, either DHCPv4 server or 592 client SHOULD NOT process the received message, and the server SHOULD 593 reply with a correspondent error status code, while the client 594 behaves as if no response had been received from that server. The 595 specific behavior depends on the configured local policy. 597 When receiving a DHCPv4 message, a Secure DHCPv4 enabled recipient 598 SHOULD discard any DHCPv4 messages that meet any of the following 599 conditions: 601 o the Signature option is absent, 603 o multiple Signature options are present, 605 o both the Public Key option and the Certificate option are absent, 607 o both the Public Key option and the Certificate option are present. 609 In such failure, if the recipient is a DHCPv4 server, the server 610 SHOULD reply an UnspecFail error (value 1, [RFC6926]) status code. 611 If none of the Signature, Public Key or Certificate options is 612 present, the sender MAY be a legacy node or in unsecured mode, then, 613 the recipient MAY fall back to the unsecured DHCPv4 mode if its local 614 policy allows. 616 The recipient SHOULD first check the support of the hash and 617 signature algorithms that the sender used. If the check fails for a 618 client, the message SHOULD be dropped. If the check fails for a 619 server, the server SHOULD reply with an AlgorithmNotSupported error 620 status code, defined in Section 5.5, back to the client. If both 621 hash and signature algorithms are supported, the recipient then 622 checks the authority of this sender. The recipient SHOULD also use 623 the same algorithms in the return messages. 625 If a Public Key option is provided, the recipient SHOULD validate it 626 by finding a matching public key from the local trust public key 627 list, which is pre-configured or recorded from previous 628 communications (TOFU). A local trust public key list is a data table 629 maintained by the recipient. It stores public keys from all senders 630 that are considered trustworthy. 632 If a Certificate option is provided, the recipient SHOULD validate 633 the certificate according to the rules defined in [RFC5280]. An 634 implementation may create a local trust certificate record for 635 verified certificates in order to avoid repeated verification 636 procedure in the future. A certificate that finds a match in the 637 local trust certificate list is treated as verified. 639 When the local policy of the recipient allows the use of TOFU, if a 640 Public Key option is provided but it is not found in the local trust 641 public key list, the recipient MAY accept the public key. The 642 recipient will normally store the key in the local list for 643 subsequent DHCPv4 sessions, but it may not necessarily have to do so 644 depending on the purpose of the authentication (see the case of 645 authenticating a client with TOFU described in Section 4). 647 The message that fails authentication check, either because the 648 certificate validation fails or because the public key is not 649 recognized, MUST be dropped. In such failure, the DHCPv4 server 650 SHOULD reply an AuthenticationFail error status code, defined in 651 Section 5.5, back to the client. 653 The recipient MAY choose to further process messages from a sender 654 when there is no matched public key. When a message is authenticated 655 using a key that has not previously been seen, the recipient may, if 656 permitted by policy, treat the sender as trustworthy and record the 657 key for future use (i.e, TOFU). 659 At this point, the recipient has either recognized the authentication 660 of the sender, or decided to drop the message. The recipient MUST 661 now authenticate the sender by verifying the signature and checking 662 timestamp (see details in Section 6.4), if there is a Timestamp 663 option. The order of two procedures is left as an implementation 664 decision. It is RECOMMENDED to check timestamp first, because 665 signature verification is much more computationally expensive. 666 Depending on server's local policy, the message without a Timestamp 667 option MAY be acceptable or rejected. If the server rejects such a 668 message, a TimestampFail error status code, defined in Section 5.5, 669 should be sent back to the client. The reply message that carries 670 the TimestampFail error status code SHOULD carry a timestamp option, 671 which indicates the server's clock for the client to use. 673 The signature field verification MUST show that the signature has 674 been calculated as specified in Section 5.3. Only the messages that 675 get through both the signature verifications and timestamp check (if 676 there is a Timestamp option) are accepted as secured DHCPv4 messages 677 and continue to be handled for their contained DHCPv4 options as 678 defined in [RFC2131]. Messages that do not pass the above tests MUST 679 be discarded or treated as unsecured messages. In the case the 680 recipient is DHCPv4 server, the DHCPv4 server SHOULD reply a 681 SignatureFail error status code, defined in Section 5.5, for the 682 signature verification failure; or a TimestampFail error status code, 683 defined in Section 5.5, for the timestamp check failure, back to the 684 client. 686 Furthermore, the node that supports the verification of the Secure 687 DHCPv4 messages MAY impose additional constraints for the 688 verification. For example, it may impose limits on minimum and 689 maximum key lengths. 691 Minbits The minimum acceptable key length for public keys. An upper 692 limit MAY also be set for the amount of computation needed when 693 verifying packets that use these security associations. The 694 appropriate lengths SHOULD be set according to the signature 695 algorithm and also following prudent cryptographic practice. For 696 example, minimum length 1024 and upper limit 2048 may be used for 697 RSA [RSA]. 699 A Relay-forward or Relay-reply message with any Public Key, 700 Certificate or the Signature option is invalid. The message MUST be 701 discarded silently. 703 6.3. Processing Rules of Relay Agent 705 To support Secure DHCPv4, relay agents just need to follow the same 706 processing rules defined in [RFC2131]. There is nothing more the 707 relay agents have to do, either verify the messages from client or 708 server, or add any secure DHCPv4 options. Actually, by definition in 709 this document, relay agents SHOULD NOT add any secure DHCPv4 options. 711 6.4. Timestamp Check 713 In order to check the Timestamp option, defined in Section 5.4, 714 recipients SHOULD be configured with an allowed timestamp Delta 715 value, a "fuzz factor" for comparisons, and an allowed clock drift 716 parameter. The recommended default value for the allowed Delta is 717 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 718 drift, 0.01 second. 720 Note: the Timestamp mechanism is based on the assumption that 721 communication peers have roughly synchronized clocks, with certain 722 allowed clock drift. So, accurate clock is not necessary. If one 723 has a clock too far from the current time, the timestamp mechanism 724 would not work. 726 To facilitate timestamp checking, each recipient SHOULD store the 727 following information for each sender, from which at least one 728 accepted secure DHCPv4 message is successfully verified (for both 729 timestamp check and signature verification): 731 o The receive time of the last received and accepted DHCPv4 message. 732 This is called RDlast. 734 o The timestamp in the last received and accepted DHCPv4 message. 735 This is called TSlast. 737 A verified (for both timestamp check and signature verification) 738 secure DHCPv4 message initiates the update of the above variables in 739 the recipient's record. 741 Recipients MUST check the Timestamp field as follows: 743 o When a message is received from a new peer (i.e., one that is not 744 stored in the cache), the received timestamp, TSnew, is checked, 745 and the message is accepted if the timestamp is recent enough to 746 the reception time of the packet, RDnew: 748 -Delta < (RDnew - TSnew) < +Delta 750 After the signature verification also succeeds, the RDnew and 751 TSnew values SHOULD be stored in the cache as RDlast and TSlast. 753 o When a message is received from a known peer (i.e., one that 754 already has an entry in the cache), the timestamp is checked 755 against the previously received Secure DHCPv4 message: 757 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 759 If this inequality does not hold or RDnew < RDlast, the recipient 760 SHOULD silently discard the message. If, on the other hand, the 761 inequality holds, the recipient SHOULD process the message. 763 Moreover, if the above inequality holds and TSnew > TSlast, the 764 recipient SHOULD update RDlast and TSlast after the signature 765 verification also successes. Otherwise, the recipient MUST NOT 766 update RDlast or TSlast. 768 An implementation MAY use some mechanism such as a timestamp cache to 769 strengthen resistance to replay attacks. When there is a very large 770 number of nodes on the same link, or when a cache filling attack is 771 in progress, it is possible that the cache holding the most recent 772 timestamp per sender will become full. In this case, the node MUST 773 remove some entries from the cache or refuse some new requested 774 entries. The specific policy as to which entries are preferred over 775 others is left as an implementation decision. 777 An implementation MAY statefully record the latest timestamps from 778 senders. In such implementation, the timestamps MUST be strictly 779 monotonously increasing. This is reasonable given that DHCPv4 780 messages are rarely misordered. 782 7. Security Considerations 784 This document provides new security features to the DHCPv4 protocol. 786 Using public key based security mechanism and its verification 787 mechanism in DHCPv4 message exchanging provides the authentication 788 and data integrity protection. Timestamp mechanism provides anti- 789 replay function. 791 The Secure DHCPv4 mechanism is based on the pre-condition that the 792 recipient knows the public key of the sender or the sender's public 793 key certificate can be verified through a trust CA. Clients may 794 discard the DHCPv4 messages from unknown/unverified servers, which 795 may be fake servers; or may prefer DHCPv4 messages from known/ 796 verified servers over unsigned messages or messages from unknown/ 797 unverified servers. The pre-configuration operation also needs to be 798 protected, which is out of scope. The deployment of PKI is also out 799 of scope. 801 When a recipient first encounters a new public key, it may also store 802 the key using a Trust On First Use policy. If the sender that used 803 that public key is in fact legitimate, then all future communication 804 with that sender can be protected by storing the public key. This 805 does not provide complete security, but it limits the opportunity to 806 mount an attack on a specific recipient to the first time it 807 communicates with a new sender. 809 When using TOFU, if the recipient automatically and unlimitedly 810 stores the public key, an attacker could force the recipient to 811 exhaust the storage by sending DHCPv4 messages with many different 812 keys. There are several possible ways to address this concern: 814 First, the new public key should only be stored after the signature 815 and timestamp validations succeed. It does not prevent the attack 816 itself, but will at least increase the cost of mounting the attack. 817 Another approach is that as long as a client recipient has an 818 uninterrupted connection to a particular network medium, it could 819 limit the number of keys that it will remember as a result of 820 messages received on that medium. Network events like a link state 821 transition would clear the counter, but there might also need to be a 822 counter based on absolute time. In addition, there should probably 823 be a mechanism for purging keys that have only been seen once after a 824 certain period. 826 Downgrade attacks cannot be avoided if nodes are configured to accept 827 both secured and unsecured messages. A future specification may 828 provide a mechanism on how to treat unsecured DHCPv4 messages. 830 [RFC6273] has analyzed possible threats to the hash algorithms used 831 in SEND. Since the Secure DHCPv4 defined in this document uses the 832 same hash algorithms in similar way to SEND, analysis results could 833 be applied as well: current attacks on hash functions do not 834 constitute any practical threat to the digital signatures used in the 835 signature algorithm in the Secure DHCPv4. 837 A server, whose local policy accepts messages without a Timestamp 838 option, may have to face the risk of replay attacks. 840 A window of vulnerability for replay attacks exists until the 841 timestamp expires. Secure DHCPv4 nodes are protected against replay 842 attacks as long as they cache the state created by the message 843 containing the timestamp. The cached state allows the node to 844 protect itself against replayed messages. However, once the node 845 flushes the state for whatever reason, an attacker can re-create the 846 state by replaying an old message while the timestamp is still valid. 847 In addition, the effectiveness of timestamps is largely dependent 848 upon the accuracy of synchronization between communicating nodes. 849 However, how the two communicating nodes can be synchronized is out 850 of scope of this work. 852 Attacks against time synchronization protocols such as NTP [RFC5905] 853 may cause Secure DHCPv4 nodes to have an incorrect timestamp value. 854 This can be used to launch replay attacks, even outside the normal 855 window of vulnerability. To protect against these attacks, it is 856 recommended that Secure DHCPv4 nodes keep independently maintained 857 clocks or apply suitable security measures for the time 858 synchronization protocols. 860 One more consideration is that this protocol does reveal additional 861 client information in their certificate. It means less privacy. In 862 current practice, the client privacy and the client authentication 863 are mutually exclusive. 865 8. IANA Considerations 867 This document defines four new DHCPv4 [RFC2131] options. The IANA is 868 requested to assign values for these four options from the DHCPv4 869 Option Codes table of the DHCPv4 Parameters registry maintained in 870 http://www.iana.org/assignments/bootp-dhcp-parameters. The four 871 options are: 873 The Public Key Option (TBA1), described in Section 5.1. 875 The Certificate Option (TBA2), described in Section 5.2. 877 The Signature Option (TBA3), described in Section 5.3. 879 The Timestamp Option (TBA4),described in Section 5.4. 881 The IANA is also requested to add two new registry tables to the 882 DHCPv4 Parameters registry maintained in 883 http://www.iana.org/assignments/bootp-dhcp-parameters. The two 884 tables are the Hash Algorithm for Secure DHCPv4 table and the 885 Signature Algorithm for Secure DHCPv4 table. 887 Initial values for these registries are given below. Future 888 assignments are to be made through Standards Action [RFC5226]. 889 Assignments for each registry consist of a name, a value and a RFC 890 number where the registry is defined. 892 Hash Algorithm for Secure DHCPv4. The values in this table are 8-bit 893 unsigned integers. The following initial values are assigned for 894 Hash Algorithm for Secure DHCPv4 in this document: 896 Name | Value | RFCs 897 -------------------+---------+-------------- 898 SHA-256 | 0x01 | this document 899 SHA-512 | 0x02 | this document 901 Signature Algorithm for Secure DHCPv4. The values in this table are 902 8-bit unsigned integers. The following initial values are assigned 903 for Signature Algorithm for Secure DHCPv4 in this document: 905 Name | Value | RFCs 906 -------------------+---------+-------------- 907 RSASSA-PKCS1-v1_5 | 0x01 | this document 909 IANA is requested to assign the following new DHCPv4 Status Codes, 910 defined in Section 5.5, in the DHCPv4 Parameters registry maintained 911 in http://www.iana.org/assignments/bootp-dhcp-parameters: 913 Code | Name | Reference 914 ---------+-----------------------+-------------- 915 TBD5 | AlgorithmNotSupported | this document 916 TBD6 | AuthenticationFail | this document 917 TBD7 | TimestampFail | this document 918 TBD8 | SignatureFail | this document 920 9. Acknowledgements 922 This document is developed based on the afforts from its brother 923 document Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6]. Therefore, the 924 authors would like to thank these who helped to develop both 925 documents: Bernie Volz, Ted Lemon, Ralph Droms, Jari Arkko, Sean 926 Turner, Stephen Kent, Thomas Huth, David Schumacher, Francis Dupont, 927 Tomek Mrugalski, Gang Chen, Qi Sun, Suresh Krishnan, Fred Templin, 928 Robert Elz and other members of the IETF DHC working group for their 929 valuable comments. 931 This document was produced using the xml2rfc tool [RFC2629]. 933 10. Change log [RFC Editor: Please remove] 935 draft-jiang-dhc-sedhcpv4-01: change according to the latest change in 936 Secure DHCPv6 during AD review and the comments received during IETF 937 92, 2015-06-18. 939 draft-jiang-dhc-sedhcpv4-00: original version, this draft is largely 940 based on a mature counterpart, Secure DHCPv6, draft-ietf-dhc-secure- 941 dhcpv6. 2015-01-29. 943 11. References 945 11.1. Normative References 947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 948 Requirement Levels", BCP 14, RFC 2119, March 1997. 950 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 951 2131, March 1997. 953 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 954 3046, January 2001. 956 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 957 Messages", RFC 3118, June 2001. 959 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 960 Identifiers for the Internet X.509 Public Key 961 Infrastructure Certificate and Certificate Revocation List 962 (CRL) Profile", RFC 3279, April 2002. 964 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 965 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 966 November 2002. 968 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 969 Algorithms and Identifiers for RSA Cryptography for use in 970 the Internet X.509 Public Key Infrastructure Certificate 971 and Certificate Revocation List (CRL) Profile", RFC 4055, 972 June 2005. 974 [RFC4491] Leontiev, S. and D. Shefanovski, "Using the GOST R 975 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 976 Algorithms with the Internet X.509 Public Key 977 Infrastructure Certificate and CRL Profile", RFC 4491, May 978 2006. 980 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 981 Housley, R., and W. Polk, "Internet X.509 Public Key 982 Infrastructure Certificate and Certificate Revocation List 983 (CRL) Profile", RFC 5280, May 2008. 985 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 986 Time Protocol Version 4: Protocol and Algorithms 987 Specification", RFC 5905, June 2010. 989 [RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell, 990 N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", 991 RFC 6926, April 2013. 993 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 994 Kivinen, "Internet Key Exchange Protocol Version 2 995 (IKEv2)", STD 79, RFC 7296, October 2014. 997 11.2. Informative References 999 [I-D.ietf-dhc-sedhcpv6] 1000 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 1001 DHCPv6", draft-ietf-dhc-sedhcpv6-08 (work in progress), 1002 June 2015. 1004 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1005 June 1999. 1007 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 1008 Hashes in Internet Protocols", RFC 4270, November 2005. 1010 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1011 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1012 May 2008. 1014 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 1015 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 1016 June 2011. 1018 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, 1019 PKCS 1", November 2002. 1021 Authors' Addresses 1023 Sheng Jiang (editor) 1024 Huawei Technologies Co., Ltd 1025 Q14, Huawei Campus, No.156 Beiqing Road 1026 Hai-Dian District, Beijing, 100095 1027 CN 1029 Email: jiangsheng@huawei.com 1030 Dacheng Zhang 1031 Beijing, 100095 100025 1032 P.R. China 1034 Email: dacheng.zhang@gmail.com