Subject: [dhcwg] missing pieces for the Secure DHCPv6 draft

From: 神明達哉 <[email-masked]>
Date: Tue, 13 Oct 2015 11:57:57 -0700

I'm resuming an old thread with renaming the subject as it seems to
require discussions on broader topics.  I'll begin with this message
from Francis: https://mailarchive.ietf.org/arch/msg/dhcwg/82ZGOz7DGBZf4hSvcIaTC8-iK4w

On Tue, Oct 6, 2015 at 12:45 PM, Francis Dupont
<[email-masked]> wrote:

> BTW I can see 2 "sure" senarios for deployment:
>  - secure DHCPv6 as a complement of SEND. In this case all the PKI
>   issues are already solved at the SEND level at the protocol level
>   (i.e., a router (e.g., the router which puts the M/O bit(s) in RAs
>   asking for DHCPv6) already provided the certificate validation stuff
>   (e.g., certificate chain, crls, etc)) and at the organization level
>   (e.g., X.509 prefile).
>
>  - static pre-configuration of credentials. In this case the environment
>   is closed and everything was installed offline before secure DHCPv6 use.
>   At the limit, it is enough to verify the "right" certificate (or raw key)
>   is used. Using the draft terminology, clients are configured with the
>   server certificate/key and the server has a table matching each client
>   with the corresponding certificate/key (BTW it is a common way to perform
>   authorization from a PKI): this is the "local trust certificate list".

Based on some off-list discussions, I've realized that we were
required to provide more background discussions than deployment
scenarios.  In my understanding we'll need to cover the following
points:

1. threat analysis on DHCPv6 security (especially in the context of sedhcpv6)
2. specifically how the two models of sedhcpv6 can be used to address
   these threats
3. some consideration on DHCP-specific difficulty such as the chicken
   and egg problem of how to get/validate the server certificate
   before starting a DHCPv6 session

For point #1 I found an expired draft for DHCPv4 authentication seems
to be a pretty good reference already:
https://tools.ietf.org/html/draft-ietf-dhc-v4-threat-analysis-03
We can probably just borrow some key parts from this document.

For point #2 and #3, I think we'll need to use lessons learned so
far.  Specifically:

- We should be honest: we cannot simply and casually say "this is out
  of scope" for difficult related issues (these are generally related
  to key distribution problems).  If something is really difficult and
  still open, we should clearly state that, and, if necessary, may
  have to consider remove some features from the current spec.
- We need to be realistic: we know speculative deployment scenarios
  won't satisfy a sufficient number of people.  As we don't have a
  good precedent on deployments, this will be difficult.  But we'll
  need to try to find a few very simple scenarios that most of us can
  hopefully agree on, and we should honestly say we don't yet know
  scenarios for areas where we can't find such a simple case.  (And,
  if necessary, we may have to remove some features).
- We shouldn't oversell the spec: this is a corollary of the above
  two.  Like in the case of applicability of TOFU, if we cannot find a
  realistic explanation of how we can use some of the described
  feature, we should rather drop it than try to make an unconvincing
  argument to insist it's necessary.  If, as a result of this, the
  spec becomes too small to matter, although I hope this won't be the
  case, then it would mean it's really premature to discuss this
  mechanism.  In that case we should conclude we drop it this time.

According to these observations, I suspect the "compliment of SEND"
scenario looks too unrealistic, given SEND itself hasn't been deployed
at all.  It may be an interesting research topic, but I suspect it
won't help advance the sedhcpv6 document.

Regarding the second, I think we'll need to explain either:
- how specifically this will decrease deployment costs compared with
  statically pre-configuring shared secrets in more detail, or
- this won't be that different in terms of deployment costs, but would
  be considered a bit more securer in that client secret won't have to
  be stored in the server

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 28 Oct 2015 16:57:08 -0700

This is a (delayed) continuation of my previous post:
https://mailarchive.ietf.org/arch/msg/dhcwg/oHHOL4Q9dgghLUyoZAGcpuBRzTM
I'm including Charlie Kaufman as suggested by Brian (Haberman) as the
shepherding AD.

> https://tools.ietf.org/html/draft-ietf-dhc-v4-threat-analysis-03

Here are some thoughts of mine along with this observation.  I also
discussed this matter with a PKI expert offline, and applied the
result.  I don't know if it adequately addresses main concerns raised
so far, but if it does at least to some extent, I'm happy to provide
some more complete text so we can use it for a revision of the draft.
In any case, any feedback would be appreciated.

Threat analysis: some of the threats described in
dhc-v4-threat-analysis seem to be applicable to our discussion:

1. Refusal to Configure Clients (by a rouge server)
2. Client misconfiguration with bad configuration (by a rouge server)
3. Impersonating Clients (by a rouge client).  There are some variants
  of this type of threat
  A. obtain addresses (or other resources) illegitimately even if some
     weak restriction (such as per-DUID) applies
  B. simulate many clients to consume all (or too many) available
     addresses.  Could be either a DoS against the server or other
     clients.  Consuming *all* addresses may not be so trivial in case
     of DHCPv6 with a large address pool, but it can at least work as
     a DoS against the server.
  C. create havoc on the subnet by injecting fake messages on behalf
     of other clients, prematurely releasing or declining their
     addresses.

It would be obvious that crypto-based authentication prevents these
threats, whether it's sedhcpv6 (public key based) or the existing
delayed authentication protocol described in RFC3315 (shared secret
based).  Comparing with the latter, sedhcpv6 has the following
advantages:

- In case of authenticating the server (by clients), we only have to
  manage one key pair.
- If we use PKI and when the server or a client is compromised, then
  we can use the PKI's revocation framework to invalidate the
  now-compromised key.
- Safer in such a scenario as that clients' keys cached/stored in the
  server are silently stolen (stolen shared secret is an immediate
  threat; a stolen public key itself can't be used for an attack by
  itself)

Regarding the second point, revocation of the server key/certificate
can be tricky because of the chicken-and-egg type of problem, but one
possible resolution would be that the client first tries to validate
the server key/certificate once the address is assigned before using
the address for any other purpose (implementing this on an actual
system may also be tricky, but this should be possible at least in
principle).  Also, when we say "if we use PKI", we can't ignore its
deployability.  That's the subject of the next topic.

Key distribution: whether it's shared secret based or public key
based, key distribution is a big issue.  dhc-v4-threat-analysis shows
some possibilities in its Section 6.3, such as using a security token
device or with help of other protocols like EAP or RADIUS (Francis's
hint of using SEND would also be one such approach).  While these may
not be completely unrealistic, I'm afraid any detailed discussions on
specific approaches will be largely speculative.  My personal
suggestion right now is to just briefly refer to these possibilities
and honestly say we really don't know if they can be deployable at
this moment even though we know this is a critical point for sedhcpv6
(or any other authentication mechanism for that matter) to be
deployable, too.

About the use of TOFU: IMO we should clarify that the applicability of
TOFU for authentication is quite limited rather than try to oversell
it.  A couple of cases for TOFU I can imagine are:
- Initial setup for a home network
- A weak form of mitigation against DHCPv6 session hijacking (like
  threat 3-C above)
Regarding the latter, it's obviously incomplete since the possible
hijacker may be there on the first use.  But in this environment we
are not trying to fully authenticate clients anyway, I think it's a
reasonable to try to protect some existing clients with no deployment
cost.

For the purpose of the sedhcpv6 draft, if usability issues of TOFU
still continues to be blocking, I think we can simply remove it from
the draft as an alternative.

--
JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Sat, 31 Oct 2015 02:02:42 +0100

In your previous mail you wrote:

>  hint of using SEND would also be one such approach).

=> note that SEND is used (please don't confuse visible with ostensible :-)
and it solves all the gory PKI details (same than for "everything pre
configured" but with an already deployed base. Unfortunately I don't
know public documents about SEND deployments/recommendations (I am
afraid they are "restricted not Internet" :-).

>  the draft as an alternative.

=> perhaps the solution is to move all deployment/applicability stuff
from the secure DHCPv6 "mechanisms" I-D so it can be published as soon
as the threat model is complete?

Thanks

[email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Sun, 1 Nov 2015 13:20:22 +0900

At Sat, 31 Oct 2015 02:02:42 +0100,

> as the threat model is complete?

That's a possibility and in a sense cleaner approach.  If the wg now
agrees with that I'm fine with that, too, but I'd note we once
rejected the idea.

--
JINMEI, Tatuya