Re: [dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

[Danny Mayer <[e-mail]>]

David W. Hankins wrote:
> On Thu, Nov 15, 2007 at 11:26:19PM -0500, Danny Mayer wrote:
>> Brian Utterback wrote:
>>> Interesting. I agree that a key needs to be specified somehow, but it
>>> is not clear to me how to do it. We have to assume that the client
>>> does not have the same NTP keys. However, we would like a way to
>>> specify a server and keys securely, so that the security of the
>>> network depends only on the security of DHCP. Again I am not up to
>>> date, *is* there a secure DHCP? If so, then how to get keys to the 
>>> clients becomes an issue.
> 
> Although DHCPv6 does have a signature verification mechanism, it does
> not encrypt carried configuration.
> 
> So unless you're transferring public keys for NTP, there's an exposure
> problem I'm not sure you're aware of.  Just making sure you know, I'm
> not familiar with the keys discussed in this context.
> 
I am aware of it, thanks. It was part of what I was trying to hilight.
> 
> Next, I want to make sure that your expectations of the services
> DHCPv6 can provide are set appropriately.
> 
> Others have pointed out DHCPv6's authentication mechanism uses shared
> secrets; there is also a similar mechanism for DHCPv4, RFC3118
> "Authentication for DHCP Messages" (which 3315 says its method is
> based upon).  You should know that this has not been well deployed in
> DHCPv4, and it shares very similar design features to RFC3315's
> authentication.  The primary problem is that for most networks in
> operation, "configure a shared secret on all of your clients" defeats
> the purpose of the "Dynamic" in DHCP.  If you have to manually
> configure all your clients with a key, why bother using DHCP at all?
> You may as well manually configure them all with the final
> configuration state and skip a lot of needless machinery.
> 

Well we are only responding to an effort to do this via DHCP. We cannot
say for sure that this is the best method to do this and obviously it's
not the only method. Of course you might say why bother with DHCP for
that matter?

> So although it can be done, no one actually does it.
> 
> I understand that 3315 authentication has precisely the same barrier,
> that the client's keys are distributed "out of band."  I have no
> reason to think that IPv6 makes operators more interested in manually
> configuring clients to obtain dynamic configuration state than they
> have been in IPv4.
> 
> This is surmountable I think, it's possible the authentication methods
> might be extended and improved to remove this barrier to adoption, but
> there have been zero drafts to date which attempt to do so.
> 
> So, expectations.
> 
> 
> Your expectations should be:  No one will use 3315 authentication as
> it is, and therefore you will not have a cryptographically secured
> means to deliver this information on real networks.  People will,
> however, take special care with their DHCPv6 protocol packets on their
> networks (firewalling, etc, just as many always have done in IPv4),
> and there exists the potential for improvement and actual deployment
> of cryptographic trust here at some future date.

Agreed.

There are a whole slew of issues regarding provisioning of a system
during the booting process (and other times) that need to be worked out.
Specifically the network configuration and booting order of network
configs for DHCP, DNS, NTP, syslog, SSH, SNMP, etc.

At some point we really need to sit down and thrash out how to do this
in a secure way, in what order that it makes sense, error conditions,
etc. I'm not sure what the DHCP folks have been discussing so I bring it
all up and you can tell us what's already been solved and how.

Danny

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg