idnits 2.17.1 draft-gupta-dhcp-auth-02.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 28, 2003) is 7729 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) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2486 (ref. '8') (Obsoleted by RFC 4282) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration Working V. Gupta 3 Group Sun Labs 4 Internet-Draft February 28, 2003 5 Expires: August 29, 2003 7 Flexible Authentication for DHCP Messages 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 29, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This memo proposes a new protocol for DHCP authentication within the 40 general framework outlined in RFC 3118 [4]. This protocol uses 41 public-key cryptography, in the form of digital signatures, for 42 authentication. This simplifies key management and supports mutual 43 authentication between clients and servers belonging to different 44 administrative domains. 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [1]. 50 Please send comments on this document to the DHCP mailing list. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Protocol 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1 Code, Length and Protocol . . . . . . . . . . . . . . . . . . 4 57 2.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3 Replay Detection Method (RDM) . . . . . . . . . . . . . . . . 5 59 2.4 Replay Detection Field . . . . . . . . . . . . . . . . . . . . 5 60 2.5 Key ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.6 Authenticator . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Client, Server, and Relay Agent Considerations . . . . . . . 9 63 4. Roaming Support for DHCP Clients . . . . . . . . . . . . . . 10 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 6. Revision History . . . . . . . . . . . . . . . . . . . . . . . 13 66 7. Future Directions . . . . . . . . . . . . . . . . . . . . . . 14 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 68 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 70 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 72 1. Introduction 74 The Dynamic Host Configuration Protocol (DHCP) provides an extensible 75 framework through which a host can acquire various configuration 76 parameters from a centrally managed server. Such parameters include 77 (among many others) the host's IP address, subnet mask, default 78 router, DNS domain, DNS server and NTP servers. The protocol, as 79 specified in RFC 2131 [2], is susceptible to various attacks 80 including source spoofing, message modification, replays and 81 eavesdropping. 83 RFC 3118 [4] outlines a mechanism (Protocol 1) for adding 84 authentication information to DHCP messages that guards against 85 source spoofing, message alteration and replays. It assumes that the 86 entities exchanging authenticated information share a secret key not 87 known to anyone else. The sender uses the key to compute a keyed 88 hash (or MAC) over the information to be protected and a replay 89 detection field. This MAC is sent along with the DHCP message. The 90 receiver recomputes the MAC over the same fields using its copy of 91 the key and compares the result against the MAC received with the 92 incoming message. A successful match authenticates the sender. 94 RFC 3118 also describes another mechanism (Protocol 0) that carries 95 an authentication token (a password) in the clear and only offers 96 weak authentication without message integrity protection. 98 This draft proposes a new protocol, Protocol 2, with the aim of 99 supporting public-key based authentication. Compared to schemes 100 based on secret keys, public-key mechanisms ease key management and 101 offer improved scalability. This draft relies on RFC 3396 [5] for 102 encoding options longer than 255 octets. Like RFC3118, this note 103 does not address confidentiality of DHCP messages. 105 2. Protocol 2 107 The format of the DHCP authentication option used in this draft (see 108 Figure 1) is the same as in RFC 3118 with the Authentication 109 Information field subdivided into two variable length fields. 111 Key ID: This is a generalization of the "secret ID" field in 112 Protocol 1 and identifies the public-key needed to verify the 113 authenticator. Several forms of Key ID are supported including 114 X.509 certificate chains, hashes of X.509 certificates, and opaque 115 values. 117 Authenticator: This is a generalization of the HMAC-MD5 field in 118 Protocol 1. It contains either a MAC or a digital signature 119 depending on whether the authentication algorithm uses symmetric- 120 or asymmetric- key cryptography. 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Code | Length | Protocol (2) | Algorithm | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | RDM | | 128 +-+-+-+-+-+-+-+-+ + 129 | Replay Detection Field (64-bits) | 130 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | | Key ID Type | Key ID length | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | | 134 ~ Key ID Value ... (variable length) ~ 135 ~ ~ 136 | | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | | 139 ~ Authenticator (variable length) ... ~ 140 | | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Figure 1: Format of the DHCP authentication 144 option for Protocol 2. 146 2.1 Code, Length and Protocol 148 The Code for the authentication option is 90. The Length field 149 contains the length of the entire option except for the code and 150 length octets. This length equals 11 plus the size of the 151 authentication information (in octets) and can typically be encoded 152 in a single octet. However for certain Key ID types (such as 153 individual certificates or certificate chains), it is possible that 154 the total length of the authentication option exceeds 255. In this 155 case, the authentication option MUST be encoded as described in RFC 156 3396 and the length field set accordingly. 158 The Protocol field MUST carry the value 0x02 for this specification. 160 2.2 Algorithm 162 The Algorithm field determines which public-key based algorithm is 163 used to compute the authenticator. 165 The following algorithms are defined. Algorithm 1 (RSA-MD5) MUST be 166 supported. 168 Algorithm 169 field Description Reference 170 ----- ----------- --------- 171 1 RSA-MD5 signature PKCS#1 172 [6] 174 2 DSA signature FIPS 180-1 175 [7] 177 Figure 2: Authentication algorithms 179 2.3 Replay Detection Method (RDM) 181 This octet indicates the replay detection method used by the DHCP 182 client and server. It determines how the Replay Detection Field is 183 set by the sender and also how its contents are interpreted at the 184 receiver. 186 An RDM value of 0 MUST be supported. Other values of RDM will be 187 defined in a subsequent revision. 189 2.4 Replay Detection Field 191 The content and interpretation of this field is controlled by the RDM 192 (Replay Detection Method) field. If the RDM field contains 0x00, the 193 replay detection field MUST be set to the value of a monotonically 194 increasing counter as mandated in RFC 3118. 196 2.5 Key ID 198 The Key ID field is used to identify the key that the receiver of an 199 authenticated DHCP message can use to verify the authenticator. It 200 is composed of three sub-fields 202 Key ID Type: Identifies the type of Key ID information carried in 203 the Key ID field. 205 Key ID Length: Number of octets used to encode the Key ID Value 206 field. 208 Key ID Value: Contains the actual identifier of the key needed to 209 verify the authenticator. 211 The following Key ID Types are defined. Implementations MUST support 212 the OPAQUE Key ID type. 214 Key ID 215 Type Description 216 ----- ----------- 218 RESV (0) Reserved 220 OPAQUE (1) Indicates that the Key ID Value contains 221 an opaque value. How the receiver uses it 222 to look up a key is entirely a local matter 223 at the receiver. The presumption here is 224 that the sender and receiver have a previously 225 agreed method of mapping the opaque key ID 226 value to a key. This definition is consistent 227 with that of the "Secret ID" in Protocol 1. 229 X509_CERT_CHAIN Indicates that the Key ID Value subfield 230 (2) contains a chain of one or more DER encoded 231 X.509 certificates. The first certificate 232 in the chain is that of the sender and 233 each subsequent certificate certifies the 234 public key used in signing the immediately 235 preceding certificate. Chains containing 236 multiple certificates are useful if the 237 receiver does not have the authenticated 238 public key of the sender and may need to 239 follow a certificate chain to establish 240 the required trust. 242 The public key contained in the first 243 certificate MUST be for the same algorithm 244 as indicated in the Algorithm field. For 245 example, if the Algorithm field indicates 246 DSA, the first certificate MUST include a 247 DSA public key. Similarly, if the Algorithm 248 field indicates RSA-MD5, the certificate 249 MUST include an RSA public key authorized for 250 use in digital signatures. After verifying 251 the authenticity of the sender's certificate, 252 the receiver SHOULD cache this trusted 253 certificate and its MD5 hash. Doing so has 254 two benefits -- (i) it speeds verification of 255 subsequent messages from the same sender, and 256 (ii) allows the sender to save bandwidth by 257 including just a certificate hash rather 258 than a complete certificate chain inside 259 subsequent messages. 261 CERT_MD5_HASH Indicates that the Key ID Value is the 262 (3) MD5 hash of a certificate. This is useful 263 in situations where the sender has reason 264 to believe that the corresponding 265 certificate is already available to the 266 receiver (e.g. it may have been sent in 267 a previous message or the receiver is known 268 to have local access to a certificate repository 269 containing the sender's certificate). Due to 270 the collision resistance property of MD5, the 271 hash identifies a unique certificate with a high 272 degree of confidence. Sending the hash (16 273 octets) rather than the actual certificate 274 results in smaller messages. 276 4 - 255 Reserved 278 2.6 Authenticator 280 The computation and verification of the Authenticator field depends 281 on the type of the authentication algorithm. For RSA-MD5, the 282 authenticator is the RSA signature (with MD5 hash) computed using the 283 sender's private key as described in PKCS#1 [6]. For DSA, the 284 authenticator is the concatenation of two 20 octet numbers (r 285 followed by s) representing the DSA signature computed according to 286 FIPS 180-1 [7]. The two numbers are carried "raw" without DER 287 encoding. In both cases, it is the public-key corresponding to the 288 private-key used in signing that MUST be identified in the Key ID 289 field. 291 The input for these computations is the same. It is the entire DHCP 292 message (except as noted below) to be protected upto and including 293 the authentication option. Before signing or computing the MAC, the 294 authentication option (except for the authenticator) must be 295 completely filled out and the authenticator field must be set to 296 zeros. Since a DHCP relay agent may alter the values of the 'giaddr' 297 and 'hops' fields in the DHCP message, the contents of these two 298 fields MUST also be set to zero for computation of the signature or 299 MAC. A relay agent may append the DHCP relay agent option 82 after 300 the authentication option. Options that appear after the 301 authentication option will not be protected by the Authenticator 302 described above. 304 3. Client, Server, and Relay Agent Considerations 306 These considerations are not impacted in any way by the use of 307 Protocol 2 instead of Protocol 1. Readers are referred to RFC 3118 308 for the details. 310 4. Roaming Support for DHCP Clients 312 Roaming can be loosely defined as the ability of a customer to "use 313 any one of multiple Internet service providers (ISPs), while 314 maintaining a formal, customer-vendor relationship with only one" 315 (quoted from RFC 2486 [8]). Each roaming user is uniquely identified 316 by a Network Access Identifier (NAI) [8] which looks like 317 joe@acme.net and includes enough information to identify the ISP with 318 which that user has a formal customer-vendor relationship. Most ISPs 319 that offer roaming services today use PPP (over dial-up) as the 320 address allocation mechanism. In the future, ISPs that use DHCP for 321 address allocation (such as some DSL or Cable Modem ISPs) may also 322 wish to support roaming. In such a scenario, it is logical to use 323 NAIs as DHCP client identifiers so both types of ISPs can identify 324 users in a consistent fashion. 326 This section outlines how the authentication option may be used to 327 support DHCP clients roaming between different administrative 328 domains. For this illustration, we consider a DHCP client associated 329 with ISP-A that roams to a DHCP-enabled network belonging to ISP-B. 330 We assume that these two ISPs have a roaming agreement in place. The 331 agreement may be indirect, e.g. through a broker such as iPass [9] 332 or GRIC [10]. Before providing full network connectivity to the 333 client, ISP-B would like to verify that it can bill ISP-A for the 334 service. The following paragraphs describe one possible sequence of 335 steps through which this can be accomplished. 337 We assume that each client has a digital certificate issued by its 338 ISP (the ISP may out source the actual issuance of certificates but 339 that is unimportant for our discussion). The certificate is valid as 340 long as the customer's account active and is revoked when the account 341 is closed. Besides its own private key, the client also has a 342 trusted copy of its ISP's public key. These keys may be carried on 343 removable media such as a smart card. If keys are stored on the 344 client's local storage (e.g. a portable computer's hard disk), then 345 the private key MUST be stored encrypted with a user chosen password. 346 Doing so minimizes the risk of a security breach should the client be 347 stolen. 349 The example here uses RSA signatures for authentication. 351 1. The roaming client, C, establishes link connectivity (e.g. by 352 plugging into an RJ-45 slot for a 10BaseT connection or by 353 completing an 802.11 association) and sends out a DHCPDISCOVER 354 request with a request for authentication. The DHCP client 355 identifier (Option 61 defined in RFC 2132 [3]) is set to contain 356 the roaming user's Network Access Identifier. 358 2. By looking at the NAI from Step 1, a DHCP server, S, on the the 359 visited network can determine the ISP, ISP-A, to which the client 360 belongs. The server checks that its ISP, ISP-B, has a roaming 361 agreement with the client's ISP, ISP-A. If so, it responds with 362 a DHCPOFFER message containing an authentication option. In this 363 option, the Algorithm is set to RSA-MD5, the Key ID Type is set 364 to X509_CERT_CHAIN and the Key ID Value is set to include the 365 server's certificate (issued by ISP-B) and ISP-B's certificate 366 signed by ISP-A. If the agreement between ISP-A and ISP-B is 367 through a broker, K, then the certificate chain may instead 368 contain: Server's certificate signed by ISP-B, ISP-B's 369 certificate signed by K and K's certificate signed by ISP-A. 370 Other combinations are also possible depending on the public keys 371 that the client is expected to possess. The authenticator 372 contains a RSA-MD5 signature computed by the server using its 373 private key. 375 3. Using a locally available copy of ISP-A's public key, the client 376 can verify the server's public key and signature and and 377 authenticate the offer. If authentication is successful, the 378 client sends out a DHCPREQUEST message. In the authentication 379 option, Algorithm is set to RSA-MD5, the Key ID Type is set to 380 X509_CERT_CHAIN, the Key ID Value is set to include the client's 381 certificate issued by ISP-A and the authenticator contains an 382 RSA-MD5 signature computed by the client using its private key. 384 4. The server first verifies the client's certificate (this may 385 require it to interact with another entity such as a certificate 386 repository) and uses the public key it contains to verify the 387 client's signature. If verification succeeds, it sends back a 388 DHCPACK message completing the sign-on process, otherwise it 389 sends back a DHCPNAK. 391 Unlike typical dial-up roaming situations where only the client is 392 authenticated, the scheme outlined above provides mutual 393 authentication of the client and server. 395 5. Security Considerations 397 This document describes a new protocol based on public-key 398 cryptography for adding source authentication, integrity protection 399 and replay detection to DHCP messages. It does not address 400 confidentiality of these messages. 402 6. Revision History 404 Version Date Comments 405 ------- ---- -------- 407 00 Jun 23, 1998 Created initial version. 409 01 Oct 22, 1999 Incorporated feedback from 410 the DHCP working group meeting 411 in Oslo. Changes include: 412 RDM field expanded to 4 bits, 413 algorithm field is now a full 414 octet, key ID length now maintains 415 16-bit alignment, theft of service 416 discussion moved to a seprate 417 document, removed unnecessary 418 distinction between a single 419 certificate and a certificate chain 420 (the former is a special case). 422 02 Feb 28, 2003 Revived draft in response to renewed 423 working group interest in public-key 424 based authentication. Made modifications 425 to reflect the publication of RFC 426 3118 and RFC 3396 as proposed standards. 428 7. Future Directions 430 DISCUSSION: It seems reasonable to include an authenticator in the 431 very first message, i.e. DHCPDISCOVER. This gives DHCP servers an 432 opportunity to authenticate the client before sending back any 433 network configuration parameters. 435 TODO: Add nonce based replay protection. The basic idea is as 436 follows: DHCPDISCOVER message will include a "challenge" from the 437 client, DHCPOFFER will include the server's "response" and its own 438 "challenge", DHCPREQUEST will include the client's "response" etc. 440 Such nonce-based replay detection minimizes the amount of replay 441 related state that must be maintained across reboots. 443 8. Acknowledgments 445 The author wishes to thank members of the DHCP Security Threat Team - 446 - Ralph Droms, Barr Hibbs, Carl Smith, Bernie Volz and Mimi Zohar for 447 encouraging him to revive this draft and several individuals (whose 448 names have been unfortunately misplaced) for providing valuable 449 feedback on this draft at the Oslo IETF meeting. 451 References 453 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 454 Levels", RFC 2119, March 1997. 456 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 457 March 1997. 459 [3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 460 Extensions", RFC 2132, March 1997. 462 [4] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 463 RFC 3118, June 2001. 465 [5] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic 466 Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002. 468 [6] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1.5", 469 PKCS 1, November 1993. 471 [7] NIST, "Digital Signature Standard", FIPS 180-1, 2000. 473 [8] Aboba, B. and M. Beadles, "Network Access Identifier", RFC 2486, 474 January 1999. 476 [9] 478 [10] 480 Author's Address 482 Vipul Gupta 483 Sun Microsystems Laboratories 484 2600 Casey Avenue 485 MS UMTV29-235 486 Mountain View, CA 94303 487 USA 489 Phone: +1 650 336 1681 490 EMail: vipul.gupta@sun.com 492 Full Copyright Statement 494 Copyright (C) The Internet Society (2003). All Rights Reserved. 496 This document and translations of it may be copied and furnished to 497 others, and derivative works that comment on or otherwise explain it 498 or assist in its implementation may be prepared, copied, published 499 and distributed, in whole or in part, without restriction of any 500 kind, provided that the above copyright notice and this paragraph are 501 included on all such copies and derivative works. However, this 502 document itself may not be modified in any way, such as by removing 503 the copyright notice or references to the Internet Society or other 504 Internet organizations, except as needed for the purpose of 505 developing Internet standards in which case the procedures for 506 copyrights defined in the Internet Standards process must be 507 followed, or as required to translate it into languages other than 508 English. 510 The limited permissions granted above are perpetual and will not be 511 revoked by the Internet Society or its successors or assigns. 513 This document and the information contained herein is provided on an 514 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 515 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 516 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 517 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 518 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 520 Acknowledgement 522 Funding for the RFC Editor function is currently provided by the 523 Internet Society.