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

[神明達哉 <[e-mail]>]

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.

On Tue, Oct 13, 2015 at 11:57 AM, <[e-mail]> wrote:

> 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

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