DHC T. Lemon Internet-Draft Nominum, Inc. Expires: January 2004 M. Richardson SSW June 22, 2003 DHCP RSA/DSA Authentication using DNS KEY records draft-ietf-dhc-auth-sigzero-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 22, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines a method for using a KEY record in the DNS belonging to a particular host to authenticate that host's DHCP transactions. 1. Introduction Authentication for DHCP Messages [RFC3118], defines a mechanism by which DHCP messages can be signed, and it also defines two protocols for signing such methods. This document adds a new Lemon & Richardson Expires January 2004 [Page 1] Internet Draft DHCP Authentication with DNS sigzero June 2003 protocol to RFC3118 that can be used to sign DHCP a message using the private half of a public/private key pair, and to verify the signature on the message using the public half, which stored in the DNS, in a KEY resource record stored on the signing host's domain name. It is important to note that this document specifies an authentication mechanism, not an authorization mechanism. The ability to prove that a host knows the secret half of the public key associated with its name can be very useful, but in itself doesn't necessarily mean that it should or should not be trusted in any particular way. However, a mechanism whereby a host can prove that it knows the private key associated with a hostname can be useful in at least two ways. First, DHCP clients can ask DHCP servers to set up PTR records on their behalf. The client provides the name to be stored in the PTR record. With this authentication mechanism, the client, by signing its messages with its private key, proves that it has a right to use the name associated with the public half of the key. The second use that we envision is that both the client's and server's domain names provide a token that can be used in an authorization database - a handle whereby a relationship between the client and server can be documented. On the part of the server, this can be a way to determine whether or not the client is entitled to be allocated resources by the DHCP server, and to what resources it is entitled, in cases where different clients may be allocated different resources. On the part of a client, while the mere fact that a DHCP server has signed its message with a key that turns out to be valid does not mean that the DHCP server is trustworthy, the signature does provide a potentially helpful audit trail back to the source of the invalid DHCP message in the case that it indeed turns out to be invalid. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. Lemon & Richardson Expires January 2004 [Page 2] Internet Draft DHCP Authentication with DNS sigzero June 2003 2. Authentication option for dns-sigzero protocol with RSA. The new algorithm type dns-sigzero for the DHCP option is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code = 90 | Length | Protocol TBD | Algorithm=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDM = 1 | Replay Detection (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay cont. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay cont. | keyid of public key | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | RSA signature | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RSA authentication option for DHCP This section defines the contents of the Authentication Information field of this payload. The RSA signature algorithm is defined in PKCS RSA Cryptography Specifications Version 2.1 [RFC3447]. A more concise definition is provided in RSA/MD5 KEYs and SIGs in the Domain Name System [RFC2537]. The RSA signature is defined with MD5 as the hash algorithm. Lemon & Richardson Expires January 2004 [Page 3] Internet Draft DHCP Authentication with DNS sigzero June 2003 2. Authentication option for dns-sigzero protocol with DSA. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code = 90 | Length | Protocol TBD | Algorithm=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDM = 1 | Replay Detection (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay cont. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay cont. | keyid of public key | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | DSA signature | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: DSA authentication option for DHCP 4. Model of operation 4.1 Changes in processing for DHCP clients Section 4.4 of Dynamic Host Configuration Protocol [RFC2131], defines how the DHCP client processes messages and makes state transitions. When a DHCP client uses the DHCP authentication option with the dns-sigzero protocol, it MUST send a DHCP client FQDN option, and the domain name contained in that option must be fully-qualified. The domain name MUST be a name that exists in the DNS and has a KEY resource record associated with it, and the KEY record's type MUST be DNSSEC. The private key that the client uses to sign its messages MUST be the private half of a public/private key pair. The public half of that key pair must be stored in the KEY resource record associated with the name specified in the FQDN option. 4.2 Client INIT state changes The client MUST include a parameter request list option that includes the DHCP authentication option. 4.3 Client SELECTING state changes Many DHCP clients simply accept the first DHCPOFFER that they Lemon & Richardson Expires January 2004 [Page 4] Internet Draft DHCP Authentication with DNS sigzero June 2003 receive, despite the fact that RFC2131 allows them to wait to collect more than one offer. DHCP clients that implement the dns-sigzero authentication protocol MUST wait for a reasonable period of time after receipt of the first response, and MUST collect additional responses. The client SHOULD validate every response that it receives that is signed. If the client receives any DHCPOFFER message that is signed with a key that it has been configured to consider valid, the client should discard any DHCPOFFER messages that it has received that do not meet this standard. If it receives more than one such message, it should choose between them as specified in RFC2131. If no preferred offer is seen, then the client MUST select among the offers in a non-deterministic manner (ideally, random). This step is important so that a client that has once been deceived into binding to the wrong DHCP server will have a chance to select a different server. A client SHOULD NOT assume that offers that do not include valid and verifiable signature options are exclusively preferred. There may be no DHCP security on the network in question, and attackers could keep the client from ever selecting the "real", unauthenticated server. Note that this behavior differs from that described in point 2 of section 5.5.1 of Authentication For DHCP Messages [RFC3118]. This is because a client may not be able to determine the authenticity of the offer until after it has connected to the network. 4.4 Client REQUESTING state changes If the DHCP client is responding to a message from a DHCP server that is signed using the dns-sigzero protocol, the DHCP client MUST sign its response using the dns-sigzero protocol, using the same key and FQDN that it sent in its DHCPDISCOVER message. In this case, when the client receives a DHCPACK from the server, if the DHCPACK is not signed, or is signed with a different keyid than was used to sign the DHCPOFFER, or if the server identifier is different, the DHCP client MUST drop the DHCPACK message and return to the INIT state. Otherwise, instead of making the transition into the BOUND state, the DHCP client SHOULD make a transition into a new state defined in this document, the PROVISIONALLY-BOUND state. Lemon & Richardson Expires January 2004 [Page 5] Internet Draft DHCP Authentication with DNS sigzero June 2003 4.5 The PROVISIONALLY-BOUND state The PROVISIONALLY-BOUND state is operationally similar to the BOUND state. The timers should be recorded as with the BOUND state. Additional DHCP offers received should be discarded. The DHCP client MUST configure the IP stack and DNS server IP addresses as if it were entering the BOUND state. It SHOULD NOT configure IP addresses for any other servers, nor should it start any services that would normally be started on entry into the BOUND state. Upon entering this state, after performing the partial configuration, the client MUST authenticate the DHCPACK message. To do this, if it does not already have the public key of the DHCP server, it must look it up. The client MUST look up the KEY resource record (subtype DNSSEC) associated with the name provided by the server in its DHCP server name option. The DNS lookup MUST be done using DNSSEC. If the DHCPACK can not be authenticated (either because the KEY can not be retrieved, the DNSSEC does not authenticate the key, or integrity check on the message fails), then the lease MUST be discarded. The client MUST unconfigure the network and return to the INIT state. If the DHCP client is able to authenticate the DHCPACK, then it MUST make the transition to the BOUND state. 4.6 Client BOUND state changes There is a new transition from the Provisionally BOUND state. The only change in behaviour of this state is that when lease renewal occurs, the DHCPREQUEST SHOULD be signed. This is done even if the lease was not originally acquired through a signature, as it MAY be that the server will adopt security in the interum. 4.7 Client RENEWING state changes There is a new transition to the Provisionally BOUND state. If a DHCPACK is received that has a DHCP Authentication option in it, then the client transitions to the Provisionally BOUND state rather than directly back to the BOUND state. The DHCPREQUEST SHOULD be signed using the DHCP authentication Lemon & Richardson Expires January 2004 [Page 6] Internet Draft DHCP Authentication with DNS sigzero June 2003 option, as with the one sent by state SELECTING. 4.8 Client REBINDING state changes The system will transition to Provisionally BOUND upon receipt of a DHCPACK that contains a DHCP authentication option, and a DHCP Server name option. The broadcast DHCPREQUEST SHOULD be signed using authentication option, as with the one sent by state SELECTING. 4.9 Changes in processing for DHCP servers. The Dynamic Host Configuration Protocol [RFC2131] describes how DHCP servers process DHCP messages. This document makes some changes to how messages are processed in the case where an Authentication option is provided that uses the dns-sigzero authentication protocol type. When a DHCP server receives a message from a DHCP client that uses the DHCP authentication option with the dns-sigzero protocol, and it needs to respond to the DHCP client, it SHOULD respond with a signed message using the the dns-sigzero protocol. The DHCP server does not use the Client FQDN option to indicate where the client should look up its KEY record - any Client FQDN option the DHCP server sends contains the client's FQDN information. Instead, the IP address that the DHCP server sends in the server-identifier option MUST have a valid PTR record in the DNS. This PTR record MUST point to an FQDN that has a KEY record, and the KEY record MUST have a type of DNSSEC. The key stored in the KEY record is the public half of a public/private key pair. The DHCP server MUST use the private half of that key pair to sign the message that it sends to the DHCP client. 4.9.1 DHCP DISCOVER processing changes Upon receipt of a DHCPDISCOVER that includes an Authentication option for the DHCP sigzero authentication protocol, the DHCP server MUST verify that the DHCPDISCOVER includes a client FQDN option, and that it is fully qualified. If the message does not contain a client FQDN option containing an FQDN, the DHCP server MUST drop the packet without further processing. Otherwise, the server SHOULD do a secure DNS lookup on the provided FQDN, looking for a KEY resource record (sub-type DNSSEC). Having found a valid KEY (with the matching keyid), the server MAY verify the signature at this point. The server may defer authentication at Lemon & Richardson Expires January 2004 [Page 7] Internet Draft DHCP Authentication with DNS sigzero June 2003 this step, for example if it is above a specified load threshold. If appropriate authentication material is not found, then the DHCPDISCOVER SHOULD be treated as if it were not signed. Otherwise, the DHCP server SHOULD be validate the signature on the message. If the signature cannot be validated, the DHCP server SHOULD log an audit entry that includes the keyid and FQDN that were specified used, and the signatures as computed and as specified in the signature on the message. The server should then drop the message without further processing. If the DHCP server is able to successfully validate the signature, it SHOULD process the DHCPDISCOVER message as specified in [RFC2131]. 4.9.2 DHCPREQUEST processing changes Upon receipt of a DHCPREQUEST that includes an Authentication option for the DHCP sigzero authentication protocol, the DHCP server MUST verify that the DHCPREQUEST includes a client FQDN option, and that it is fully qualified. If the message does not contain a client FQDN option containing an FQDN, the DHCP server MUST drop the packet without further processing. If the server does not have a cached copy of the KEY associated with the supplied FQDN as a result of some previous transaction (e.g., the DHCPDISCOVER/DHCPOFFER transaction), it MUST look up the record again, as described above. The DHCP server SHOULD be validate the signature on the message at this point. If the signature cannot be validated, the DHCP server SHOULD log an audit entry that includes the keyid and FQDN that were specified used, and the signatures as computed and as specified in the signature on the message. The server should then drop the message without further processing. If the DHCP server is able to successfully validate the signature, it SHOULD process the DHCPREQUEST message as specified in [RFC2131]. 4.9.3 DHCPDECLINE processing changes When the DHCP server receives an unsigned DHCPDECLINE message for a transaction where the preceding DHCPREQUEST message was signed using an Authentication option for the DHCP sigzero authentication protocol, the DHCP server SHOULD drop the DHCPDECLINE without Lemon & Richardson Expires January 2004 [Page 8] Internet Draft DHCP Authentication with DNS sigzero June 2003 further processing. Upon receipt of a DHCPDECLINE that includes an Authentication option for the DHCP sigzero authentication protocol, if the DHCPDECLINE does not include a client FQDN option that contains an FQDN, the DHCP server SHOULD drop the DHCPDECLINE packet without further processing. If the specified FQDN is not the same as the FQDN used to acquire the address being declined, the DHCP server SHOULD drop the DHCPDECLINE packet without further processing. Otherwise, the DHCP server SHOULD retrieve the KEY record associated with the specified FQDN either from its cache or through a secure DNS lookup, and SHOULD validate the signature on the message. If the signature cannot be validated, the DHCP server SHOULD log an audit entry that includes the keyid and FQDN that were specified used, and the signatures as computed and as specified in the signature on the message. The server should then drop the message without further processing. If the DHCP server is able to successfully validate the signature, it SHOULD process the DHCPDECLINE message as specified in [RFC2131]. 4.9.4 Annotated exchange between client and server 5. Security Considerations This draft provides a new security mechanism for the DHCP protocol, which may in many cases provide enhanced security. However, like many security mechanisms, the work required to verify public key signatures and trace back through DNSSEC trees is substantial, and can be used against the DHCP server in a denial of service attack. It is also theoretically possible to use this against a DHCP client in a denial of service attack, although this may be somewhat more difficult. 6. IANA Considerations Section 2 defines a new protocol code, as described in [RFC3118]. The value for this code is TBD. Sections 2 and three also describe algorithm codes specific to protocol 2. The algorithm codes are 1 for RSA and 2 for DSA. Lemon & Richardson Expires January 2004 [Page 9] Internet Draft DHCP Authentication with DNS sigzero June 2003 7. Acknowledgments This draft is the very belated result of a conversation with Randy Bush, with some kibbitzing from Johan Ihrens, Olaf Kolkman and a few others at a DHCP/DNS workshop in Amsterdam in January of 2001. The bulk of the idea came from Randy Bush, who was trying to come up with a better way for DHCP clients and servers to do DNS updates. Normative references [RFC3118] Droms, R., Editor, Arbaugh, W. and Editor, "Authentication for DHCP Messages", June 2001. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", March 1999. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", February 2003. [DHCFQDN] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", ID (draft-ietf-dhc-fqdn-option-05.txt), November 2002. Authors' Addresses Ted Lemon Nominum, Inc. 2385 Bay Road Redwood City, CA 94063 USA EMail: mellon@nominum.com Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 Lemon & Richardson Expires January 2004 [Page 10] Internet Draft DHCP Authentication with DNS sigzero June 2003 CA EMail: mcr@sandelman.ottawa.on.ca URI: http://www.sandelman.ottawa.on.ca/ Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.