Re: [dhcwg] Deployment consideration for SeDHCPv6

[Ralph Droms <[e-mail]>]

> On Jun 17, 2014, at 6:27 PM, 神明達哉 <[e-mail]> wrote:
> 
> At Tue, 17 Jun 2014 13:15:39 -0400,
> Ralph Droms <[e-mail]> wrote:
> 
>> 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?
> 
> In the second example, the client sends its public key in Solicit, and
> the server remembers it during the DHCP session starting from that
> Solicit.  The server uses the public key to authenticate any
> subsequent message from that client (or anyone claiming to be that
> client) for that DHCP session.  I said LoF (let alone full
> authentication) isn't needed because when the server accepts and
> remembers the public key sent in the Solicit, it doesn't do so for the
> purpose of authenticating the Solicit itself.  It only remembers the
> public key to confirm that subsequent messages of the session are
> certainly sent from the same client as the one sent the Solicit, and
> there's no "leap" here.

I see.  I missed the point that the messages still use the authentication option to prove that the messages come from the same source and to prove message integrity, but the source is not checked for authorization to use the server.

> 
> In the third example, I actually didn't say LoF isn't required.  Could
> the text read as if I did?

I reread the text.  You are right, it does not say LoF is not required.  I misread the text initially.

- Ralph




> 
> --
> JINMEI, Tatuya
> 
> p.s., I noticed one type in the text, a kind only non native English
> user would do: s/stuff/staff/ below:
> 
>>> 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.
> [...]
>>> 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.
> 
> if we use any part of my suggested text, please correct these > authors.