DHC Working Group E. Bi Internet-draft S. Manning Intended Status: Standards Track M. Wong Expires: September 10, 2012 Y. Cui Huawei March 12, 2012 Security option extensions for DHCPv4 draft-bi-dhc-sec-option-01 Abstract This document defines a new option that can be used by DHCP servers to exchange with DHCP clients specific security configuration information. This new option defines a standard parameter format and code so that there will be no ambiguity in interoperating the information being exchanged and that there will be no issues related to interoperability. It is an option definition extension for DHCPv4 which should be included in RFC 2132. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Expires [Page 1] Internet draft 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 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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Terminology used in this document . . . . . . . . . . . . . . . 3 3 DHCP Security Specific Configuration option . . . . . . . . . . 4 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 7.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Expires [Page 2] Internet draft 1 Introduction DHCP provides a framework for passing network configuration information to hosts on a TCP/IP network. Some configuration parameters and control information can be carried in DHCP options which are defined in [RFC2132], [RFC3046], [RFC3118], [RFC4030], etc. When a host that acts as a DHCP client booting up, it can be configured with some security policy. Such as, due to the security concern, all the configuration packets to and from a client may be required to be protected by a secure mechanism, which is typically an IPsec secure channel or transport layer security established with the server or administrator. These security mechanisms require the configuration be initialized at the early stage when it is connected to the network. In particular, it should be notified any crucial security configuration as soon as possible. DHCP is essential for users who want to connect to IP networks before they can communicate with other hosts. Among a number of indispensable Internet protocols, it provides the most convenient way to make configuration extension, which eliminates the manual task by a network administrator and duplicate resource assignments. Thus, in addition to the essential IP address and network boot servers, security configuration is expected to be included in DHCP extension, as well. Some scenarios that require this kind of secure booting are when DHCP clients in wireless base stations are attaching to a wireless network infrastructure as defined in [3GPP.33.310]. If secure configuration is unavailable, the packets may be dropped by nodes in the network such as a firewall or security gateway. So it is important for the host to obtain a set of security information, which is configured in the DHCP server prior to the establishment of the security tunnel. Currently, some implementations exchange this security information through DHCP vendor-specific options, i.e. OPTION 43. However, this has the usual limitations of requiring the client and server to understand these vendor-specific extensions. Since most of the parameters that make up the security configuration are common across most clients and servers, having a standardized set of options and procedures would be a huge benefit to interoperability. This document defines a new security DHCP option used to exchange the security information and related parameters. The newly defined option is as follows: Option X1: DHCP Security Specific Configuration option 2 Terminology used in this document Expires [Page 3] Internet draft 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 DHCP Security Specific Configuration option A DHCP server can use this option to indicate to the DHCP client specific configuration information, such as the IP address of the security gateway that is used to establish IPsec tunnel within the enterprise network, multiple IP addresses of the client that are used within the enterprise network. The information contained in the specific configuration area of this option includes one or more attribute values that are assigned by IANA. The information which is contained in these attribute data fields of this option contains the detailed specific configuration information for the DHCP client. This option may be used wherever DHCP options may be used, as specified in [RFC2131] and [RFC2132]. It is most meaningful in the messages between DHCP client and DHCP server, such as, DHCPOFFER and DHCPACK. The format of the option X1 is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | C-IP Address | data-len1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Client IP address Data | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Se-GW ID | data-len2 | Security-GW ID Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Security-GW ID Data | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL policy | data-len3 | ACL Policy Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ACL Policy Data | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PKI IP Add | data-len4 | PKI IP Address Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + PKI IP Address Data | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires [Page 4] Internet draft | RSV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. The format of DHCP security specific configuration option option-code: DHCP security-specific option code (TBD). ion-len: Total length of all following option data in octets. Security-specific attribute N: Security-specific attribute type code (TBD). If the DHCP client is required to securely boot, the address or FQDN of Security gateway for IPsec establishment is required. Additionally, if the security policy dictates, the ACL policy and multiple IP address of the DHCP client for different usage are also required. In this document, the minimum set of security-specific attribute is specified. IP address of the DHCP client: it indicates the IP address of the DHCP client. In current specification defined in [RFC2131], the IP address of client is allocated in yiaddr field, but only one address can be obtained. If multiple IP addresses are needed, such as, transport IP, service IP or public interface IP address and enterprise network IP address, this option can be used. The security-specific attribute data comprise the different separate items. The definition of the sub-security-specific is listed as follows. Public interface IP: it indicates the public interface IP address of the DHCP client. Enterprise IP: it indicates the IP address of the DHCP client used within the enterprise network. Each of the attributes is optional and available according to local policy. Security-gateway ID: it indicates the security information of the security gateway. If the client is configured with security policy, the value is mandatory to use. Else, it cannot obtain the Security gateway information to establish IPsec tunnel. And it is mainly used with IPsec. IP address: it indicates the IP address of the security gateway. Expires [Page 5] Internet draft FQDN: it indicates the FQDN of the security gateway Either of these two sub-security-specific attributes can be contained according to local policy. ACL policy: it indicates the ACL policy attribute. And six elements of the ACL policy are contained in the series of sub-security- specific attributes. The six elements which contains IP address, transport port number, protocol, and DSCP. The client will be configured with an ACL to filter potentially dangerous packets. Only packets that match the ACL parameters are allowed to pass. PKI IP: it indicates the IP address of RA/CA RSV: If is not used, it should be set to zero. Private: It is for private use. These attributes are for the host, the configuration of all of base stations are the same when initially dispatched from the factory, when the server receive the client ID, the server will know whether the client needs to be configured with security, and then it will send the security information to the client. For the client, it MUST identify the option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-sec-spec | data-len2 | sub-sec-spec Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + sub-security -specific-data | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. The format of Sub-security-specific option Sub-security-specific attribute type: type code of the sub-security- specific attribute, i.e., for security-specific attribute, it includes the source IP address, destination address, source port number, destination port number, protocol and DSCP in order. The data-len is one octet long and specifies the length of the sub- security-specific data. This option contains the information corresponding to one or more security-specific code number. Multiple instances of this option may be present and must be concatenated in accordance with [RFC3396]. The definition of the information carried in this option is defined uniformly. The security-specific attribute information indicated the Expires [Page 6] Internet draft security information type. For example, a DHCP client indicates security configurations with the same code number that can be interpreted by different DHCP servers. As the security-specific code is uniform and standard, no ambiguity interpretation can occur. A security-specific code number is unique and only occur once in the option and should be treated independently. This option can also contains one or more encapsulated options that defined in [RFC2132]. DHCP client can request the configuration information from DHCP server by sending DHCP request message. DHCP server allocates the configuration information to DHCP client according to the client ID. i.e., DHCP server can know whether this connecting client needs to be configured security configuration by client ID, which can be carried in option 60 specified in [RFC2132]. If the security configuration is needed, the defined security-specific option will be sent back to the client from DHCP server in DHCPOFFER. If this option is used, different DHCP clients implemented by different vendors have good interoperability. The DHCP server needs only to support one standardized format which reduces complexity and enhances performance. If the DHCP client is configured with a security policy, all of the attributes listed in the figure MUST be carried in the newly defined option in DHCPDISCOVER or DHCPREQUESTmessages. And DHCP server MUST allocate all the request configuration attribute values according to the received attribute type and format in the DHCP response messages. Use of security-specific information allows enhanced operation, utilizing additional features in a DHCP implementation. Servers not equipped to interpret the security-specific information sent by a client MUST ignore it. Clients that do not receive desired security- specific information MUST ignore it and initiate another DHCP operation. 4 Security Considerations This document defines a new security option used by DHCP servers and DHCP clients to exchange security configuration information. And, if the additional configuration information is sensitive in nature, consideration needs to be taken on how to protect it. 5 IANA Considerations There may be IANA consideration for taking additional value for the option. The value of the protocol field needed to be assigned from the numbering space. Expires [Page 7] Internet draft 6 Acknowledgements Thanks to Eric Chen, Xiangsong Cui and Rock Xie who contributed actively to this document. 7 References 7.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. [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001. 7.2 Informative References [3GPP.33.310] 3GPP, "Network Domain Security (NDS); Authentication Framework (AF)", 3GPP TS 33.310 10.3.0, June 2011. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002. [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005. Authors' Addresses Emily Bi Huawei Technologies Beijing, China Email: bixiaoyu@huawei.com Expires [Page 8] Internet draft Serge Manning Huawei Technologies TX, U.S. Email: serge.manning@huawei.com Marcus Wong NJ, U.S. Huawei Technologies Email: mwong@huawei.com Yang Cui Huawei Technologies Beijing, China Email: cuiyang@huawei.com Expires [Page 9]