Re: [dhcwg] on use case discussion for draft-ietf-dhc-sedhcpv6

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

At Wed, 4 Mar 2015 13:36:48 -0500,
Ted Lemon <[e-mail]> wrote:

> > Okay, then, going back to my novice's question, what's the difference
> > in terms of deployability and/or security between the above one and
> > the following one?
>
> Your proposed example requires that the user somehow convey the
> randomly-generated secret-to-be-shared to the authentication
> database through the registration process.   Since the client device
> has no way of anticipating what back-end registration process will
> be used, this cannot be automated.

Correct, but isn't it the same for the client to convey the public key
to the authentication database through the registration process?

> It also requires that the authentication database share that secret
> with the DHCP server.

Correct, but what kind of threat would we worry about in that case?
Whether it's shared secret or client's public key, if either the
authentication database or the DHCP server itself is compromised, then
the attacker can successfully pretend to be a valid client, right?

> So this would only work in contexts where it's okay for the DHCP
> server to be able to know the contents of the shared secret
> database, and it would only work in cases where the shared secret
> registration process works as you have described it.

But isn't it the same for a public-key based mechanism?  "this would
only work in contexts where it's okay for the DHCP server to be able
to know the contents of the public key database, and it would only
work in cases where the public key registration process works in some
way".  And, it looked to me that any specific flow for a public-key
based scenario can have a shared secret-based variant at a comparable
deployability cost and security level (regarding the latter, it would
certainly be better if we don't have to store a "secret" in multiple
places in general, but in our scenario if the key database or the DHCP
server is compromised it seems to be equally fragile for a public
key-based system as I asked in the second "Correct, but") - or I
misunderstand something fundamental, which is probably the case, so
I'd like to know an example flow where public key-based mechanism
works perfectly but a shared secret-based one doesn't.  And, in that
sense, I'm not sure how I interpret this:

> E.g., it would not work with Kerberos.

Do you mean it doesn't work as Kerberos itself being the shared secret
mechanism (like draft-hornstein-dhc-kerbauth), or do you mean some
public key based mechanism will somehow work well with Kerberos?  If
it's the former, I already agreed in my previous sense, but this
doesn't answer my question.  If it's the latter, which specific flow
do you have in your mind?

--
JINMEI, Tatuya