Re: [dhcwg] Deployment consideration for SeDHCPv6

[Sheng Jiang <[e-mail]>]

Thanks Ralph for confirmation. Thanks Jinmei for helpful input. We have included these text in the ongoing update version.

Best regards,

Sheng

>-----Original Message-----
>From: Ralph Droms [mailto:[e-mail]]
>Sent: Wednesday, June 18, 2014 1:16 AM
>To: 神明達哉; Sheng Jiang
>Cc: Lemon Ted; dhcwg
>Subject: Re: [dhcwg] Deployment consideration for SeDHCPv6
>
>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