Internet DRAFT - draft-yiu-dhc-dhcpv6-sa
draft-yiu-dhc-dhcpv6-sa
DHC Working Group Y. Lee
Internet-Draft Comcast
Intended status: Informational Y. Cui
Expires: September 9, 2015 Z. Liu
L. Sun
Tsinghua University
March 8, 2015
Secure Access Mechanism for DHCPv6
draft-yiu-dhc-dhcpv6-sa-00
Abstract
DHCPv6 [RFC3315] provides configuration parameters such as IPv6
network addresses for hosts. The unencrypted nature and use of
various identifiers make its privacy and security become more
vulnerable. With appropriate protection mechanisms, the privacy and
security can be improved to some extent. This document specifies
such a mechanism that builds a trusted relationship between DHCPv6
clients and servers before solicitation. The mechanism enables a
valid client to find and access the legitimate server or reject and
blacklist a rogue server.
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 September 9, 2015.
Copyright Notice
Copyright (c) 2015 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
Lee, et al. Expires September 9, 2015 [Page 1]
Internet-Draft Secure Access Mechanism for DHCPv6 March 2015
(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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview of Secure Access Mechanism . . . . . . . . . . . . . 4
5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5
6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Client Behaviour . . . . . . . . . . . . . . . . . . . . 6
6.2. Server Behaviour . . . . . . . . . . . . . . . . . . . . 7
6.3. Behaviour in Lightweight Mode . . . . . . . . . . . . . . 8
7. Further Protection Considerations . . . . . . . . . . . . . . 8
7.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Encryption . . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
[RFC3315] specifies the Dynamic Host Configuration Protocol for IPv6.
[I-D.ietf-dhc-dhcpv6-privacy] analyzes the DHCPv6 privacy issues and
discusses how various identifiers used in DHCPv6 could become a
source for gleaning additional information of an individual. Such
identifiers are included in various DHCPv6 messages. In other words,
there are important client information embedded in DHCPv6 messages.
If the messages are sent to a rogue server or an invalid third party,
end users' privacy and security may be compromised.
Current authentication models include secure DHCPv6
[I-D.ietf-dhc-sedhcpv6] and authentication mechanism defined in
[RFC3315]. Both share the primary goal of validating the identity of
message sender. They were not designed to protect client privacy.
DHCPv6 messages such as SOLICIT contains sensitive client
information, these messages are not protected. Further, current
authentication mechanisms focus more on the identity of clients, they
do not provide full authentication of the DHCPv6 server (e.g. server
Lee, et al. Expires September 9, 2015 [Page 2]
Internet-Draft Secure Access Mechanism for DHCPv6 March 2015
authentication in secure DHCPv6 is based on leap of faith). Current
authentication mechanisms aim to protect the DHCPv6 server by
preventing invalid clients from launching attacks such as DoS attack.
However when considered client privacy, the authenticity of server
really matters.
Hence there is a requirement to design a mechanism that sets up a
trusted relationship between a client and a server before starting
the DHCPv6 transaction (i.e. before DHCPv6 solicitation). In this
document, we propose such a peer entity authentication called Secure
Access by defining two new DHCPv6 messages. The Secure Access
mechanism makes use of server and client certificates and achieves
authentication through Public Key Infrastructure ([RFC5280]). With
the designed mechanism, a valid client can find and access the
legitimate server or reject and blacklist a rogue entity before
standard DHCPv6 process.
The Secure Access mechanism specified in this document does not
affect the current DHCP design. It is more like an alternative
extension, only the client who wants to improve the privacy will use
it. Another benefit is that further data protection solution such as
encryption can be based on the trusted relationship built by this
mechanism.
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. Related Works
This section briefly introduces the existed authentication models and
discusses their pros and cons when compared with the design in this
document.
Authentication mechanism defined in [RFC3315] provides a basic
verification of DHCPv6 messages sender and contents through using an
Authentication option. The Authentication option can be treated as a
symmetric key, which is a simple but limited authentication pattern.
Two specific protocol, Delayed Authentication Protocol and
Reconfigure Key Authentication Protocol, are proposed along with this
option. This authentication framework also allows future separate
authentication protocols to be put forward but it seems not to be
deployable.
Secure DHCPv6 ([I-D.ietf-dhc-sedhcpv6]) enhance the security of
DHCPv6 by using server's public/private key pairs and client's
Lee, et al. Expires September 9, 2015 [Page 3]
Internet-Draft Secure Access Mechanism for DHCPv6 March 2015
certificates to authenticate. To ease the pre-configuration of
authentication, the client make a leap of faith to trust the server.
While the server provide full authentication of client through
validating its certificate. Secure DHCPv6 also enables the recipient
to check the message integrity and offers anti-replay protection
using timestamps. Compared with authentication mechanism in
[RFC3315], secure DHCPv6 is more lightweight and provide better
protection when refers to the authentication of DHCPv6 clients.
4. Overview of Secure Access Mechanism
The Secure Access mechanism defined in this document is mainly based
on the server and client's certificates. Similar to secure DHCPv6,
we also make use of PKI (Public Key Infrastructure) to authenticate
relevant entities. Since both certificates of client and server are
required, a full bidirectional authentication between client and
server is available. The certificates used in this document are all
X.509 v3 certificates whose details can be found in [RFC5280].
If a client desires to improve privacy when using DHCPv6, it can
initiate the Secure Access process to achieve a peer entity
authentication. The client applies for its public key certificate
from a CA (Certificate Authority) which is signed by the CA's private
key. Then the client implements a new DHCPv6 message called
Authenticate and multicasts it to the servers. The Authenticate
message MUST carry the Certificate option defined in
[I-D.ietf-dhc-sedhcpv6] to provide server with client's public key
certificate. It is RECOMMENDED that the Authenticate message does
not carry options other than Certificate option for the privacy.
A legitimate server also needs to get its own certificate from CA as
the client does. The server receives the Authenticate message needs
to verify the client's certificate. Typically it uses the CA's
public key to validate whether the client is trusted or not.
Detailed process of the authentication is described in [RFC5280] and
is out of scope of this document. If the client is valid, the server
will respond a new DHCPv6 message called Authenticate-reply message
which contains a Certificate option (carry the server's public key
certificate) and a Server Unicast option. It is possible for the
server to carry more information (more options) in the Authenticate-
reply message (e.g. Server Unicast option).
The initiated client MAY receive more than one Authenticate-reply
messages from different servers. It verifies each Authenticate-reply
message by validating corresponding server certificate through PKI.
If the Authenticate-reply message does not contain a Certificate
option or the verification fails, the client will discard the message
and further blacklist the server. The client remember those servers
Lee, et al. Expires September 9, 2015 [Page 4]
Internet-Draft Secure Access Mechanism for DHCPv6 March 2015
who pass the verification as legitimated ones. In this way, the
client can find legitimate servers and trigger the normal DHCPv6
process in a more protected way (e.g. unicast or encryption).
This mechanism provides an end-to-end authentication between DHCPv6
clients and servers. When a relay agent is involved, the only
function it performs is forwarding. Also the relay agent does not
allowed to add any additional options.
The Secure Access mechanism also supports another lightweight mode
which only based on the server's certificate. Since it is uncommon
for a client to obtain a certificate from the CA, we have to make the
mechanism applied to such a scenario that only server certificate is
available. This may sacrifice the security of a DHCPv6 server to
some extent but will not do harm to the client privacy. Since the
server responses usually do not contain much client information. In
this lightweight mode, the server responds an Authenticate-reply
message as soon as it received a Authenticate message from the
client. Then the client performs the same process as the common mode
has described.
5. New DHCPv6 Messages
Two new DHCPv6 messages are defined to achieve the peer entity
authentication between clients and servers before standard DHCPv6
process. The Authenticate message is always sent by the client to
carry its certificate and the Authenticate-reply message is sent by
the server for client to validate its legitimacy. This section
describe the two new messages formats and structures.
Both Authenticate and Authenticate-reply message use the Client/
Server message formats described in Section 6 of [RFC3315]. Two new
message codes are defined in the following.
AUTHENTICATE (TBA1): The client multicasts an Authenticate message to
available servers to request for legitimate servers. The
Authenticate message contains client's certificate for server to
check its validity.
AUTHENTICATE-REPLY (TBA2): The server sends an Authenticate-reply
message to requesting client to prove its legitimacy by carrying the
Certificate option. It also needs to include a Server Unicast option
to provide the client with its address.
Lee, et al. Expires September 9, 2015 [Page 5]
Internet-Draft Secure Access Mechanism for DHCPv6 March 2015
6. Behaviour
This section describes the behaviour of DHCPv6 clients and servers
when Secure Access mechanism is deployed. It is suitable for the
clients who are concerned about their privacy and are eager to
improve it. All the behaviours are prior to the standard DHCPv6
process, that is to say the Secure Access mechanism will be finished
before the DHCPv6 Solicit message is sent to the server.
6.1. Client Behaviour
If a client wants to improve its privacy by finding a legitimate
server to communicate, it will be more reasonable that the requesting
client is also valid. In the context of this document, only valid
clients can obtain their certificates from a trusted CA. That would
require the CA to judge whether a client is valid or not. A common
and simple solution is to make the trusted CA handled by the ISP. In
this way, the trusted CA could easily achieve the verification
through ISP's registration data. While there could be more extra
solutions and the actual CA implementation is out of scope of this
document. A valid client can only have one certificate which is
signed by the trusted CA.
Once the client obtains its certificate, it can trigger the Secure
Access mechanism by multicasting the Authenticate message to the
servers (i.e. using the multicast addresses defined in [RFC3315]).
The client MUST insert only one Certificate option in the
Authenticate message. The Certificate option is used to carry the
client's certificate and is defined in [I-D.ietf-dhc-sedhcpv6]. In
order not to leak any client information in the Secure Access phase,
it is also RECOMMENDED that the Authenticate message does not include
any other options except for Certificate option.
After sending out the Authenticate message, the client is waiting for
servers' response. During this period, it will discard any DHCPv6
message that the message type is not AUTHENTICATE-REPLY. The client
is not allowed to send any other message whose message type is not
AUTHENTICATE until it finds an authenticated server.
On receipt of servers' Authenticate-reply messages, it first checks
the options field. The client simply discards the message if it
includes neither Certificate option nor Server Unicast option. If
the Authenticate-reply message include a Server Unicast option but
not a Certificate option, the client will blacklist this server as a
rogue server. If the Authenticate-reply message include a
Certificate option but not a Server Unicast option, the client will
also discard the received message. When both Certificate option and
Server Unicast option exist, the client extracts the Certificate
Lee, et al. Expires September 9, 2015 [Page 6]
Internet-Draft Secure Access Mechanism for DHCPv6 March 2015
options then verifies it through PKI. If the verification fails, the
client will blacklist the server. The client remembers servers who
pass the verification as legitimate servers and choose one to build
trusted relationship. Based on the trusted relationship, the client
can employ further protection means to initiate a standard DHCPv6
process. The further protection means are discussed in Section 7.
The client should implement a timer locally. If it has not received
any Authenticate-reply message when the timer expires, it will reset
the timer and resend its Authenticate message. If it still could not
receive any Authenticate-reply in the second expiration, the client
would treat this condition as a failure of authentication. There
could be various solutions for the failure such as reporting to the
user or starting standard DHCPv6 process that ignores the failure
condition. Which solution is employed is dependent on the client
side policy. The timer expiration and client side policy would vary
in different scenarios, hence their implementations are out of scope
of this document.
6.2. Server Behaviour
If a server is legitimate and support the Secure Access mechanism
defined in this document, it should obtain its certificate from the
same trusted CA when it is configured. Such server should provide
services for both standard DHCPv6 process and DHCPv6 with Secure
Access. When it receives a standard DHCPv6 message (e.g. Solicit),
it just follows the procedure defined in [RFC3315].
When the server receives an Authenticate message, it is an indication
that the client wishes to build a trusted relationship with a
legitimate server. The server who is willing to be accessed by such
a client extracts the Certificate option to validate the client
through PKI. If there is no Certificate option or the authentication
fails, the server will simply discard this message. If the client
can be proved to be valid (i.e. its certificate is trusted), the
server will respond an Authenticate-reply message to the valid
client. The Authenticate-reply message MUST include only one
Certificate option to carry server's certificate and one Server
Unicast option. It should be noted that the only function of Server
Unicast option is to provide the client with the server's IP address,
whether to unicast a message in the following process is depend on
the client side.
The server is allowed to add more options in the Authenticate-reply
message to provide any other information that it is willing to
present to the client. If the server receives an Authenticate
message twice, it will resend an Authenticate-reply message.
Lee, et al. Expires September 9, 2015 [Page 7]
Internet-Draft Secure Access Mechanism for DHCPv6 March 2015
If a server does not support the Secure Access mechanism defined in
this document, it will simply discard the received Authenticate
message and do nothing else.
6.3. Behaviour in Lightweight Mode
The Secure Access mechanism also supports a lightweight mode that the
authentication is only based on server certificates. Under this
circumstance, the server does not need to validate the client's
certificate. If a client wishes to start the Secure Access mechanism
in a lightweight mode, it will multicast the Authenticate message
without any option in it. If the server receives an Authenticate
message without any option, it is an indication that the lightweight
mode is employed. The server simply skips the process of validating
a client, responds the Authenticate-reply with the server
certificate. Then the client follows the same process after sending
out Authenticate message as described in section 6.1 to finish the
mechanism.
7. Further Protection Considerations
The Secure Access mechanism follows the peer entity authentication
principle defined in section 6.3, second bullet of [RFC6973]. With
the mechanism employed, it is possible for a client to find a
legitimate server and then build a trusted relationship with it. The
trusted relationship also makes further protection measures feasible.
This section briefly discusses such two further protection methods
that can be used to protect the later standard DHCPv6 process.
7.1. Unicast
In a typical DHCPv6 process, a client is always not aware of the
server's address when it sends the first message (i.e. Solicit
message). Thus DHCPv6 makes use of multicast to send the Solicit
message to any available server on the same link. The multicast
characteristic encourages more rogue servers or eavesdroppers to
appear. If the client could unicast message to the server, the
privacy could be improved effectively. Following the [RFC3315], a
client could unicast its message if it receives a Server Unicast
option from the server. However in the current design, it is
impossible to unicast a Solicit message or an Information-Request
message which also contains important client information. This is
due to both messages are always the first message in the standard
DHCPv6 transaction (Client-server Exchange Involving Two Messages and
Four Messages respectively).
With the Secure Access mechanism, the scenario that a Solicit message
or an Information-Request could not be unicast would be solved.
Lee, et al. Expires September 9, 2015 [Page 8]
Internet-Draft Secure Access Mechanism for DHCPv6 March 2015
Since the server includes a Server Unicast option in the
Authenticate-reply which is received before the standard DHCPv6
process. If the server can be proved as a legitimate server through
the Secure Access mechanism, the client could then use the server
address embedded in the Server Unicast option to unicast its Solicit
message or Information-request message. It should be noted that the
client may record multiple legitimate servers, it should choose one
to start unicast transaction based on a local policy. The detailed
policy is out of scope of this document.
7.2. Encryption
DHCPv6 message contains various identifiers that may expose important
client information. Confidentiality is always a better way to
improve the privacy since it can make the data secret from the
eavesdroppers. There are various encryption patterns could be used
to add confidentiality to the DHCPv6 process, but each of them would
require a pre-authentication to validate the identity of the two
endpoints.
The Secure Access mechanism just provides such an end-to-end
authentication to support the further encryption pattern. Encryption
also introduces some drawbacks such as more overhead, larger packet
size and so on. The encryption scheme for DHCPv6 should be
lightweight and do not need to be perfect. The further details of
DHCPv6 confidentiality is out of scope of this document and could be
defined in another separate document.
8. Security Considerations
TBD
9. IANA Considerations
This document defines two new DHCPv6 [RFC3315] messages. IANA is
requested to assign the following new DHCPv6 Message types in the
registry maintained in http://www.iana.org/assignments/
dhcpv6-parameters:
AUTHENTICATE
AUTHENTICATE-REPLY
10. References
Lee, et al. Expires September 9, 2015 [Page 9]
Internet-Draft Secure Access Mechanism for DHCPv6 March 2015
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July
2013.
10.2. Informative References
[I-D.ietf-dhc-dhcpv6-privacy]
Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
considerations for DHCPv6", draft-ietf-dhc-
dhcpv6-privacy-00 (work in progress), February 2015.
[I-D.ietf-dhc-sedhcpv6]
Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure
DHCPv6", draft-ietf-dhc-sedhcpv6-06 (work in progress),
February 2015.
Authors' Addresses
Yiu L. Lee
Comcast
One Comcast Center
Philadelphia, PA 19103
U.S.A
Email: yiu_lee@cable.comcast.com
Lee, et al. Expires September 9, 2015 [Page 10]
Internet-Draft Secure Access Mechanism for DHCPv6 March 2015
Yong Cui
Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn
ZiLong Liu
Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: liuzilong8266@163.com
Linhui Sun
Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: lh.sunlinh@gmail.com
Lee, et al. Expires September 9, 2015 [Page 11]
