idnits 2.17.1 draft-ietf-dhc-auth-sigzero-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 151: '...ero protocol, it MUST send a DHCP clie...' RFC 2119 keyword, line 153: '... The domain name MUST be a name that e...' RFC 2119 keyword, line 155: '...EY record's type MUST be DNSSEC. The...' RFC 2119 keyword, line 156: '...ign its messages MUST be the private h...' RFC 2119 keyword, line 163: '... The client MUST include a parameter...' (46 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [RFC2119], but that reference does not seem to mention RFC 2119 either. -- 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 22, 2003) is 7613 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) == Missing Reference: 'RFC2119' is mentioned on line 93, but not defined == Unused Reference: 'RFC2132' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'DHCFQDN' is defined on line 426, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2537 (Obsoleted by RFC 3110) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) == Outdated reference: A later version (-13) exists of draft-ietf-dhc-fqdn-option-05 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC T. Lemon 3 Internet-Draft Nominum, Inc. 4 Expires: January 2004 M. Richardson 5 SSW 6 June 22, 2003 8 DHCP RSA/DSA Authentication using DNS KEY records 9 draft-ietf-dhc-auth-sigzero-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 22, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document defines a method for using a KEY record in the DNS 41 belonging to a particular host to authenticate that host's DHCP 42 transactions. 44 1. Introduction 46 Authentication for DHCP Messages [RFC3118], defines a mechanism 47 by which DHCP messages can be signed, and it also defines two 48 protocols for signing such methods. This document adds a new 49 protocol to RFC3118 that can be used to sign DHCP a message using 50 the private half of a public/private key pair, and to verify the 51 signature on the message using the public half, which stored in the 52 DNS, in a KEY resource record stored on the signing host's domain 53 name. 55 It is important to note that this document specifies an 56 authentication mechanism, not an authorization mechanism. The 57 ability to prove that a host knows the secret half of the public 58 key associated with its name can be very useful, but in itself 59 doesn't necessarily mean that it should or should not be trusted 60 in any particular way. 62 However, a mechanism whereby a host can prove that it knows the 63 private key associated with a hostname can be useful in at least 64 two ways. First, DHCP clients can ask DHCP servers to set up PTR 65 records on their behalf. The client provides the name to be 66 stored in the PTR record. With this authentication mechanism, 67 the client, by signing its messages with its private key, proves 68 that it has a right to use the name associated with the public 69 half of the key. 71 The second use that we envision is that both the client's and 72 server's domain names provide a token that can be used in an 73 authorization database - a handle whereby a relationship between 74 the client and server can be documented. On the part of the 75 server, this can be a way to determine whether or not the client is 76 entitled to be allocated resources by the DHCP server, and to what 77 resources it is entitled, in cases where different clients may be 78 allocated different resources. 80 On the part of a client, while the mere fact that a DHCP server 81 has signed its message with a key that turns out to be valid does 82 not mean that the DHCP server is trustworthy, the signature does 83 provide a potentially helpful audit trail back to the source of the 84 invalid DHCP message in the case that it indeed turns out to be 85 invalid. 87 1.1. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in "Key words for use in 92 RFCs to Indicate Requirement Levels" [RFC2119]. 94 2. Authentication option for dns-sigzero protocol with RSA. 96 The new algorithm type dns-sigzero for the DHCP option is defined 97 as follows: 99 0 1 2 3 100 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 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Code = 90 | Length | Protocol TBD | Algorithm=1 | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | RDM = 1 | Replay Detection (64 bits) | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Replay cont. | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Replay cont. | keyid of public key | | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 110 ~ ~ 111 | RSA signature | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 Figure 1: RSA authentication option for DHCP 116 This section defines the contents of the Authentication Information 117 field of this payload. The RSA signature algorithm is defined in 118 PKCS RSA Cryptography Specifications Version 2.1 [RFC3447]. 119 A more concise definition is provided in RSA/MD5 KEYs and SIGs in 120 the Domain Name System [RFC2537]. The RSA signature is defined 121 with MD5 as the hash algorithm. 123 2. Authentication option for dns-sigzero protocol with DSA. 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Code = 90 | Length | Protocol TBD | Algorithm=2 | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | RDM = 1 | Replay Detection (64 bits) | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Replay cont. | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Replay cont. | keyid of public key | | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 136 ~ ~ 137 | DSA signature | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 2: DSA authentication option for DHCP 142 4. Model of operation 144 4.1 Changes in processing for DHCP clients 146 Section 4.4 of Dynamic Host Configuration Protocol [RFC2131], 147 defines how the DHCP client processes messages and makes state 148 transitions. 150 When a DHCP client uses the DHCP authentication option with the 151 dns-sigzero protocol, it MUST send a DHCP client FQDN option, and 152 the domain name contained in that option must be 153 fully-qualified. The domain name MUST be a name that exists in 154 the DNS and has a KEY resource record associated with it, and the 155 KEY record's type MUST be DNSSEC. The private key that the 156 client uses to sign its messages MUST be the private half of a 157 public/private key pair. The public half of that key pair must 158 be stored in the KEY resource record associated with the name 159 specified in the FQDN option. 161 4.2 Client INIT state changes 163 The client MUST include a parameter request list option that includes 164 the DHCP authentication option. 166 4.3 Client SELECTING state changes 168 Many DHCP clients simply accept the first DHCPOFFER that they 169 receive, despite the fact that RFC2131 allows them to wait to 170 collect more than one offer. DHCP clients that implement the 171 dns-sigzero authentication protocol MUST wait for a reasonable 172 period of time after receipt of the first response, and MUST 173 collect additional responses. The client SHOULD validate every 174 response that it receives that is signed. 176 If the client receives any DHCPOFFER message that is signed with a 177 key that it has been configured to consider valid, the client 178 should discard any DHCPOFFER messages that it has received that do 179 not meet this standard. If it receives more than one such 180 message, it should choose between them as specified in RFC2131. 182 If no preferred offer is seen, then the client MUST select among the 183 offers in a non-deterministic manner (ideally, random). This step is 184 important so that a client that has once been deceived into binding 185 to the wrong DHCP server will have a chance to select a different 186 server. 188 A client SHOULD NOT assume that offers that do not include valid and 189 verifiable signature options are exclusively preferred. There may be 190 no DHCP security on the network in question, and attackers could keep 191 the client from ever selecting the "real", unauthenticated server. 193 Note that this behavior differs from that described in point 2 of 194 section 5.5.1 of Authentication For DHCP Messages [RFC3118]. 195 This is because a client may not be able to determine the 196 authenticity of the offer until after it has connected to the 197 network. 199 4.4 Client REQUESTING state changes 201 If the DHCP client is responding to a message from a DHCP server 202 that is signed using the dns-sigzero protocol, the DHCP client 203 MUST sign its response using the dns-sigzero protocol, using the 204 same key and FQDN that it sent in its DHCPDISCOVER message. 206 In this case, when the client receives a DHCPACK from the server, 207 if the DHCPACK is not signed, or is signed with a different keyid 208 than was used to sign the DHCPOFFER, or if the server identifier 209 is different, the DHCP client MUST drop the DHCPACK message and 210 return to the INIT state. 212 Otherwise, instead of making the transition into the BOUND state, 213 the DHCP client SHOULD make a transition into a new state defined 214 in this document, the PROVISIONALLY-BOUND state. 216 4.5 The PROVISIONALLY-BOUND state 218 The PROVISIONALLY-BOUND state is operationally similar to the 219 BOUND state. The timers should be recorded as with the BOUND 220 state. Additional DHCP offers received should be discarded. 221 The DHCP client MUST configure the IP stack and DNS server IP 222 addresses as if it were entering the BOUND state. It SHOULD NOT 223 configure IP addresses for any other servers, nor should it start 224 any services that would normally be started on entry into the 225 BOUND state. 227 Upon entering this state, after performing the partial configuration, 228 the client MUST authenticate the DHCPACK message. To do this, if 229 it does not already have the public key of the DHCP server, it must 230 look it up. 232 The client MUST look up the KEY resource record (subtype DNSSEC) 233 associated with the name provided by the server in its DHCP server 234 name option. The DNS lookup MUST be done using DNSSEC. 236 If the DHCPACK can not be authenticated (either because the KEY can 237 not be retrieved, the DNSSEC does not authenticate the key, or 238 integrity check on the message fails), then the lease MUST be 239 discarded. The client MUST unconfigure the network and return to 240 the INIT state. 242 If the DHCP client is able to authenticate the DHCPACK, then it 243 MUST make the transition to the BOUND state. 245 4.6 Client BOUND state changes 247 There is a new transition from the Provisionally BOUND state. 249 The only change in behaviour of this state is that when lease renewal 250 occurs, the DHCPREQUEST SHOULD be signed. This is done even if the 251 lease was not originally acquired through a signature, as it MAY be 252 that the server will adopt security in the interum. 254 4.7 Client RENEWING state changes 256 There is a new transition to the Provisionally BOUND state. 258 If a DHCPACK is received that has a DHCP Authentication option in 259 it, then the client transitions to the Provisionally BOUND state 260 rather than directly back to the BOUND state. 262 The DHCPREQUEST SHOULD be signed using the DHCP authentication 263 option, as with the one sent by state SELECTING. 265 4.8 Client REBINDING state changes 267 The system will transition to Provisionally BOUND upon receipt of a 268 DHCPACK that contains a DHCP authentication option, and a DHCP 269 Server name option. 271 The broadcast DHCPREQUEST SHOULD be signed using authentication 272 option, as with the one sent by state SELECTING. 274 4.9 Changes in processing for DHCP servers. 276 The Dynamic Host Configuration Protocol [RFC2131] describes how 277 DHCP servers process DHCP messages. This document makes some 278 changes to how messages are processed in the case where an 279 Authentication option is provided that uses the dns-sigzero 280 authentication protocol type. 282 When a DHCP server receives a message from a DHCP client that uses 283 the DHCP authentication option with the dns-sigzero protocol, and 284 it needs to respond to the DHCP client, it SHOULD respond with a 285 signed message using the the dns-sigzero protocol. The DHCP 286 server does not use the Client FQDN option to indicate where the 287 client should look up its KEY record - any Client FQDN option the 288 DHCP server sends contains the client's FQDN information. 289 Instead, the IP address that the DHCP server sends in the 290 server-identifier option MUST have a valid PTR record in the DNS. 291 This PTR record MUST point to an FQDN that has a KEY record, and 292 the KEY record MUST have a type of DNSSEC. The key stored in the 293 KEY record is the public half of a public/private key pair. The 294 DHCP server MUST use the private half of that key pair to sign the 295 message that it sends to the DHCP client. 297 4.9.1 DHCP DISCOVER processing changes 299 Upon receipt of a DHCPDISCOVER that includes an Authentication 300 option for the DHCP sigzero authentication protocol, the DHCP 301 server MUST verify that the DHCPDISCOVER includes a client FQDN 302 option, and that it is fully qualified. If the message does not 303 contain a client FQDN option containing an FQDN, the DHCP server 304 MUST drop the packet without further processing. 306 Otherwise, the server SHOULD do a secure DNS lookup on the provided 307 FQDN, looking for a KEY resource record (sub-type DNSSEC). Having 308 found a valid KEY (with the matching keyid), the server MAY verify 309 the signature at this point. The server may defer authentication at 310 this step, for example if it is above a specified load threshold. 312 If appropriate authentication material is not found, then the 313 DHCPDISCOVER SHOULD be treated as if it were not signed. 315 Otherwise, the DHCP server SHOULD be validate the signature on the 316 message. If the signature cannot be validated, the DHCP server 317 SHOULD log an audit entry that includes the keyid and FQDN that 318 were specified used, and the signatures as computed and as 319 specified in the signature on the message. The server should then 320 drop the message without further processing. 322 If the DHCP server is able to successfully validate the signature, 323 it SHOULD process the DHCPDISCOVER message as specified in [RFC2131]. 325 4.9.2 DHCPREQUEST processing changes 327 Upon receipt of a DHCPREQUEST that includes an Authentication option 328 for the DHCP sigzero authentication protocol, the DHCP server MUST 329 verify that the DHCPREQUEST includes a client FQDN option, and that 330 it is fully qualified. If the message does not contain a client 331 FQDN option containing an FQDN, the DHCP server MUST drop the 332 packet without further processing. 334 If the server does not have a cached copy of the KEY associated 335 with the supplied FQDN as a result of some previous transaction 336 (e.g., the DHCPDISCOVER/DHCPOFFER transaction), it MUST look up the 337 record again, as described above. 339 The DHCP server SHOULD be validate the signature on the message at 340 this point. If the signature cannot be validated, the DHCP server 341 SHOULD log an audit entry that includes the keyid and FQDN that 342 were specified used, and the signatures as computed and as 343 specified in the signature on the message. The server should then 344 drop the message without further processing. 346 If the DHCP server is able to successfully validate the signature, 347 it SHOULD process the DHCPREQUEST message as specified in [RFC2131]. 349 4.9.3 DHCPDECLINE processing changes 351 When the DHCP server receives an unsigned DHCPDECLINE message for 352 a transaction where the preceding DHCPREQUEST message was signed 353 using an Authentication option for the DHCP sigzero authentication 354 protocol, the DHCP server SHOULD drop the DHCPDECLINE without 355 further processing. 357 Upon receipt of a DHCPDECLINE that includes an Authentication 358 option for the DHCP sigzero authentication protocol, if the 359 DHCPDECLINE does not include a client FQDN option that contains an 360 FQDN, the DHCP server SHOULD drop the DHCPDECLINE packet without 361 further processing. If the specified FQDN is not the same as the 362 FQDN used to acquire the address being declined, the DHCP server 363 SHOULD drop the DHCPDECLINE packet without further processing. 365 Otherwise, the DHCP server SHOULD retrieve the KEY record 366 associated with the specified FQDN either from its cache or 367 through a secure DNS lookup, and SHOULD validate the signature on 368 the message. 370 If the signature cannot be validated, the DHCP server SHOULD log an 371 audit entry that includes the keyid and FQDN that were specified 372 used, and the signatures as computed and as specified in the 373 signature on the message. The server should then drop the message 374 without further processing. 376 If the DHCP server is able to successfully validate the signature, 377 it SHOULD process the DHCPDECLINE message as specified in [RFC2131]. 379 4.9.4 Annotated exchange between client and server 381 5. Security Considerations 383 This draft provides a new security mechanism for the DHCP 384 protocol, which may in many cases provide enhanced security. 385 However, like many security mechanisms, the work required to 386 verify public key signatures and trace back through DNSSEC trees 387 is substantial, and can be used against the DHCP server in a 388 denial of service attack. It is also theoretically possible to 389 use this against a DHCP client in a denial of service attack, 390 although this may be somewhat more difficult. 392 6. IANA Considerations 394 Section 2 defines a new protocol code, as described in [RFC3118]. 395 The value for this code is TBD. Sections 2 and three also 396 describe algorithm codes specific to protocol 2. The algorithm 397 codes are 1 for RSA and 2 for DSA. 399 7. Acknowledgments 401 This draft is the very belated result of a conversation with Randy 402 Bush, with some kibbitzing from Johan Ihrens, Olaf Kolkman and a 403 few others at a DHCP/DNS workshop in Amsterdam in January of 2001. 404 The bulk of the idea came from Randy Bush, who was trying to come 405 up with a better way for DHCP clients and servers to do DNS 406 updates. 408 Normative references 410 [RFC3118] Droms, R., Editor, Arbaugh, W. and Editor, 411 "Authentication for DHCP Messages", June 2001. 413 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 414 March 1997. 416 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP 417 Vendor Extensions", RFC 2132, March 1997. 419 [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name 420 System (DNS)", March 1999. 422 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 423 Standards (PKCS) #1: RSA Cryptography Specifications 424 Version 2.1", February 2003. 426 [DHCFQDN] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", 427 ID (draft-ietf-dhc-fqdn-option-05.txt), November 2002. 429 Authors' Addresses 431 Ted Lemon 432 Nominum, Inc. 433 2385 Bay Road 434 Redwood City, CA 94063 435 USA 437 EMail: mellon@nominum.com 439 Michael C. Richardson 440 Sandelman Software Works 441 470 Dawson Avenue 442 Ottawa, ON K1Z 5V7 443 CA 445 EMail: mcr@sandelman.ottawa.on.ca 446 URI: http://www.sandelman.ottawa.on.ca/ 448 Full Copyright Statement 450 Copyright (C) The Internet Society (2003). All Rights Reserved. 452 This document and translations of it may be copied and furnished to 453 others, and derivative works that comment on or otherwise explain it 454 or assist in its implementation may be prepared, copied, published 455 and distributed, in whole or in part, without restriction of any 456 kind, provided that the above copyright notice and this paragraph are 457 included on all such copies and derivative works. However, this 458 document itself may not be modified in any way, such as by removing 459 the copyright notice or references to the Internet Society or other 460 Internet organizations, except as needed for the purpose of 461 developing Internet standards in which case the procedures for 462 copyrights defined in the Internet Standards process must be 463 followed, or as required to translate it into languages other than 464 English. 466 The limited permissions granted above are perpetual and will not be 467 revoked by the Internet Society or its successors or assigns. 469 This document and the information contained herein is provided on an 470 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 471 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 472 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 473 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 474 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 476 Acknowledgement 478 Funding for the RFC Editor function is currently provided by the 479 Internet Society.