Internet DRAFT - draft-bi-dhc-sec-option
draft-bi-dhc-sec-option
DHC Working Group E. Bi
Internet-draft S. Manning
Intended Status: Standards Track M. Wong
Expires: Janurary 17, 2013 Y. Cui
Huawei
July 16, 2012
Security option extensions for DHCP
draft-bi-dhc-sec-option-02
Abstract
This document defines a new option that can be used by DHCP servers
to provision with DHCP clients specific security configuration
information. It has been known that DHCP protocol typically works at
the very beginning stage of the access to networks, thus lack of
security protection. However, although it is difficult to set up some
security mechanism for DHCP protocol solely, it is able to play a key
role for DHCP server to provide configuration information to help
building security mechanism within those pre-configured DHCP clients
and devices. This new option defines a simple extension to current
standard format and benefits to those who need to activate security
mechanism in an early stage and interoperate within devices from
multiple vendors.
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
E. Bi et al. Expires January 17, 2012 [Page 1]
Internet draft DHCP security options extensions July 2012
Copyright and License 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
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
1.1 Applicability . . . . . . . . . . . . . . . . . . . . . . . 3
2 Terminology Used in This Document . . . . . . . . . . . . . . . 4
3 DHCP Security Specific Configuration Option . . . . . . . . . . 4
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1 Normative References . . . . . . . . . . . . . . . . . . . 6
7.2 Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
E. Bi et al. Expires January 17, 2012 [Page 2]
Internet draft DHCP security options extensions July 2012
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 IP packets to and from a client may be required to
be protected by a secure mechanism, which is typically an IPsec
channel or transport layer security established with the server or
administrator.
These security mechanisms require the configuration information can
be provisioned to the DHCP client at the early stage when it is
connected to the network. In particular, the DHCP client should be
notified the crucial security configuration information as early 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 information is expected to be included in DHCP
extension, as well.
1.1 Applicability
Some scenarios that require this kind of provisioning secure
configuration information are when DHCP clients in wireless base
stations are attaching to a wireless network infrastructure. As
defined in [3GPP.33.310], for establishing security link with
operator's network, wireless base station shall connect to the PKI
server and SeGW. If secure configuration information (address of PKI
server, address of SeGW, etc.) is unavailable on the wireless base
stations, the wireless base stations cannot connect to the network.
So it is important for the host to obtain a set of security
configuration 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 security configuration
information 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 configuration information.
E. Bi et al. Expires January 17, 2012 [Page 3]
Internet draft DHCP security options extensions July 2012
The newly defined option is as follows:
Option: DHCP security specific configuration option
2 Terminology Used in This Document
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 address of the
security gateway that is used to establish IPsec tunnel within the
enterprise network, the address of the PKI server which is used to
issue certificate to the DHCP client.
This option may be used wherever DHCP options are available, 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 is as follows:
Opt-ID | opt-length | attribute 1 | attribute 2| ......
where Opt-ID denotes the new option ID, opt-length denotes the bit
length of following attributes, and attributes 1,2... can be extended
correspondingly to various use cases.
For example, in the above use case of 3GPP standards [3GPP.33.310],
the addresses (IP or FQDN) of Se-GW and PKI server are needed to know
for DHCP client (wireless base station), the DHCP option could be as
follows, where attributes 1 and 2 denote Se-GW and PKI server,
respectively.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 1 | data-len1 | Security-GW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Security-GW IP Address Data |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 2 | data-len2 | PKI Server ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ PKI Server IP Address Data |
/ /
E. Bi et al. Expires January 17, 2012 [Page 4]
Internet draft DHCP security options extensions July 2012
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| other attributes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The format of DHCP security specific configuration option
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
security information type. For example, a DHCP client indicates
security configuration information 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 [RFC4361].
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 by client ID, which can be carried in option 60 specified
in [RFC4361]. If the security configuration information 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 requested configuration attributes 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.
Finally, it is also desired to extend this option to IPv6, which is
left to be improved.
E. Bi et al. Expires January 17, 2012 [Page 5]
Internet draft DHCP security options extensions July 2012
4 Security Considerations
This document defines a new security option used by DHCP servers and
DHCP clients to provision security configuration information.
However, the security mechanism itself does not need to rely on the
security of DHCP, i.e. the configuration information provided by DHCP
server can hardly guarantee their own validity, since DHCP originally
is lack of protection.
Therefore, the new option proposed in this document is not aimed to
solve the security of DHCP, but try to make use of DHCP to provide
configuration information for those who have already equipped with
security mechanism, and that security cannot be harmed by potentially
invalid information provisioned.
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.
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.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006.
E. Bi et al. Expires January 17, 2012 [Page 6]
Internet draft DHCP security options extensions July 2012
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
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
E. Bi et al. Expires January 17, 2012 [Page 7]
