Rfc3118
5.4 Key utilization
Each DHCP client has a key, K. The client uses its key to encode any
messages it sends to the server and to authenticate and verify any
messages it receives from the server. The client's key SHOULD be
initially distributed to the client through some out-of-band
mechanism, and SHOULD be stored locally on the client for use in all
authenticated DHCP messages. Once the client has been given its key,
it SHOULD use that key for all transactions even if the client's
configuration changes; e.g., if the client is assigned a new network
address.
Each DHCP server MUST know, or be able to obtain in a secure manner,
the keys for all authorized clients. If all clients use the same
key, clients can perform both entity and message authentication for
all messages received from servers. However, the sharing of keys is
strongly discouraged as it allows for unauthorized clients to
masquerade as authorized clients by obtaining a copy of the shared
key. To authenticate the identity of individual clients, each client
MUST be configured with a unique key. Appendix A describes a
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 [6],
subnet address, e.g., 192.168.1.0), which must be unique to that
client. That is, K = MAC(MK, unique-id), where MK is a secret master
key and MAC is a keyed one-way function such as HMAC-MD5.
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.
By deriving all keys from a single master key, the DHCP server does
not need access to clear text passwords, and can compute and verify
the keyed MACs without requiring help from a centralized
authentication server.
To avoid compromise of this key management system, the master key,
MK, MUST NOT be stored by any clients. The client SHOULD only be
given its key, K. If MK is compromised, a new MK SHOULD be chosen
and all clients given new individual keys.
Remplacer la LiveBox par un routeur