Internet DRAFT - draft-xu-dhc-cadhcp
draft-xu-dhc-cadhcp
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]
