Re: I-D ACTION:draft-ietf-dhc-authentication-03.txt

[Thomas Narten <[e-mail]>]

>   Appendix A - Key Management Technique
>
>   To avoid centralized management of a list of random keys, suppose K for
>   each client is generated from the pair (client identifier, subnet
>   address), which must be unique to that client.  That is, K = MD5(MK,
>   unique-id), where MK is a secret master key and MD5 is some encoding
>   function.
>
>   Without knowledge of the master key MK, an unauthorized client cannot
>   generate its own key K.  The server can quickly validate an incoming
>   message from a new client by regenerating K from the client-id.  For known
>   clients, the server can choose to recover the client's K dynamically from
>   the client-id in the DHCP message, or can choose to precompute and cache
>   all of the Ks a priori.

In the first paragraph, it seems to me that you don't want the subnet
address to be part of the computation, since that would change the key
if the subnet was renumbered. Earlier in the draft (Section 4.3), it
is explicitely stated that the same key can be reused even if the client
configuration changes, including its address.

How important is it to have the subnet number included? Presumably,
the concern is to prevent different clients/interfaces (on different
subnets) that happen to have the same link-layer address end up using
the same key, allowing one client to masquerade as the other.

For typical LAN links, MAC addresses are unique enough not to need to
worry about this, IMO.

Thomas