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

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

At Thu, 8 May 2014 13:30:01 -0500,
Ted Lemon <[e-mail]> wrote:

> >>> - whether we really need (public key) authentication in that
> >>> direction, and if we do, why
>
> Public key authentication makes sense in both directions.   Servers
> may be configured to grant different access to clients that
> authenticate than to clients that don't.  Clients may have lists of

Okay, I can see that usage.

> servers that either are known to be legitimate, or that are known to
> have worked in the past (leap of faith).   Being able to
> discriminate between a good server and a rogue server using this
> mechanism is desirable.

I have no problem with this either.

My main concern is the combination of authenticating clients with the
leap of faith model.  This model isn't suitable for the "grant
different access" usage, since anyone can pretend to be an
authenticated client with that model.

> >>> - 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
>
> This seems to be out of scope for the current document, which just specifies a mechanism for authenticating transactions given that a key is known.   It's possible that this needs to be stated more clearly.   The reason (IMHO) why it's out of scope is that there are a variety of mechanisms that might make sense and that could be implemented.

I'm okay with separating such discussions outside of this document.
But then I'd personally like to see a "threat analysis" document
first (covering these points), not the other way around.  As a
believer of the YAGNI principle, I personally cannot be so
enthusiastic about defining/implementing something that just *might*
make sense somewhere.  Especially so, if we need to worry about a
security impact as mentioned in the security considerations section of
the draft.

> For instance, a DHCP server might give an unknown client an address in a walled garden where it could arrange to pay for service, and then its key would be known to the DHCP server and could be used to authenticate service in the future without requiring registration.

I'm impressed with your imagination:-) Although I'm not sure if this
example is persuasive enough, I see we can come up with some
*possible* usage of client authentication with leap of faith.

> >>> - and, if it's more likely to rely on leap of faith, what kind of
> >>> consideration is needed
>
> You mean in terms of risk assessments?

Considerations like the possibility of resource exhaustion attacks as
mentioned in Section 7 of the draft.

--
JINMEI, Tatuya