DHC Y. Xu Internet-Draft S. Manning Intended status: Standards Track M. Wong Expires: March 24, 2012 Huawei Technologies September 21, 2011 An Authentication Method based on Certificate for DHCP draft-xu-dhc-cadhcp-01.txt Abstract This document defines a technique that can provide both entity authentication and message authentication based on certificate. This protocol combines three existing options, authentication option as specified in delay authentication mechanism in [RFC3118] and the user authentication protocol option defined in [RFC2485]. The goal of this specification is to define methods based certificate to protect the integrity of DHCP message and stop the gaps of the existing delay authentication mechanism. In order to meet these goals, we use the asymmetrical cryptography protection and some options about authentication that have been defined in other specifications. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on March 24, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Xu Expires March 24, 2012 [Page 1] Internet-Draft Certificate based DHCP Security September 2011 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Xu Expires March 24, 2012 [Page 2] Internet-Draft Certificate based DHCP Security September 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Certificate based Authentication . . . . . . . . . . . . . . . 5 4. Unicast/Broadcast DHCPOFFER Message . . . . . . . . . . . . . 7 5. Authentication between DHCP Server and Trusted Server . . . . 8 6. Signature Generation . . . . . . . . . . . . . . . . . . . . . 8 7. Message Validation . . . . . . . . . . . . . . . . . . . . . . 9 8. Entity Authentication . . . . . . . . . . . . . . . . . . . . 9 9. Client Considerations . . . . . . . . . . . . . . . . . . . . 9 10. Server Considerations . . . . . . . . . . . . . . . . . . . . 10 11. Trusted Server Considerations . . . . . . . . . . . . . . . . 10 12. Application Example . . . . . . . . . . . . . . . . . . . . . 11 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 16.1. Normative References . . . . . . . . . . . . . . . . . . 14 16.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Xu Expires March 24, 2012 [Page 3] Internet-Draft Certificate based DHCP Security September 2011 1. Introduction DHCP provides a framework for passing network configuration information to hosts on a TCP/IP network. Most of these parameters are IP addresses. DHCP server can allocate addresses to client dynamically. To ensure the security of communication between DHCP client and DHCP server, network administrators wish to provide authentication for the DHCP client and DHCP messages. [RFC3118] defines an authentication mechanism for DHCP, delay authentication protocol. But it is vulnerable to denial of service attack through flooding with DHCPDISCOVER messages, which are not authenticated by Delay authentication protocol. This attack may exhaust the addresses available for assignment by the DHCP server and other attacks and limitations. As this delay authentication is based on the pre-shared key. It increases the overload of key distribution and management in the implementation, e.g., when there are many DHCP clients in the network, if delay authentication is used, a great number of pre- shared key must be configured in DHCP server for different DHCP clients, it results in the overload as the pre-shared key configuration and management. Additionally, the delayed authentication does not support inter-domain authentication. As the delay mechanism relies on a shared secret between the two negotiating authorities. For the case of servers providing service to local clients, the above mechanism may be sufficient. But in the more general case of the clients roaming across domains it is not possible to create all the possible key associations beforehand. Possible solutions to this problem may be possible to use the certificate and asymmetric algorithm. As defined in [RFC5280] , certificates can be used in entity authentication widely. But as the MTU in Ethernet usually is 1500 bytes, while the certificate is usually large as 1k or 2k bytes, DHCP message, such as DHCPDISCOVER messages and DHCPREQUEST messages in some scenario are broadcast messages, these cannot be fragmented into several messages. Thus directly carrying certificates in DHCP messages is impossible. Considering these reasons discussed above and the requirements of some operators for DHCP security, a new mechanism is proposed. This document defines a new method for Dynamic Host Configuration Protocol authentication based on certificates. The basic design philosophy is performing authentication immediately between DHCP client and DHCP server by combining some authentication options, sending URL information and the Client identity specified in [RFC2485] and [RFC2132] instead of a certificate directly, and leveraging a mechanism where the DHCP server has been authenticated by a centralized trusted server. Xu Expires March 24, 2012 [Page 4] Internet-Draft Certificate based DHCP Security September 2011 2. Terminology 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 [RFC2119]. 3. Certificate based Authentication The DHCP client is configured with its certificate and the corresponding private key and the certificate of trusted server. The DHCP server is configured with its certificate and the corresponding private key. The trusted server is configured with its certificate and the corresponding private key and certificates of DHCP Clients. A DHCP client sends DHCPDISCOVER message that has been protected by its private key to DHCP server, the verification of the message is through the DHCP server and trusted server. If successful, the DHCP server sends the DHCPOFFER message protected with the private key of the DHCP server. And the DHCP client authenticates the DHCP server by the validation of the DHCPOFFER message. Based on the authentication option from [RFC3118] , if the protocol field is 2(TBD), the message authentication uses the certificate based authentication mechanism defined in this document. In the certificate based authentication, the client requests authentication in DHCPDISCOVER message and the server replies with a DHCPOFFER message. Three options are included in the DHCPDISCOVER message, the Authentication Option defined in this document, the Client-identifier Option defined in [RFC2132] and the User Authentication Protocol Option defined in [RFC2485] . The DHCPDISCOVER message is signed with the private key of the DHCP client. For the Authentication Option, unlike the delayed authentication mechanism, the signature generated with the DHCP client private key is added in the Authentication Information. The Client-identifier Option (Option 61) is used to carry the DHCP client identifier. If the DHCP client is configured with a certificate, the FQDN of certificate can be used as the DHCP client identifier. The User Authentication Protocol Option is used to carry the URL of the trusted server, such as, a certificate server. The URL of the trusted server can be configured out of band. The format of the authentication request in a DHCPDISCOVER or a DHCPINFORM message for certificate authentication is: Xu Expires March 24, 2012 [Page 5] Internet-Draft Certificate based DHCP Security September 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |0 0 0 0 0 0 1 0| Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDM | Replay Detection (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay cont | Signature (128bytes/256bytes/512 bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. The format of the authentication request (DHCPDISCOVER/ DHCPINFORM) The code for the authentication option is 90, and the length field contains the length of protocol, RDM, algorithm, Replay Detection field, and Signature. The protocol is defined to 2(00000010). The signature field is used for message validation. The other field is defined as [RFC3118] . When the DHCP server receives the DHCPDISCOVER message, it can obtain the certificate of DHCP client by the URL and the client identity. At first, the DHCP server searches the trusted server with the URL information, and forwards the client identity information to the trusted server to obtain the DHCP client certificate. If the DHCP server is authenticated by a trusted server, the DHCP server downloads the DHCP client certificate from the trusted server. The certificate may be protected with the secure tunnel, such as, SSL/ TLS, which established between the DHCP server and the trusted server. Through the authentication between DHCP server and the trusted server, only the legitimate DHCP server or the authenticated DHCP server can obtain the certificate of the DHCP client from the trusted server. After the trusted server receives the client identity information, it checks the validity of the client identity. If it is legitimate, the trusted server will send the certificate to the DHCP server via the SSL/TLS tunnel. Upon receiving the DHCP client certificate, the DHCP server checks that the subject field of certificate matches with the client identity. The DHCP server validates the signature of the DHCPDISCOVER in Authentication Option. If the validation is successful, it proves that the DHCP client is in possession of the private key corresponding to the certificate. At this time, the DHCP client has been authenticated with the certificate based authentication mechanism. Xu Expires March 24, 2012 [Page 6] Internet-Draft Certificate based DHCP Security September 2011 4. Unicast/Broadcast DHCPOFFER Message When DHCPOFFER message is unicast, it can be fragmented and maybe used to carry a certificate. The DHCP server will use its private key to sign the DHCPOFFER message, which contains the configured information, such as Vendor Specific Information option, the Authentication option, and may contain other options. The certificate of the DHCP server is included in the Authentication Option. The format of the option is shown in Figure 2. If the length exceeds the MTU, it can be fragmented with several messages with same sequence number specified as in [RFC3396] . When the DHCP client receive whole the DHCPOFFER message, it obtains the certificate of DHCP server to check whether the certificate is valid, and validates the signature of the DHCPOFFER message. The following DHCPREQUEST message and the DHCPACK message can be validated by the same authentication mechanism. The DHCP client protects the sending message with the signature generated by its private key. The DHCP server validates the signature with the public key of the DHCP client. The format of the authentication information in a DHCPOFFER, DHCPACK message for certificate authentication is shown as follow, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |0 0 0 0 0 0 1 0| Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDM | Replay Detection (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay cont | Flags|U| RSD | Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Certificate [n]... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature (128bytes/256bytes/512 bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. The format of the authentication information (DHCPOFFER/ DHCPACK) We can use the new defined format of the option. Then we can use the following format in DHCPOFFER, DHCPACK message. And when the option exceeds 255 bytes, the method that specified in [RFC3396] will be used. Xu Expires March 24, 2012 [Page 7] Internet-Draft Certificate based DHCP Security September 2011 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 | Length |0 0 0 0 0 0 1 0| Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDM | Replay Detection (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay cont | Certificate ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature (128bytes/256bytes/512 bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. The format of the new authentication option When DHCPOFFER message is broadcast, DHCP server sends to DHCP client DHCPOFFER message, which contains the public key of DHCP server, the certificate URL of the DHCP server and the signature of the DHCPOFFER with the private key of the DHCP server. When DHCP client receives the public key of the server, it considers this certificate as a valid one temporarily. The client authenticates the DHCPOFFER with this DHCP public key and gets the IP address allocated by the server. At that, the client achieves the certificate of DHCP server with the URL, and checks whether this certificates match with the public key carried in DHCPOFER message. If they match, the client can affirm the validity of the server. 5. Authentication between DHCP Server and Trusted Server The authentication mechanism between DHCP server and the trusted server may be any existing authentication method, such as, the SSL/ TLS defined in [RFC4246] and [RFC5246] . After the authentication between the trusted server and the DHCP server, the SSL/TLS tunnel is established between DHCP server and the trusted server. 6. Signature Generation The signature of the message is generated through the private key and DHCP content, such as, DHCP message or some information like entity identity. For the DHCPDISCOVER and the DHCPREQUEST message, the signature is generated with the private key of the DHCP client. For the DHCPOFFER and the DHCPACK message, the signature is generated with the private key of the DHCP server and the DHCP contents. Xu Expires March 24, 2012 [Page 8] Internet-Draft Certificate based DHCP Security September 2011 7. Message Validation To validate the incoming DHCP messages, the receiver will check the signature with the corresponding public key. For the DHCPDISCOVER and the DHCPREQUEST message, the DHCP server first checks whether the value in replay detection field is acceptable according to the replay detection method specified by the RDM field. Next the server validates the signature with the public key in the certificate of client. for the DHCPOFFER and the DHCPACK message, the client checks the replay detection field, if it is correct, the client validates the certificate of DHCP server and checks the validity of the signature of the DHCP message to guarantee that this DHCP server has been authenticated. 8. Entity Authentication The DHCP server authenticates the DHCP client by the validation of the DHCPDISCOVER message signature. This validation is carried out by the DHCP server with the certificate of the DHCP client acquired from the trusted server. The DHCP client authenticates the DHCP server by validating the certificate of DHCP server and the signature of the DHCPOFFER message. 9. Client Considerations This section describes the behavior of a DHCP client using the certificate based authentication. 1. The client MUST include the authentication request option based on certificate where the protocol field is equal to 2 in its DHCPDISCOVER message along with the client identifier option and the User Authentication Protocol Option. The DHCPDISCOVER message MUST sign the message with the private key client. 2. The client MUST perform the validation of the certificate of DHCP server and the signature of the DHCPOFFER message. 3. The client replies with a DHCPREQUEST message that MUST include authentication option protected by the same private key used in DHCPDISCOVER message. 4. If the client validates the DHCPOFFER it accepted, the client MUST validate the DHCPACK message from the server. Xu Expires March 24, 2012 [Page 9] Internet-Draft Certificate based DHCP Security September 2011 10. Server Considerations This section describes the behavior of a DHCP server in response to client message using certificate based authentication. General considerations 1. Each server MUST be authenticated by a trusted server and can maintain the secure link with this trusted server. 2. Each server MUST validate the incoming message with the public key of the DHCP client by obtaining the certificate of the DHCP client from the trusted server. 3. Each server MUST protect the sending message by the private key of the DHCP server. If the replay detection check or the message signature validation fails, the server MUST discard the incoming message. 11. Trusted Server Considerations The trusted server is only a general name for a certificate server. Any valid authentication mechanism may be used between DHCP server and trusted server. The trusted server can regarded as high level sever that can authenticate DHCP servers. This section describes the behavior of the trusted server using certificate based authentication. 1. The trusted server MAY authenticate the DHCP server prior to the connection between the DHCP client and DHCP server. 2. The trusted server MUST distribute the certificate of the DHCP client to a legitimate DHCP server that has been authenticated. 3. Client certificates may be cached or obtained in real time, but caching has performance gain at the expense of memory usage. As the client list grows, the DHCP server will use more memory to store the certificate of client, which will increase the overhead of certificate management. This is similar to the argument of not using PSK-based scheme. Xu Expires March 24, 2012 [Page 10] Internet-Draft Certificate based DHCP Security September 2011 12. Application Example +-------------+ +------------+ +---------------+ | | | | | | | client | |DHCP server | |Trusted Server | | | | | | | +-------------+ +------------+ +---------------+ | | Security Tunnel | | |<----------------->| | DHCP Discover | | |-------------------------->| | | | Security Tunnel | | |<----------------->| | |download certificate| | |<----------------->| | | | | +----------------------+ | | | Obtian public key of | | | | DHCP client,validate | | | | the messsage | | | +----------------------+ | | DHCP OFFER | | |<------------------------->| | | | | +---------------------+ | | |Validate the message | | | +---------------------+ | | | DHCP Request | | |-------------------------->| | | DHCP ACK | | |<------------------------->| | Figure 4. DHCP Example Procedure Security tunnel will be established between DHCP server and Trust server before or after DHCP server receive DHCP DISCOVER message. With the DHCP client ID and the address information of trusted server, DHCP server obtain the corresponding public key of the DHCP client to validate the DHCP DISCOVER message. If successful, the DHCP server will send DHCPOFFER to DHCP client specified according to unicast case or broadcast case. And the client validates the DHCP OFFER corresponding to the two different cases. The authentication of following messages can be used the similar mechanism. Xu Expires March 24, 2012 [Page 11] Internet-Draft Certificate based DHCP Security September 2011 13. Security Considerations 1. on Signature Signature calculation can be based on either the private key of sender or the public key of receiver, but with the private key of sender, it has the effect of origin authentication. 2. On Authentication The two entity authentication is considered only bi-lateral authentication and not mutual authentication. Each authentication is verified independently without both client and server contributing to the authentication. When DHCPOFFER is unicast, it can be fragmented and maybe used to carry a certificate. In this case, DHCP client may be able to receive the certificate of DHCP server. Furthermore, the DHCPOFFER may then be signed by the private key of server, which also provides the benefit of origin authentication. 3. Delay authentication is based on symmetrical encryption algorithm, the certificated authentication method is based on asymmetrical encryption algorithm. The comparison of symmetrical encryption algorithm and asymmetrical encryption algorithm: On Calculation speed, symmetrical encryption algorithm is faster than asymmetric encoding algorithm. On Length of the key, asymmetrical encryption algorithm is longer than symmetrical encryption algorithm. And for asymmetrical encryption algorithm, it is difficult to derive the decrypted key from the encrypt key since they are different. So asymmetrical encryption algorithm has the higher security level. On the overload and feasibility, it increases the overload of key distribution and management in the implementation for symmetrical encryption algorithm, as it needs to pre-configured key beforehand. And asymmetrical encryption algorithm can support inter-domain authentication preferably. 4. Implementations MUST support the following attribute algorithm values a) Integrity Algorithm Xu Expires March 24, 2012 [Page 12] Internet-Draft Certificate based DHCP Security September 2011 i. MD5 ii. SHA1 Algorithm Type Value RESERVED 0 HASH_MD5 1 HASH_SHA1 2 HASH_SHA256 3 HASH_SHA384 4 HASH_SHA512 5 Standards Action 6-127 Private Use 128-255 Unassigned 256-32767 b) signature algorithm i. RSA Algorithm Type Value RESERVED 0 RSA 1 Standards Action 2-127 Private Use 128-255 Unassigned 256-32767 14. IANA Considerations There may be IANA consideration for taking additional value for this option. The values of the protocol field needed to be assigned from the numbering space. Xu Expires March 24, 2012 [Page 13] Internet-Draft Certificate based DHCP Security September 2011 15. Acknowledgments Thanks to Sophia Bi, Serge Manning, Marcus Wong, Eric Chen, Xiangsong Cui and Rock Xie who contributed actively to this document. 16. References 16.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2485] Drach, S., "DHCP Option for The Open Group's User Authentication Protocol", RFC 2485, January 1999. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. 16.2. Informative References [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002. [RFC4246] Dolan, M., "International Standard Audiovisual Number (ISAN) URN Definition", RFC 4246, February 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Xu Expires March 24, 2012 [Page 14] Internet-Draft Certificate based DHCP Security September 2011 Authors' Addresses Yixian Xu Huawei Technologies Huawei Building, Xinxi Road No.3 Haidian District, Beijing 100085 P. R. China Phone: +86-10-82836300 Email: xuyixian@huawei.com Serge Manning Huawei Technologies Phone: 001-9725435324 Email: serge.manning@huawei.com Marcus Wong Huawei Technologies Phone: 001-908-5413505 Email: mwong@huawei.com Xu Expires March 24, 2012 [Page 15]