Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

[Sheng Jiang <[e-mail]>]

Hi, Jinmei,

In the common scenario that we expect, the leap of faith model is not deployed independent. In the deployment of secure DHCPv6 server, the server serves three types of clients: 1) full authenticated clients, 2) clients trusted by leap of faith model, 3) un-authenticated clients. Hence, the clients are in different class for limited resource assignment and access priority. It provides fine-grained client management.

Regards,

Sheng + Dacheng

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of 神明達哉
>Sent: Wednesday, May 07, 2014 11:35 PM
>To: Sheng Jiang
>Cc: Tomek Mrugalski; dhcwg
>Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May
>18
>
>At Tue, 6 May 2014 07:36:34 +0000,
>Sheng Jiang <[e-mail]> wrote:
>
>> >- In Section 6.2:
>> >
>> >   On the recipient that supports the leap of faith model, the number of
>> >   cached public keys or unverifiable certificates MUST be limited in
>> >   order to protect against resource exhaustion attacks.  If the
>> >
>> >  This is mainly concerned about servers, correct?  If so, I'm not
>> >  sure how severe this "attacks" are; DHCP servers generally need to
>> >  maintain some state for each client (unless that's stateless only
>> >  server) and would naturally already have some limitation on that
>> >  resource.  Shouldn't the general defense be enough for this
>> >  particular resource, too?
>>
>> The "MUST" here seems not proper. Let us replace is with "MAY". It makes
>this point optional and should address your concern.
>
>I don't think my main point is MUST vs MAY.  It's about a more
>general point of authenticating messages from clients to servers:
>
>- whether we really need (public key) authentication in that
>  direction, and if we do, why
>
>- also if we do, what's the commonly expected model of "trust anchor":
>  leap of faith or use of CA or something else, and if it's more
>  likely to be a weaker model like leap of faith (I suspect so, for
>  the direction of clients to servers), whether the motivation (1st
>  bullet) is worth the weaker security
>
>- and, if it's more likely to rely on leap of faith, what kind of
>  consideration is needed
>
>The discussion on caching the public keys is just a part of the third
>bullet.  What I'm missing in the current draft is more comprehensive
>and higher level discussions on all of these points.  It's far from
>obvious to me compared to authenticating messages from servers to
>clients.
>
>--
>JINMEI, Tatuya