Re: [dhcwg] Deployment consideration for SeDHCPv6

[Ralph Droms <[e-mail]>]

Sheng - I think Jinmei-san's suggested text is very good, although I do have one question about authentication on a server.  The text includes examples for the various scenarios, which addresses my primary concern.

Jinmei-san - I have one question about your text.  Can you explain in a little more detail how the second and third examples of authentication on a server work, in which you say the server only has to remember the client's public key so neither full authentication nor LoF is required?

- Ralph

On Jun 6, 2014, at 2:51 PM 6/6/14, 神明達哉 <[e-mail]> wrote:

> 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