Re: [dhcwg] Deployment consideration for SeDHCPv6

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

At Thu, 5 Jun 2014 09:38:41 +0000,
Sheng Jiang <[e-mail]> wrote:

> The below text is the proposal from SeDHCPv6 authors in order to
> clarify the applicability. We plan to add these text, of course
> after reaching consensus in the mail list, into the next update
> version. Any comments are appreciated.

The proposed text seems to be almost a minor revise of my outline I
showed on the list, so I guess Ted would still complain that it's
incomplete:-).  I'm not sure how much we should be "complete" in this
document (especially if we wouldn't like to make the document a
kitchen sink), but I'll show my own try below.  Not intending to push
this particular text, but I thought I'm responsible for providing
something more concrete as someone who keeps raising the point.

X. Deployment consideration

This document defines two levels of authentication: full
authentication based on certificate or pre-shared key verification and
weaker authentication based on leap-of-faith (LoF).  As a mechanism,
both levels can be applied on servers and clients.  Depending on the
details of expected threats and other constraints, some cases may have
limited applicability.  This section discusses such details.

X.1 Authentication on a client

For clients, DHCP authentication generally means authenticating the
server (the sender of DHCP messages) and verifying message integrity.

This is satisfied with full authentication.  Due to the configuration
overhead, however, full authentication may not always be feasible.  It
would still be viable in a controlled environment with skilled stuff,
such as a corporate intranet.

If LoF is used, message integrity is provided but there is a chance
for the client to incorrectly trust a malicious server at the
beginning of the first session with the server (and therefore keep
trusting it thereafter).  But LoF guarantees the subsequent messages
are sent by the same server that sent the public key, and therefore
narrows the attack scope.  This may make sense if the network can be
reasonably considered secure and requesting pre-configuration is
deemed to be infeasible.  A small home network would be an example of
such cases.

For environments that are neither controlled nor really trustworthy,
such as a network cafe, full authentication wouldn't be feasible due
to configuration overhead, while pure LoF, i.e. silently trusting the
server at the first time, would be too insecure.  But some
middleground might be justified, such as requiring human intervention
at the point of LoF.

X.2 Authentication on a server

As for authentication on a server, there are several different
scenarios to consider, each of which has different applicability
issues.

A server may have to selectively serve a specific client or deny
specific clients depending on the identify of the client.  This will
require full authentication, since if the server allows LoF any
malicious user can pretend to be a new legitimate client.  Also, the
use of certification wouldn't be feasible in this case, since it's
less likely for all such clients to have valid (and generally
different) certificates.  So the applicable case may be limited, but a
controlled environment with skilled stuff and a specifically expected
set of clients such as a corporate intranet may still find it useful
and viable.

A server can prevent an attack on the DHCP session with an existing
client from a malicious client, e.g., by sending a bogus Release
message: the server would remember the original client's public key
at the beginning of the DHCP session and authenticate subsequent
messages (and their sender).  Neither full authentication nor LoF is
needed for this purpose, since the server does not have to trust the
public key itself.  So this can be generally used for any usage of
DHCP.

A server can prevent an attack by a malicious client that pretends to
be a valid past client and tries to establish a new DHCP session
(whether this is a real security threat may be a subject of debate,
but this is probably at least annoying).  This is similar to the first
scenario, but full authentication may not necessarily be required;
since the purpose is to confirm a returning client has the same
identify as a valid past client, the server only has to remember the
client's public key at the first time.  So LoF can be used at the risk
of allowing a malicious client to mount this attack before the initial
session with a valid client.  An uncontrolled, but reasonable reliable
network like a home network may use this defense with LoF.

--
JINMEI, Tatuya