Subject: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-07.txt

From: [email-masked]
Date: Mon, 23 Mar 2015 12:20:05 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

        Title           : Secure DHCPv6
        Authors         : Sheng Jiang
                          Sean Shen
                          Dacheng Zhang
                          Tatuya Jinmei
	Filename        : draft-ietf-dhc-sedhcpv6-07.txt
	Pages           : 23
	Date            : 2015-03-23

Abstract:
   The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
   DHCPv6 servers to pass configuration parameters.  It offers
   configuration flexibility.  If not being secured, DHCPv6 is
   vulnerable to various attacks, particularly spoofing attacks.  This
   document analyzes the security issues of DHCPv6 and specifies a
   Secure DHCPv6 mechanism for communications between DHCPv6 clients and
   DHCPv6 servers.  This document provides a DHCPv6 client/server
   authentication mechanism based on sender's public/private key pairs
   or certificates with associated private keys.  The DHCPv6 message
   exchanges are protected by the signature option and the timestamp
   option newly defined in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-sedhcpv6-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: 神明達哉 <[email-masked]>
Date: Mon, 23 Mar 2015 13:22:37 -0700

>     Filename        : draft-ietf-dhc-sedhcpv6-07.txt

This version includes the changes I proposed at:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg16369.html

More specifically, I've added the following paragraphs to Section 4:

   TOFU can be used by a client to authenticate a server and its
   messages.  It can be deployed without establishing a trust
   relationship between the client and the server.  Unlike the
   Reconfigure Key Authentication Protocol defined in [RFC3315], it can
   also be used for other DHCPv6 messages than Reconfigure, and the same
   single key can be used for all clients since the server does not send
   a secret in plain text on the wire.  Overall this will provide a
   reasonable balance of easy deployment and moderate level of security,
   as long as the risk of the attack window on the first use is
   acceptable.

   TOFU can also be used by a server to protect an existing DHCPv6
   session with a particular client by preventing a malicious client
   from hijacking the session.  In this case the server does not even
   have to store the client's public key or certificate after the
   session; it only has to remember the public key during that
   particular session and check if it can verify received messages with
   that key.  This type of authentication can be deployed without a pre-
   established trust relationship.

   If authentication has to be provided from the initial use, the Secure
   DHCPv6 mechanism needs some infrastructure such as PKI so the
   recipient of a public key or certificate can verify it securely.  It
   is currently a subject of further study how such an infrastructure
   can be integrated to DHCPv6 in a way it makes the deployment easier.

and this to Section 6.2:

   When the local policy of the recipient allows the use of TOFU, if a
   Public Key option is provided but it is not found in the local trust
   public key list, the recipient MAY accept the public key.  The
   recipient will normally store the key in the local list for
   subsequent DHCPv6 sessions, but it may not necessarily have to do so
   depending on the purpose of the authentication (see the case of
   authenticating a client with TOFU described in Section 4).

with some other minor cleanups.  I hope this version is closer to
something we can agree to.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Mar 2015 14:13:52 +0000

Hi,

For clients trusting servers, TOFU is fine for my use case. For servers to trust
clients, however, authentication is needed on first use. This means that the
server must have access to the public keys and certificates of all clients, but
the clients need not have public keys and certificates for servers nor for other
clients. So, the "PKI" is simply a common database that is accessed by all servers.

Is this model accommodated by the spec?

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: dhcwg [mailto:[email-masked]] On Behalf Of ????
> Sent: Monday, March 23, 2015 1:23 PM
> To: [email-masked]
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-07.txt
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: 神明達哉 <[email-masked]>
Date: Tue, 24 Mar 2015 07:38:26 -0700

At Tue, 24 Mar 2015 14:13:52 +0000,

> Is this model accommodated by the spec?

It may depend on what you mean by "accommodated", but I believe
nothing in this spec prohibits this type of usage model.  Clients will
use the "TOFU is okay" policy, while the server's policy will require
the verification of clients' public keys or certificates.  In any
case, details of the "PKI" regarding how it's used for a particular use
case are beyond the scope of this spec.

--
JINMEI, Tatuya