Securing DHCP with DNSSEC bourne public keys

Section 4.4 of defines the state machine for the DHCP client.

No changes to the transitions for this state. When the client sends the DHCP DISCOVER message, it MUST sign the request with its private key, including an authentication option in the DISCOVER message in an option as defined above. The client SHOULD cache the resulting signature such that it can retransmit it. (XXX - is there any value in this? The xid will change each time). The client MUST include its proposed fully-qualified domain name in a client FQDN, as specified in . The client MUST include a parameter request list option that includes the DHCP authentication option, and the Server Name option.

No changes to the transitions for this state. The client SHOULD prefer DHCPOFFERs that include a authentication option that are signed by keys that the client currently has cached. If no preferred offer is seen, then the client MUST select among the offers in a non-deterministic manner (ideally, random). This step is important so that a client that has been deceived into binding to the wrong DHCP server will have a chance to select a different server. A client SHOULD NOT assume that offers that do not include valid and verifiable signature options are exclusively preferred. There may be no DHCP security on the network in question, and attackers could keep the client from ever selecting the "real", unauthenticated server. (XXX - yet, if one can remember them all, one would prefer to try the offers with signatures first) Note that this behaviour differs from that described in point 2 of section 5.5.1 of . This is because a client may not be able to determine the authenticity of the offer until after it has connected to the network. Should an appropriate DHCP server key be pre-configured, or cached, then the behaviour is the same.

A new state called "Provisionally BOUND" MUST be added. The system will transition to this new state upon receipt of a DHCP ACK that contains a DHCP authentication option, and a DHCP Server name option. When sending the DHCP REQUEST to the server, it MUST also be signed. The DHCP REQUEST MUST also include the same client FQDN as was sent in the DISCOVER message. XXX - should the DHCP Decline be signed? I think so.

The provisionally bound state is operationally similar to the BOUND state. The timers should be recorded as with the previous state. Additional DHCP offers received should be discarded. The system should be sufficiently configured with the provided IP address such that DNS requests to the root name server(s) may be done. If the system is going to be configured with the a DNS server as specified in the Domain Name Server option of , and this name server is directly reachable, it may be reasonable to defer any additional system configuration until the BOUND state. Some systems may not provide such a "partially configured" state. In any case, if the system has any kind of system event that indicates that it is on the network, this event SHOULD be deferred until the BOUND state has been reached. Upon entering this state, after performing the partial configuration, the client MUST authenticate the DHCP ACK. To do this, if it does not already have the public key of the DHCP server, it must look it up. The client MUST lookup the KEY resource record (subtype DNSSEC) associated with the name provided by the server in its DHCP server name option. The DNS lookup SHOULD be done with DNSSEC enabled. {XXX - DHCP server name option. Is there such a thing? The original idea was to lookup the KEY record in the reverse map (in-addr.arpa/ip6.arpa), based upon the IP address in the server identifier. Ted suggested that we wanted to use FQDN, but I'm not sure where it will get stored. Do we need a new option} If the DHCP ACK can not be authenticated (either because the KEY can not be retrieved, the DNSSEC does not authenticate the key, or integrity check on the message fails), then the lease MUST be discarded. The client transitions back to INIT state, having sent a DHCPNAK to the server, and then halting the network. XXX - Do we go back and authenticate the DHCP OFFER?

There is a new transition from the Provisionally BOUND state. The only change in behaviour of this state is that when lease renewal occurs, the DHCP REQUEST SHOULD be signed. This is done even if the lease was not originally acquired through a signature, as it MAY be that the server will adopt security in the interum.

There is a new transition to the Provisionally BOUND state. If a DHCP ACK is received that has a DHCP Authentication option in it, then the client transitions to the Provisionally BOUND state rather than directly back to the BOUND state.

The system will transition to Provisionally BOUND upon receipt of a DHCP ACK that contains a DHCP authentication option, and a DHCP Server name option. The broadcast DHCP REQUEST SHOULD contain an authentication option, as with the one sent by state SELECTING.

Section 4.4 of defines the state machine for the DHCP client.

Upon receipt of a DHCP DISCOVER that includes an Authentication option of the type defined in this document, then it MUST verify that there is a provided client FQDN option, and that it is fully qualified. The server MUST then do a DNSSEC lookup on the provided FQDN, looking for a KEY resource record (sub-type DNSSEC). The server SHOULD cache this result for at least as long as the DHCP OFFER that will be made would be valid for. The server MAY cache it for as long as the DNS time to live value. Having found a valid KEY (with the matching keyid), the server MAY verify the signature at this point. If the server feels that it is overloaded or under denial of service attack, it may defer authentication at this step. If appropriate authentication material is not found, then the request SHOULD be treated as if none were present. If authentication material was found, but the signature check fails, then the message MUST be discarded. Audit entries SHOULD be made, including the keyid that was used, and the computed vs actual MD5 checks.

Upon receipt of a DHCP REQUEST that includes an Authentication option of the type defined in this document, then it MUST verify that there is a provided client FQDN option, and that it is fully qualified. The server MAY have already cached the KEY record associated with this FQDN. If it has not, then it MUST lookup the record again, as described above. The signature MUST be authenticated in this step. The server MAY then insert the provided FQDN into the reverse map using dynamic update, as described in . If the client has requested it, via the DHCP IPSECKEY option, then the server should also insert the public key taken from the FQDN into the reverse map.

XXX - unclear yet.