A Secure Way to Combine IPsec, NAT & DHCP - Computer Network Security - page 109

DHCP itself does support neither an access control for a proper user nor the
mechanism with which clients and servers authenticate each other.
In [6] we have proposed an extension to DHCP protocol called E-DHCP (Ex-
tended-Dynamic Host Configuration Protocol) in order to allow a strict control on the
equipments and users through a strong authentication process. [6] defines a new
DHCP option (fig.1) based on the use of certificates.
The definition of new DHCP options [11] is possible because the options field en-
visages the implementation of new options [10].
This option provides simultaneously the authentication of entities (DHCP client
and server) and DHCP messages. The technique used by this option is based on the
use of public key cryptography [17], X.509 identity certificates [15] and AC (Attrib-
ute Certificates) [12]. On the other hand, E-DHCP allows an improved access control
to the DHCP system by using AC.

Bits :
0 1 2…. 7 8 9 …....15 16 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .

URIIdentityCertificate URIAttributeCertificate
AuthenticationInformation

Code Length Flag

Fig. 1. Authentication option structure

In E-DHCP proposal (fig. 2), DHCP server is leaned on an AA (Attribute Author-
ity) server [12] that creates a client Attribute Certificate (client AC), which ensures
the link between the client identity certificate and the allocated IP address. Therefore,
the use of AC confirms client's ownership of the allocated IP address.

Attribute Authority

E-DHCP Server DHCP Server

Fig. 2. E-DHCP Server

In a typical E-DHCP scenario (fig.3), the client broadcasts a DHCPDiscover mes-
sage on its local physical subnet. This message includes the proposed authentication
option.
The client specifies its identity certificate URI (Uniform Resource Identifiers) [2]
in DHCPDiscover message, then in response, the server specifies its identity certifi-
cate URI in DHCPOffer message.
In all the transactions, on one side the sender (client/server) encapsulates the value
of the encrypted signature of DHCP message, and on the other side, the corresponding
receiver (server/client) checks signature's authenticity.