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]