Dynamic Host Configuration WG Olafur Gudmundsson INTERNET DRAFT Trusted Information Systems March 26, 1997 Security Architecture for DHCP Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document addresses the general security requirements of both v4 and v6 versions of DHCP. This document lists security requirements and proposes as security model, which meets scaling requirements, security requirements and efficiency requirements. The proposed security model uses public key cryptography and a proposed trusted key distribution mechanism to authenticate clients and servers. The authentication protocol can also exchange keying material for more efficiently protecting successive communication between client and server. The security model also addresses securing relay agents. 1. DHCP security requirements One of the problems of designing a security model for DHCP[DHCP] is the wide variety in use and preconditions that different sites/clients have. The fact that sites deploy redundant servers and the lack of a server to server protocol further complicates things, proposed server to server protocol is an Internet draft[Server]. This document assumes fair knowledge of DHCP. 1.1. What is authentication? Authentication is the process of establishing the identity of some entity. Once identity has been authenticated that identity Expires September 26, 1997 [Page 1] Internet Draft March 26, 1997 can be used for access control, accounting etc.. Public key cryptography is a powerful tool that relies on complex mathematical operations to provide information that only the holder of the private key could have generated. For more background information see RFC-1825[RFC1825]. 1.1. Requirements Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are: o "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. o "MUST NOT" This phrase means that the item is an absolute prohibition of this specification. o "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. o "SHOULD NOT" This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. o "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. Expires September 26, 1997 [Page 2] Internet Draft March 26, 1997 2. Proposed DHCP security requirements The proposed requirements can be summarized in the following rules. Initial Client/Server Authentication 1. Server MUST authenticate client identity. 2. Client SHOULD authenticate the server identity as authorized server Initial Relay Agent/Server Authentication 3. Server MUST authenticate relay agent identity as authorized relay agent. 4. Relay Agent MUST authenticate server identity as authorized server. Successive Client to Server and Relay Agent to Server Communication 5. Client and Server MUST agree on security model for protecting future communication. Server/Relay agent advertisements 6. Advertisements MUST be verifiable by all recipients. DHCP security cannot be accomplished in a vacuum; fortunately there are available (or soon will be) protocols that DHCP can take advantage of. First and foremost DNSSEC[DNSSEC] or some other KEY distribution mechanism must be available. IPSEC[RFC1825,IPSEC] will be able to handle requirement 5. It is not clear if IPSEC for IPv6, in some cases using local link addresses, can address requirement 1-4. In the case of IPv4 DHCP MUST perform authentication. 2.1. DHCP Identity In order to secure DHCP all clients MUST have an identity, this identity can possibly be one of the following: host name, user identity, account code. The "prime" identity MUST have a public KEY stored in the key distribution mechanism. The client MUST know its identity before contacting the server. Each client MUST have access to the correct private key before contacting the DHCP server. For example if the identity selected for a host is its host name and the key distribution mechanism is DNS, then the public key used to authenticate the host is stored under the host name in its home zone. The private key needs to be stored in the computer at all times. If the identity selected is the user then the key is stored under the user name in DNS (e.g.: ogud.tis.com for me), and user needs to load the computer with the private key before the host can contact the server. If the identity of Expires September 26, 1997 [Page 3] Internet Draft March 26, 1997 the host is just there to uniquely identify the host, the host still needs a private key. 2.2. Policy issues. This document does not address access control issues as that is a policy issue for each site, but effective access control depends on correct authentication, thus this work will make access control simpler. This document does not address the issue of protecting the private key on either server, agent or client. 3. Client Authentication: One of the goals of this document is to convince the working group that achieving initial authentication is the most important step. Once server and client have established each other's identity the remaining problems can easily be solved. The problem of initial client authentication cannot be solved by IPSEC, as the client does not have an IP identity when it requests service for the first time from server. Once client has been configured it can enter IPSEC security associations with other DHCP servers during the lifetime of the IP address lease. 3.1 Types of DHCP clients and their identification needs. To DHCP there are two kinds of clients. Clients that request some of their net identity, and clients that request ALL of their net identity from DHCP. From a security point of view, the second type of client is no different, because these clients must have some identity (for example MAC address) that can be used to uniquely identify them. Previous DHCP security proposals[DHCAUTH] have suggested the use of shared secrets and passwords to identify clients. It is also possible to use some kind of challenge/response system to identify clients. These approaches have limited scaling ability and require a server to server protocol. But in many environments these weaker authentication mechanisms are adequate. The most general case is the identification of a computer that connects to a world wide ISP network and expects the same identity regardless of location. In this case it is unlikely that the same DHCP server serves both India and Iceland. A network of this kind can have a collaborative agreement between number of different ISPs, with multiple administrative domains. It is not reasonable/scalable that all DHCP servers in this network know shared secrets, or passwords for all computers that are allowed to connect. From a security standpoint it is a bad practice to distribute shared secrets or passwords to many places. 3.2. Motivation for single strong authentication schema. Expires September 26, 1997 [Page 4] Internet Draft March 26, 1997 The author feels that it is better to mandate ONE strong authentication protocol for all DHCP interaction, rather than allow for multiple ones and allow sites to choose the wrong one. The protocol below is a strong authentication using public key signatures and encryption. The security of the protocol depends on the difficulty in breaking the private keys used. The site security depends on the sites protecting the private keys. By mandating one protocol at this point we also eliminate the need for negotiating what authentication protocol to use. At this point the public key algorithm has not been selected. The two leading candidates are RSA and ECC (Elliptical Curve Cryptography). 4. General DHCP Client authentication protocol. This protocol depends on a reliable certified public key distribution mechanism like DNSSEC[DNSSEC]. Each host and server supplies it's identity, this identity indicates where the associated public key is stored. For DNS the identity is FQDN (Fully Qualified Domain Name), accompanied by key algorithm number and public key footprint. For other key distribution mechanisms there must be enough information to retrieve the key from that source. To successfully validate a server public key, clients must be configured with root key(s) for the key distribution certification tree. This protocol never transmits public keys as it is easy to forge self signed keys. Instead certified keys are distributed via trusted 3rd party (eg. DNSSEC). One of the preconditions of this protocol is that client and server MUST roughly agree on current time. The role of the current time information below is to prevent replay attacks. If client does not know the current time, it MUST request it before starting the authentication process. Servers and Relay agents MUST provide current time upon request without any security checks. If the client does not know the current time, it must be able to ask the local relay agent/server for the current time without authentication and get an answer. 4.1. DHCP authentication protocol overview. In the following discussion, DHCP fields not important to the overall security schema are omitted. Following protocol outline assumes that the key distribution mechanism is DNS. Expires September 26, 1997 [Page 5] Internet Draft March 26, 1997 1. Client: Sends server discovery packet containing Identity (this can be one of host identity, claimed identity, charging identity) client's own public key identity Optionally its host identity current time security options/transformations supported DHCP requests for at least address, DNS server and gateway address. all preceding data is signed by client private key corresponding to the public key specified above. 2. Server: If current time is within accepted range Look up client public key in key distribution mechanism verify signature is this client allowed to connect? If all above checks are passed server sends back server Public KEY identity Security model selected key identifier ( if needed by security Model) current time. information client requested for configuration (Address, DNS server, gateway) all above signed by the Server private KEY. 3. Client can now configure itself Look up server Public Key in DNS. if Server key is found, client SHOULD validate packet and Server KEY using DNS client should also verify that DNS server is actually a valid DNS server. Sends server key identifier requesting keying material current time signed by client public key 4. Server: Server generates a random key to use and it sends to client key identifier Keying material Lifetime of the security association. Current time This data is encrypted using clients public key The client decrypts the packet with its private key. At this point the client can assume its normal processing and send further requests to server protected by the security model selected. The protocol for a relay agent is similar but is omitted here. Expires September 26, 1997 [Page 6] Internet Draft March 26, 1997 4.2. Additions to the protocol overview. The protocol outlined above does not spell out all the possible error states that can be entered. This needs to be specified in the full protocol. Some of the possible errors include the following cases: What does the server do if it is unable to retrieve/validate the client key? The Client in its verification phase must be able to determine what are the authorized DHCP servers. This may require a new DNS record, or use the SRV[SRV] record. What does a client do if it is not able to convince itself that it is talking to a good DHCP server? Due to the fact that some of the operations required by this protocol take longer than the time-out values in unsecured DHCP, these need to be changed for Security aware servers and clients. There may be a need for a server to send back an ACK to a client indicating that a request has been received and is being processed to stop client from retransmitting requests. In the case of security aware client trying to talk to security ignorant server the server must return an error code informing the client that it does not understand the request. Security aware servers similarly must treat security ignorant clients differently, but how must be determined. 4.3. Justification for the authentication protocol There are number of reasons why the protocol does not attempt to create a security association in the first round. By explicitly requesting the security association, the client is notifying the server that it trusts the server and wants to establish a long term relationship with it. There is no reason to establish a security association with a server the client does not trust. If a server selects a shared secret or encryption as a message protection mechanism then the key selected by the server is for use between one client and one server for a limited time. If there is a group of DHCP servers for this site, then the server to server protocol MAY be used to distribute the secret to all the servers. If redundant servers do not share secrets then a client MUST authenticate itself to each server. If a security association outlives its lease time, it MUST be renewed or deleted. In this protocol, there is no need for shared secrets to leave an administrative domain. This protocol solves the distribution problem of shared secrets and eliminates the need for clients to remember shared secrets. The explicit expiration of shared secrets greatly simplifies server management of shared secrets. The only information that a client needs to know is its own Expires September 26, 1997 [Page 7] Internet Draft March 26, 1997 identity, its public/private key pair and the root public key for the key distribution mechanism. An added benefit of this protocol is that it does not require the DHCP server to store the authentication information for clients that may connect to it. The public keys used are retrieved from an external source. This means that there will be minimal change in how servers are run. This protocol does not address the access control issue; that is a separate problem. 4.4. What does the authentication protocol accomplish? This protocol accomplishes requirements 1 through 4. It carries enough information to enable requirement 5. For server and client to validate each other public keys they may want to walk the DNS tree to the root to create a chain of valid keys. The client cannot trust the DNS server supplied by the server but it can trust the signed verifiable data that the DNS server provides. This requires that the DHCP client be able to do DNSSEC verification locally. To determine that the Server is not an impostor there may be a need to store in DNS the list of authorized DHCP servers and agents in a zone. The "root keys" that client stores, can be the keys for "." or for the outermost domain that the client can talk to servers in. The main reason for having the server select the secret keying material for the security association, has to do with random number entropy. Many computers do not have good sources of randomness available at boot time. A server that has been running for a while, on the other hand, has access to better sources of randomness. The protocol when specified should include guidelines on how to generate good random keys on servers. 5. Protecting ongoing client/server communication Rule 5 above states that client (or relay agent) and server must agree on a security model for securing all communication. The authentication protocol above accomplishes the required dynamic setup for this. Once a security aware Server and security aware Client have authenticated each other they have entered a security association. This security association will determine how all successive communication is protected. Below is a list of available mechanisms that accomplish this task. A. None (Current state of affairs) NOT recommended B. Message digest with shared secret. (Protects the contents of the packet). C. Digital signature. (Provides more assurance at higher cost). D. Encrypted communication (Provides confidentiality). E. IPSEC. Expires September 26, 1997 [Page 8] Internet Draft March 26, 1997 The author feels that mechanisms B and D are the only ones practical for DHCP. Digital signatures are not worth the computational and bandwidth cost for one on one communication. IPSEC will become viable at some point in the future and can/ should be used to protect the communication. The working group needs to decide whether to deploy a message protection mechanism in the DHCP protocol or wait for IPSEC. This document recommends that B be implemented using HMAC[HMAC] technique combined with one of the following message digest algorithms MD5, SHA-1 or RIPEMD-160. Digital signatures provide a stronger authentication mechanism than Message digests but are much more expensive to generate. Some Digital signatures are inexpensive to verify but not all. RSA is inexpensive to verify but DSA is not. Given the expensive computation of digital signatures it is hard to justify their use once identity has been established. 6. Impact of Agents on security model. Given that in many cases clients need Agents to connect them to DHCP servers, it is important that agents cannot modify the contents of the DHCP request. It is also important that Agents authenticate server advertisements. Agents should not be allowed to modify client requests in any way, other than that required to route the requests. There is no need for the client to enter a security association with its Relay Agent. 6.1. Server/Relay agent advertisements. This is a special case where one entity is talking to many. In order to protect this form of communication from malicious attacks these advertisements MUST be digitally signed using the advertisers public key. It is possible to create a group shared secret or group encryption key. This is not a good arrangement for anything that lasts longer than a short time. Short time can be a few minutes to a few hours; longer than that it is not a secure arrangement. If one party leaks this key information, outsiders can forge traffic. 6.2. Security threats from relay agents. Relay agents can potentially conduct "man in the middle" attacks on a system that uses them. In the schema above relay agents can conduct denial of service attacks. This is a simple fact of life and there is no way to overcome that. It is not clear that relay agents can conduct any other kind of attacks as they are not able to forge any of the contents of the packets. In the case where clients do not validate that the server contacted is a valid server, relay agents may conduct attacks as Expires September 26, 1997 [Page 9] Internet Draft March 26, 1997 fake server. In this attack the relay agent claims to be the server to the client and the client to the server. Careful design of the protocol should be able to prevent this. 7. Security considerations This document is about security. 8. References [DHCP] R. Droms, "Dynamic Host Configuration Protocol", RFC 1541, Bucknell University, October 1993. [DHCAUTH] R. Droms, "Authentication for DHCP Messages", Internet Draft November 1996 [DNSSEC] D. Eastlake, C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997. [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", February 1997 [IPSEC] R. Atkinson, "Security Architecture for the Internet Protocol", Internet Draft , November 1996. [RFC1825] R. Atkinson, "Security Architecture for the Internet Protocol", RFC 1825, September 1995. [Server] R. Droms, R. Cole, "An Inter-server Protocol for DHCP" Internet Draft March 1997. [SRV] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996. 9. Author address Olafur Gudmundsson Trusted Information System 3060 Washington Road Glenwood, MD 21738 +1 301 854 5794 Expires September 25, 1997 [Page 10]