Certificate-Based Authentication for DHCP

Glenn Glazer, Cora Hussey, Roy Shea

March 20, 2003

Abstract available resources. This could be done ei-

ther with the intent to prevent other clients
In this paper, we describe and explore multiple from obtaining addresses, or with the intent
methods of DHCP authentication. We develop a to simply steal a single “free” address from
new type of authentication, CBDA, using certifi- the provider.
cates, we explain the implementation of an ex-
isting protocol, Delayed Authentication, to au- For all of these problems, a solution would be
thenticate via shared keys, and we demonstrate to authenticate both the client and the server.
how the certificate-based authentication design If the server had the ability to confirm its trust
improves upon and can be implemented from the of the client, it could confirm, (to a high degree
shared key design. In addition, we will discuss of confidence,) that the client was not, in fact,
and give examples of why certificate-based au- a rogue client, and vice versa for the client au-
thentication for DHCP potentially adds ease and thenticating the server.
flexibility to obtaining out-of-band key knowl- Many different ideas for how DHCP should
edge. be authenticated already exist. Most of these
ideas existed, developed, or disappeared through
1 Introduction IETF discussion and work. Some include cryp-
tography, some do not. The main methods that
The DHCP protocol has a number of security currently exist or that have been previously con-
shortcomings. When a client contacts a DHCP sidered are:
server to obtain an IP address to operate on a
network, both the client and the server are forced 1. Token Authentication [3]
to assume many potentially untrue things. Since This involves sending a token such as a
these security concerns have been well-defined plaintext password from the client to the
throughout the development of DHCP as well server to identify the client.
as other authentication protocols, we list them
here: 2. Delayed Authentication [3]
This involves a-priori of a shared key setup
◦ The DHCP server may be a rogue server. between client and server, and the authen-
This could result in improper network IP ticity of the DHCP messages is confirmed
address or no addresses at all being released using both an index to that key and a hash
to clients, and the clients would have few of the packet using that key. This will be
graceful ways to recover. fully described in Section 2.

◦ The client may be a rogue client. 3. DHCP Authentication via Kerberos V [6]
This could result in the rogue client im- This particular method of authenticating
properly using up IP addresses or flooding via Kerberos V only authenticates the
the servers with packets, thus draining the client, and involves communication with the

1
 Kerberos server in addition to the standard the progression of a successful DHCP exchange,
DHCP communication. and then will describe other possibilities. The
terms used in this section are:
We have designed a new method of authenti- K – The key known by Client and Server
cation for DHCP, called Certificate-Based DHCP
SID – The Secret ID used to look up K
Authentication or CBDA, and we have designed
it to be added to the DHCP Authentication pro- KMAC – Packet hash encrypted with key K
tocol suite [3]. The main benefit of using CBDA Replay – Replay attack prevention data
would be the ease and flexibility of using certifi- For both Delayed Authentication and CBDA,
cates instead of the difficulty of obtaining and authentication information is passed in each
using shared keys across multiple networks. We DHCP packet as an option. Options are pieces
will expand on the benefits, the structure, and of information that are added on to the end of
the implementation in this paper. a DHCP Packet after the DHCP Header. There
Section 2 explains what Delayed Authentica- can be many options in one packet for many dif-
tion is, how it works, and what the issues of ferent purposes, but they all must be less than
its use of shared keys are. Section 3 describes 255 bytes long. Options over that length must
CBDA, the surrounding use of certificates, and be split and then reassembled by the receiver.
related implementation topics. Section 4 gives For more information on passing options, split-
a multi-example comparison of CBDA and De- ting options, and using options in DHCP, please
layed Authentication. Section 5 describes poten- see the corresponding RFCs [1] and [9]. The ad-
tial future work, and Section 6 contains our con- vantage of using options rather than additional
clusions and what we learned from the project. packets is that the DHCP protocol remains un-
changed and the authentication exchange occurs
within the DHCP exchange.
2 Delayed Authentication
The specification for DHCP Authentication
which has been more formally designed and ac-
cepted than many of the others comes from
the IETF [2]. The more secure and interest-
ing method within RFC 3118 is known as De-
layed Authentication. Delayed Authentication
authenticates both a DHCP Client and a DHCP
Figure 1: DHCPDISCOVER Message
Server to each other using a shared symmet-
ric key known to both parties before any DHCP
In the DHCPDISCOVER message, the Client
communication. In addition, the Server and
broadcasts or multicasts the packet with the De-
Client have agreed on a common identifier that
layed Authentication option to known servers a
can reference that secret key without actually
request for a DHCP lease. In this authentication
sending it over the wire.
step, the Server looks up K using SID.

2.1 Protocol Overview

This section describes the protocol itself, as out-
lined in RFC 3118 [3], Section 5. The descrip-
tion should better allow us to describe the differ-
ences between this protocol and the Certificate
Authentication of our design, as well as to show
how one builds upon the other. We will first give Figure 2: DHCPOFFER Message

2
 In the DHCPOFFER message, the Server re- by providing the time or a nonce, and hashing
sponds with an offer of a lease even though it that as part of the message.
has not confirmed the identity of the Client. To Due to these two reasons, authentication can
confirm the identity of the Server to the Client, be assured with a high degree of certainty. If au-
the packet includes a hash of the packet signed thentication is not successful, however, Delayed
with K referenced by SID. Authentication leaves it to the implementer to
decide what to do. If the DHCP exchange itself
is not successful, Delayed Authentication fails as
any other DHCP implementation would.

2.2 Implementation
We chose to implement Delayed Authentication
on the open-source and free DHCP codebase de-
veloped the Internet Software Consortium [7].
Figure 3: DHCPREPLY Message This made sense since the author of many of the
DHCWG [2] RFCs also wrote the the ISC code-
In the DHCPREPLY message, the Client con- base, and the codebase appeared to be the only
firms its identity by signing the new hash of the free and open-source C distribution available.
DHCPREPLY packet with K. That way, the sig- The ISC DHCP distribution also includes
nature proves that the Client knows K as well. an API to set up remote management for a
This packet is also sent to other servers who of- DHCP Server. Since the remote management re-
fered the leases which the Client wants to turn quires authentication, the ISC codebase includes
down. the Digital Signature Toolkit (DST, [10]) from
Trusted Information Systems, now named Net-
work Associates. We used this toolkit for signa-
tures, hashing, and verifying signed and hashed
information.
Our implementation contains the basic De-
layed Authentication functionality. We did not
specify alternate key management techniques,
Figure 4: DHCPACK Message or allow the same distribution to prefer and
choose between non-authenticated and authenti-
In the DHCPACK message, the final K-signed cated DHCP. However, the implementation fully
hash comes from the Server along with confir- implements the core components of Delayed Au-
mation that the lease acceptance has been imple- thentication as specified in RFC 3118.
mented and the Client may use the configuration To use the authentication option, the hash
in the lease. method and other configuration items are stored
in the configuration file. This method of option
The packet exchange above describes a suc-
management and specification was recommended
cessful exchange – one where the Server and the
by Ted Lemon [8] from the ISC. The following
Alternate Server are both valid servers, and the
lines added to the configuration file enable and
Client is a valid client. Both the Client and
require authentication:
Server are assured that the other is, in fact, who
they claim to be because: send authenticate [HEX STRING];
(a) Both have knowledge of the secret key K require authenticate;
(proved by the signing of the hashes with it) [HEX STRING] is a 32-byte hex list. Each hex
(b) Replay attacks are made much more difficult member is separated by a colon, and the entire

3
list is written as one continuous line, for example, multiple shared secret keys can quickly become
as 0:0:...:0:0. It has five main components: cumbersome.
Hash Type – 1 for HMAC MD5 This is not a comment on the validity of the
protocol itself. As seen in Section 2.1, the De-
RDM – 1 or 0 for Replay type
layed Authentication protocol is secure, com-
Replay – 0:0:0:0:0:0:0:0 for Replay space pact, and usable. The key distribution and man-
SID – 0:0:0:0 for Secret ID space agement requirements, however, may not be that
MAC – 0:...:0 (16 long) for Hash space way in practice.
[HEX STRING] would then be written in order as:
Hash Type:RDM:Replay:SID:MAC 3 CBDA
Which results in the full 32 hex member, colon
separated string. To complement the functionality of Delayed Au-
This section would not be complete without thentication, we propose a new protocol type
at least one comment on the difficulty of adding for DHCP Authentication called CBDA, or
security to an existing codebase and protocol Certificate-Based DHCP Authentication. We in-
which were not originally designed with security tend CBDA to provide more flexibility in DHCP
in mind. For a more in-depth discussion of simi- Authentication, and to provide an alternative
lar issues, and for more information on our opin- method of key management which should be eas-
ions concerning the implementation, please see ier to implement.
Section 6.1. The following sections will provide our mo-
tivations for using certificates (Section 3.1), an
overview of the protocol (Section 3.2), implemen-
2.3 Issues tation methods (Section 3.3), some real-world
The main issues of Delayed Authentication are examples of using and managing certificates for
key distribution and key flexibility. Neither of Certificate Authentication (Section 3.4), and is-
these affect the security of the protocol, but both sues with the Certificate Authentication protocol
have the potential to affect the applicability of itself (Section 3.5).
actually using the protocol in practice.
Delayed Authentication relies on shared cryp- 3.1 Motivations
tographic keys being already known by the client
Once we determined the potential need for a
and by the server. This is one of the major draw-
DHCP authentication protocol that used a dif-
backs to using shared keys – the distribution of
ferent method of key distribution and manage-
them, though complicated, often gets left to the
ment, we then had determine what method of
implementer or sysadmin. The RFC itself at-
authentication would be better. We set the fol-
tempts to remedy this and suggests using a mas-
lowing standards for the protocol:
ter server key with multiple client keys [3] to sim-
plify the magic of key distribution, but this can ◦ It must mutually authenticate both the Client
decrease the security of the design. and the Server
The other disadvantage to using shared keys
becomes apparent when the client changes net- ◦ It should work with a minimum of keys over
works. This will become increasingly common multiple networks
as portable work computers authenticate them- ◦ It should require a minimum of key distribu-
selves on a corporate server, and are then later tion difficulty in general, as well as to work
used to telecommute from a DHCP-based home over multiple networks
LAN. Different networks should require different
keys, and this introduces a new issue with shared ◦ It must be as or more secure than Delayed
key management: the key-chain. Management of Authentication, i.e. it must use encryption

4
 rather than plaintext and protect against re- mostly not applicable to the DHCP packet ex-
play attacks change since they are intended for extended
transmissions rather than a few negotiation
◦ It must use well-known, commonly used, and packets.
well-tested security structures, keys, and al-
gorithms
3.2 Protocol Overview
◦ It should more or less follow the same format At a high level, the CBDA protocol involves
as the other two protocols defined in DHCP sending X.509 certificates or certificate chains
Authentication [3] so that it may aid the with a common signer as an option in the
protocol, not replace it DHCPDISCOVER and DHCPOFFER packets,
and then sending only signed hashes of the pack-
We then determined what well-known and ets in the DHCPREQUEST and DHCPACK
tested security formats would apply to DHCP. packets.
The options that we found were: The CBDA protocol works in the same fashion
as Delayed Authentication above. That is, the
DSSA/SPX: A valid protocol that fulfilled Client and Server send authentication informa-
most of the requirements above [5]. The only tion in an option within each DHCP packet and
drawbacks were that, although prevalent in aca- the DHCP protocol itself remains unchanged.
demic texts, there seemed to be only one dis- For more information on options, see Section 2.1
tribution of it available, and that distribution or the RFCs [1], and [9].
could not be found to be in known use. Further-
This section will first present the section defi-
more, the inclusion of a third-party authentica-
nitions within the option, then the option struc-
tor would have prevented the new protocol to
ture itself, and then an example of a successful
follow the same format as the other two DHCP
DHCP exchange between a Client and Server.
Authentication protocols.
The option sections are:
Kerberos: This seemed to be a viable option, Code – Option Code (90, for DHCP Authentica-
especially since work had already been done to tion)
use Kerberos with DHCP [6]. But we rejected
Length – Length of the entire option
it on the basis that it only easily identifies the
client and does not provide protection from rogue Protocol – Authentication Protocol (2, for
servers. In addition, the complexity of commu- CBDA)
nicating between the Kerberos server and the Algorithm – Hash/encryption algorithm (RSA-
DHCP server would make it unlikely to follow MAC or DSA)
the format of the other two DHCP Authentica- RDM – Replay Detection Method (0 for time, 1
tion protocols. for increasing nonces)
X.509 Certificates: Our chosen method. We Replay – The time or the nonce
determined that certificates allow straightfor- Key ID Type – Type 0 (509 CERT CHAIN), Fu-
ward key management and easy switching be- ture values could expand to PGP, etc.
tween multiple networks. X.509 provided a good Key ID Length – Length of the entire key
certificate standard.
Key ID – The certificate chain itself
Others: These included SESAME, bootstrap- Authenticator – Signed or encrypted hash of
ping a shared key off of a public key exchange entire packet except hops and giaddr – both of
and other methods of key exchange such as which are in DHCP main packet [1] and both
Diffie-Hellman, and a few others. These were of which are changed during the transit of the

5
packet – and the Authenticator itself. Those The option structures for DHCPREQUEST
three fields are set to 0 for hashing. and DHCPACK assume that the Server and the
Client both retain (at least for the duration of
The above option contents come together to the particular DHCP exchange and lease) the
form the CBDA option formats. Note the ad- public key contained within the certificate chain
dition of the Key ID and related certificate in- of the other. Because of this, they can recog-
formation, and also note that the Authentica- nize each other, associate the public key with
tor Hash and Replay Detection are retained from the particular Client or Server, and verify the
Delayed Authentication: signed hash at the end of the options. That way,
the certificates do not need to be re-sent. The
public keys can be retained with lease informa-
tion, or they may be indexed in an association
table addressed by either unique information in
the DHCP header, or a similar Client or Server
identifier.
Note also that if the Server wishes to retain
lease information for an authenticated Client
to be re-used in the INIT-REBOOT or other
state [1], the Server must also retain the public
key for the Client along with the IP address and
other configuration information.
Now, as in Section 2, we will give an example
Figure 5: Option structure for DHCPDIS- of a successful packet exchange. Previous to the
COVER, DHCPOFFER, and DHCPINFORM packet exchange, the Server and the Client have
messages the following information:

The option structure for the DHCPDIS- Client:

COVER and DHCPOFFER ensures that the ◦ Lc , a list of signing authorities the client trusts
certificates authenticating the client and the ◦ Kc , the public key for the Client
server are sent out in the first two DHCP pack- ◦ Ec , the private key for the Client
ets, even if the nonces for the replay protection ◦ Cc , a certificate (chained) containing Kc
have not been confirmed by the end of DHCPOF- Server:
FER. ◦ Ls , a list of signing authorities the server trusts
◦ Ks , the public key for the Server
◦ Es , the private key for the Server
◦ Cs , a certificate (chained) containing Ks
Note that Lc ∩ Ls = Tca (A list of com-
mon trusted authorities, including some common
Trusted CA).
If Lc ∩ Ls = ∅, the authentication fails. For
more information on authentication failure, see
the end of this section. The terms used in the
packet exchange are:
Figure 6: Option structure for DHCPRE- M ACEc /Es – Packet hash encrypted with the
QUEST, DHCPACK, DHCPNACK, and corresponding private key
DHCPRELEASE messages Replay – Replay attack prevention data

6
 In the DHCPREPLY message, the Client
replies to the Server, accepting the lease
offered by the Server and notifying the
Alternate Servers that it has chosen the
Server. Note that the Client only sends the
new signed hash of the DHCPREPLY packet,
and does not re-send the certificate with Kc . The
Server uses its stored copy of Kc to check the
Figure 7: DHCPDISCOVER Message hash.

In the DHCPDISCOVER message, the Client

broadcasts or multicasts to known servers a re-
quest for a DHCP lease.
In this authentication step, the Server and all
Alternate Servers check Cc to see if it is signed
by someone they trust (Tca ), and they check and Figure 10: DHCPACK Message
store Kc from Cc . All Servers also check the
replay information, and they check that Kc cor-
In the DHCPACK message, the Server ac-
rectly decrypts M ACEc .
knowledges that the lease which it and the
Client have agreed upon will be recorded and
can be used. The Client uses its stored copy of
Ks to confirm the hash.

Figure 8: DHCPOFFER Message

In the DHCPOFFER message, the Server

Figure 11: DHCPRELEASE Message
replies to the Client with an offer of a lease on an
IP address. The Server includes Cs so that the
Client may confirm the Tca signature on it and In the DHCPRELEASE message, the Client
save Ks for future use. The Client also confirms releases the IP address. Since the Server re-
that M ACEs correctly decrypts and matches and tained Kc with the lease for the Client, it can
confirms that the Replay information checks out. confirm the validity of the hash and release
the lease. The DHCPRELEASE packet demon-
strates the ease of all authenticating all packets
after a DHCPACK when using CBDA.
For unsuccessful DHCP exchange cases,
CBDA would follow the normal method of fail-
ure for DHCP-based failures [1]. For authen-
tication failures, this paper recommends failing
silently for best security, or sending a DHCP-
NACK to reset the client state to INIT. Other,
Figure 9: DHCPREPLY Message similar silent options for Delayed Authentication

7
failures are suggested by Ted Lemon [4]. The have to do the minimum necessary work to be-
implementer, however, may choose to use the come authenticated on a network.
DHCPINFORM message to inform the user of This section provides examples which should
a non-trusted certificate or a similar case. demonstrate how certificate use would achieve
the above. Section 4 uses the same examples to
3.3 Implementation compare Delayed Authentication and CBDA.

Any future implementation of CBDA could eas- (1) Primary Network Example
ily build off of our implementation of Delayed (A user wishes to obtain an IP address on one
Authentication. Not only is CBDA designed to network only, his Primary Network.)
become an additional protocol within the ex-
isting DHCP Authentication RFC [3], but the On the Primary Network, one would want the
implementation of Delayed Authentication pro- length of the certificate chain to be as small as
vides a clear path toward refining and imple- possible, since this certificate would be sent the
menting CBDA. most often. The most straightforward method
For example, two main Delayed Authentica- to do this:
tion implementation hurdles (as also discussed Have each user on the DHCP network ob-
in Sections 2.2 and 6.1) were the issue of modi- tain a certificate with their public key signed by
fying a fully-formed packet before putting it out the Primary Network CA. The Primary Network
on the wire, and the issue of where to store the DHCP Servers would then accept all valid, non-
keys and other authentication information. Both replay DHCP packets with certificates signed by
of these hurdles also need to be crossed in any the Primary Network CA.
implementation of CBDA. Thus, implementing
Delayed Authentication provides a direct basis (2) Separate Multiple Networks Example
for future solutions to these issues. (A user wishes to obtain an IP address on multi-
ple separate networks that are not associated with
3.4 Certificate Use each other, for example, his Work Network and
his Home ISP Network.)
The use and depth of certificates and certificate
chains would depend on the individual security Two main methods exist to achieve authen-
policies of the client and server. The flexibility tication on both networks. The two networks
of certificates allows the user and sysadmin to can either agree on some third-party CA outside
determine whether certificates should be issued both networks, say, Trusted CA, or the user may
on an individual level, on a group level, or even obtain separate certificates for both networks.
on a world-wide level. Neither method involves modifying any DHCP
This section will provide examples of designing server key tables, and neither method requires
and using a certificate policy, and also give po- the two networks to trust one another.
tential methods to incorporate revocation with
certificates used to authenticate DHCP. (3) Temporary Network Example
(A user wishes to have the temporary ability ob-
3.4.1 Certificate Examples tain an IP address on a Secondary Network.)

The use of certificates in DHCP Authentication This example may occur if one was to give a
intends, among other things presented in 3.1, to presentation, provide customer service, perform
make identities of the ever-changing and large a contract job, or simply rent an address from
user base of a DHCP network easier to monitor. or visit a café with a different network than his
The Server should need to keep as few known Primary Network.
and trusted keys as possible. The Client should There are many methods to achieve this, but

8
all are similar to the following two methods. The ample. In addition, this example further demon-
user can either: strates that new hosts may be properly authen-
(a) Have his existing certificate or a new cer- ticated without sharing any secret keys, even
tificate signed by the Secondary Network CA, across networks that trust one another.
and construct the time limit in that certificate
to equal the need for the IP address, or (5) Rogue Client with Credentials
(b) Have the Secondary Network DHCP (A user who has obtained a valid key or certifi-
Servers modified to accept certificates signed by cate, and then has decided to create mischief ).
his Primary Network CA permanently.
Examples (5) and (6) are anything but sim-
The choice depends on the security policy ple. The Server handling a rogue Client is the
of the Secondary Network, and how much key slightly simpler case, since all servers can be con-
management effort the user Client and DHCP figured to watch for a non-expired certificate and
Server are expected to perform. This allows a reject it.
new entry to the DHCP server if certificates from This still, however, leaves the difficult ques-
the Primary Network CA are trusted and com- tions of how to distribute certificate revocation
monly used, and places the effort on the user information to all the servers, and how to make
otherwise. sure all servers have matching acceptance poli-
In either case, even if a network trusts the sig- cies. As discussed in Section 3.4.2, both ques-
nature on a certificate, the network may choose tions are outside the scope of this paper.
to only temporarily accept a particular Client
by setting a short validity time in his certificate (6) Rogue Client with Credentials
and lease. (A server who has obtained a valid key or certifi-
cate, and then has decided to create mischief ).
(4) Trusted Multiple Networks Example The problem of a valid Client detecting a
(A user wishes to obtain an IP address on two rogue Server adds even more complexity to the
networks, Network A and Network B. Both net- above problem of detecting a rogue Client. Since
works trust each other or have agreed on a the valid Client may not yet be attached to the
trusted common CA called Trusted CA.) network, one cannot guarantee it to reliably get
any revocation information via commonly used
This example may occur in very large corpo-
notification methods.
rations that are spread across wide geographical
areas. Network A may be in California, while For more information on solutions for the
Network B may be in Ireland. If both Network Client obtaining Certificate Revocation lists
A and Network B are owned by a common com- while using Certificate Authentication, see Sec-
pany, however, it often makes sense that if an tion 3.4.2.
employee travels between Networks A and B that The most obvious solution to both problems in
employee should obtain an IP address at both Examples (5) and (6), however, would be to keep
sites. tight security on who gets certificate credentials
in the first place.
The solution to this example can be the same
as in the Primary Network Example and the Sep- On most of the above examples, solutions for
arate Networks Example – obtain one certificate what the server should accept are presented, but
signed by Trusted CA, and use that on both net- no solutions for what the client should accept are
works for authentication. presented. In most cases, if the Client chooses to
This example differs, however, since Network get a certificate signed by a network, the Client
A and Network B trust each other. They may trusts that network and should therefore accept
agree to accept certificates signed by the other, in incoming certificates signed by the same net-
a similar fashion to the Temporary Network Ex- work. This will guarantee some intersection of

9
trust between the Client and Server. some Certificate Authority. Then, whenever a
Client contacts a Server for a DHCP lease, the
Server would be required to send out the signed
3.4.2 Certificate Revocation
revocation list, either in the form of an DHCPIN-
As explained in the examples above, one of the FORM message or within the main DHCP ex-
issues of using CBDA comes up when a user in change itself.
possession of a valid certificate creates mischief. Problems with this method still exist, how-
For the servers, updating certificate revocation ever. This would either require the CA to pub-
lists becomes relatively easy when one assumes lish empty revocation lists to prevent a rogue
that the Server is nearly always connected to DHCP server from claiming there were no revo-
the network and thus can get the most recent cations, or would require the Client to take some
list. sort of consensus of the lists it did receive from
The Client, however, by very nature of DHCP, other servers.
is not guaranteed to be predictably connected to
In any case, note that the general problem
the network. In addition, in order to use any
of revocation is not limited to CBDA. It an
certificate revocation information in a DHCP ex-
open and difficult question. DHCP merely fur-
change, the information must come to the Client
ther complicates the problem with the difficulty
before or during the exchange. That is, the re-
of contacting clients before or while they are
vocation information must be delivered to the
obtaining their network information. Imple-
Client when the Client potentially does not yet
menting revocation for the Client and even the
know its own IP address. This becomes obvi-
Server remains a non-trivial task and an open
ously difficult.
problem outside of the scope of this paper.
We have devised two main solutions for notify-
ing a Client of a revocation, and neither is very
clean or low-cost. 3.5 Issues

Distribution by the Certificate Revocation Au- Although we believe that adding CBDA to
thority DHCP Authentication makes the protocol more
flexible and better able to be deployed over large
This solution entails having a Certificate Re-
vocation Authority reply to any DHCP broad- and varied networks, CBDA does have some is-
cast messages and respond by broadcasting the sues.
latest revocation lists. The Client may then wait First of all, there are the trust issues present in
any certificate chaining protocol. For example, if
to receive the revocation list around the time of a
DHCPOFFER, the Client may then check that the certificate signatures from inward out read:
Client → Server A → Server B
the certificate for the Server is not listed, and
then the Client may proceed with the DHCP All that Server B knows about Client is that
process. Server A signed a certificate for Client. This
means that, as certificates are only as good as
Obviously, this not only limits itself to clients
sending DHCP requests out on broadcast, but the issuing methods to decide which ones to sign,
puts a great deal of additional load on the Cer-certificate chains are only as good as the weakest
tificate Revocation Authority to send out revo- such method in the entire chain.
cation information in response to every single Secondly, certificates are very large and DHCP
DHCPDISCOVER it hears and potentially open packets were originally designed to be relatively
itself to flooding. small. In specification [1], no universal limit ex-
ists for DHCP packets, but in practice there nec-
Distribution by the DHCP Server essarily needs to be a limit to prevent flooding
This solution entails having the DHCP Servers of a host. Clients may specify the maximum
store the revocation lists, which are signed by length DHCP packet they will accept, and many

10
of these limits may need to be redesigned if long by the Primary Network CA.
certificate chains are used. Advantages: No key tables to keep track of on
Third, the certificate revocation policy, be- the DHCP servers.
yond setting very short certificate expiration Disadvantages: Long packet length, question
times, could be very complicated to set up. In of trust on other signatures in the certificate.
addition, a revocation policy may create as much
of a demand on issuing the revocation list as (2) Separate Multiple Networks Example
on the DHCP server itself, as described in Sec- (A user wishes to obtain an IP address on multi-
tion 3.4.2. Fortunately, if the policies for issuing ple separate networks that are not associated with
certificates are strict enough in the first place, each other, for example, his Work Network and
revocation would be extremely uncommon. his Home ISP Network.)
All of these issues demonstrate the cost of be-
ing able to authenticate DHCP packets in mul- Delayed Authentication Solution: Have each user
tiple networks as well as being able to have a obtain an individual shared key from both sysad-
minimum number of keys to authenticate with. mins. Obtain and load both keys securely.
Advantages: Same as Example (1).
Disadvantages: Multiple keys must be used,
4 Protocol Comparison and they must be securely obtained and man-
aged.
The CBDA protocol was designed to become
DHCP Option 90 (in DHCP Authentication CBDA Solution: Have the Client obtain two
RFC 3118), Protocol 2 (Certificate-Based Au- separate certificates, or find an intersection of
thentication). Protocol 0 is the plaintext Token trust between the networks and obtain that sig-
protocol, and Protocol 1 is Delayed Authentica- nature.
tion, described in Section 2. Advantages: Potentially able to use only one
This section will demonstrate how, as part of certificate. Certificates need less security be-
the DHCP Authentication protocol suite, CBDA cause the CBDA requires private-key signed
would complement and extend the abilities of hashes as well.
Delayed Authentication. To show this, as in Sec- Disadvantages: Same as Example (1).
tion 3.4.1, we will provide the same multiple sce-
nario examples to demonstrate how the two pro- (3) Temporary Network Example
tocols compare. (A user wishes to have the temporary ability ob-
tain an IP address on a Secondary Network.)
(1) Primary Network Example
Delayed Authentication Solution: Have the user
(A user wishes to obtain an IP address on one
obtain an individual shared key from the sysad-
network only, his Primary Network.)
min. The sysadmin deletes the key from each
Delayed Authentication Solution: Have each user server after the temporary time limit has been
obtain an individual shared key from the sysad- reached.
min. Obtain and load key securely. Advantages: Same as Example (1).
Advantages: No expiring certificates, easy Disadvantages: Must edit the key tables on
to revoke DHCP access for a particular client, all DHCP servers for all visiting or temporary
(delete the shared key from the database). parties.
Disadvantages: Must use and update a table
CBDA Solution: Obtain the signature of the Sec-
to track all the shared keys, difficult to distribute
ondary Network CA, or have the Secondary Net-
keys securely to a large network.
work CA accept another signature that the user
CBDA Solution: Have each user obtain a certifi- has already. Design the certificate to only be
cate of their public key from the sysadmin signed valid for desired length of time.

11
 Advantages: Potentially able to use only one In the case of a rogue Server, the problem
certificate. The time limit takes care of itself becomes harder. As presented in Section 3.4.2,
when the certificate expires. getting revocation information to clients is any-
Disadvantages: Must find a common CA, even thing but trivial.
for just a simple visit, plus all items in Example
(1). Delayed Authentication Solution: Unfortunately,
there does not appear to be a way to let a client
know to ignore a particular server with a valid
(4) Trusted Multiple Networks Example
key. By the nature of Delayed Authentication,
(A user wishes to obtain an IP address on two
all keys on all servers are the same and are ref-
networks, Network A and Network B. Both net-
erenced by the same number. Therefore, a client
works trust each other or have agreed on a
cannot tell any difference between servers by
trusted common CA called Trusted CA.)
their key alone. If the server does not change
Delayed Authentication Solution: Have the user its IP address, however, the client can perhaps
obtain an individual shared key from both sysad- block it or other machine-specific information,
mins. Obtain and load both keys securely. but if the key is stolen and moved to random lo-
Advantages: Same as Example (1). cations, distinguishing the maliciously used key
Disadvantages: Multiple keys must be used if from a valid one is impossible.
the DHCP Servers on the separate networks use Advantages: None
different keys, and they must be securely handled Disadvantages: Difficult to implement
even though the networks have a common trust.
CBDA Solution: Each server should have an in-
CBDA Solution: Have the user obtain one cer- dependent public key even though all certificates
tificate signed by Trusted CA. may be signed by someone the client trusts. The
Advantages: Able to use only one certificate. client may block that public key.
Disadvantages: Same as Example (1). Advantages: Can potentially distrust the
rogue certificate individually.
(5) Rogue Client with Credentials Disadvantages: Very difficult to assure knowl-
(A user who has obtained a valid key or certifi- edge of a rogue server. See Section 3.4.2.
cate, and then has decided to create mischief ).
The above examples should demonstrate that
Delayed Authentication Solution: Delete the key
CBDA cannot replace Delayed Authentication,
for that Client from all Servers
but only augments it. For simple, small net-
Advantages: Only requires a deletion from the
works, Delayed Authentication is a good choice.
key database.
For large and ever-changing networks, CBDA is
Disadvantages: Difficult to implement.
a better choice.
CBDA Solution: Notify all Servers to watch for
that particular certificate or public key, or delete
the corresponding signature from the trusted ta- 5 Future Work
ble.
Advantages: Can choose block certificates at The main focus of future work will be first to al-
any level. low others to comment on the CBDA protocol,
Disadvantages: Requires specific blocking in- second to take those comments and refine the
stead of deletion, difficult to implement. design, and then finally to move toward imple-
menting it.
(6) Rogue Server with Credentials Other future work can be done on the Delayed
(A server who has obtained a valid key or certifi- Authentication implementation to allow varied
cate, and then has decided to create mischief ). key management methods. This would better

12
allow Delayed Authentication to adapt to the ex- the future, we would consider the small, custom,
amples presented in Section 4. proof-of-concept basis, even if in the end we may
not choose it.

6 Conclusion 6.1.2 Retroactive Security

This project, although extensive in effort, was The implementation of Delayed Authentication
also extensive in breadth. It involved research- made the difficulty of adding security onto an ex-
ing most of the major authentication protocols in isting codebase extremely apparent. This prob-
use today, studying Delayed Authentication, and lem is somewhat related to Section 6.1.1 in that
developing Certificate-Based DHCP Authentica- the size of this particular codebase made imple-
tion. Because of this, we wish to describe what menting security even more difficult, but the size
we learned and comment on the project in gen- was not the main problem.
eral so that others who follow us may not have As discussed in Sections 2.2 and 3.3, essential
to take the same hard steps that we have. items and abilities such as key structures, key
management techniques, checks and hashes of
6.1 What we learned completed packets, and retaining authentication
knowledge all had to be teased into the codebase
We learned a great deal from this project – some rather than simply added.
good, some disheartening, but all constructive. To give one example, authentication informa-
There are three main areas where we felt we tion must be kept on the Server along with the
learned the most: the difficulty of using, under- lease for each Client. Had the code been de-
standing, and changing pieces of a large code- signed with security in mind, perhaps the lease
base, the difficulty of adding security to a code- would have been a small, well-defined structure.
base and protocol designed without it, and the Yet in the codebase from the ISC, the lease was
intricacies of designing a protocol which would spread out over multiple files, forms, storage
be secure, flexible, and well-accepted. methods, and types. Authentication tracking in-
formation needed to be added to all of them,
6.1.1 Large Codebase Manipulation since all of them were used in different ways and
for different purposes.
The DHCP codebase from the ISC [7] is not This is not to say the ISC wrote a bad pro-
small. Implementing authentication in a code- gram. In our case we could even be called lucky,
base of such size moves well beyond a proof-of- since the code already included some of the Digi-
concept sized project. Instead, it forces the im- tal Signature Toolkit [10]. Our experience simply
plementer to either understand and work with made it apparent that code in general, when de-
a commercial and daily-use quality implementa- signed for flexibility and varied use, is very hard
tion, or to struggle with both a new concept and to modify retroactively for security. All paths of
an established and massive piece of software and all flexible pieces must be modified, and many
end up hacking both. times some are missed.
Sometimes building a small proof-of-concept
basis program turns out to be easier than ed-
6.1.3 Acceptable Protocols
ucating oneself on existing large code. Unfortu-
nately, we never considered such a choice because When initially designing CBDA, (see Sec-
the ISC code comments and descriptions were tion 3.1), DSSA/SPX appeared to be quite ap-
unclear on whether Delayed Authentication ex- plicable to DHCP authentication and seemed to
isted already. We went with it, hoping for more be a very good choice of methods to authenti-
extensive implementation than they had, (which cate with. However, nobody in the entire world
was little to none,) and were thus committed. In seemed to use it.

13
 On the other hand, Kerberos V would only Online (1993-2003). Available:
solve the client authentication issue, would in- http://www.ietf.org/html.charters/dhc-
volve hefty modification of the DHCP protocol, charter.html
and yet at least two internet drafts appeared
specifying how to use Kerberos V in DHCP au- [3] Droms and Arbaugh. Authentication for
thentication. Presumably the internet drafts DHCP Messages. RFC Number 3118.
were inspired by the breadth of use Kerberos en- Online (2001). Available:
joys today. http://www.ietf.org/rfc/rfc3118.txt
Because of these issues, we added the addi- [4] Droms and Lemon. The DHCP Handbook.
tional requirement in Section 3.1 that the pro- Sams Publishing (2003).
tocols of CBDA must be commonly used. We
feel that CBDA is a good protocol despite the [5] Gollman, Dieter. Computer Security. John
requirement, but in other circumstances the op- Wiley and Sons, Chichester (1999). Pages
tions may not have been as good. 171-174.
In short, we learned that the best choice may
[6] Hornstein et al. DHCP Authentication via
not always be the choice which will actually get
Kerberos V. 20 November 2000. Internet
used. Thus, the implementer may be faced with
Draft (c) The Internet Society.
a choice between use or quality – a very silly
choice. In our case, we simply used the choice [7] Internet Software Consortium. Dynamic
as motivation to look beyond DSSA into other, Host Configuration Protocol (DHCP) Dis-
more common methods of authentication. From tribution. Online (1998-2003). Available:
this, we happened to think of certificates, which http://www.isc.org/products/DHCP
ended up being a better suited method.
[8] Lemon, Ted. Personal communication.
January through March, 2003.
6.2 Summary
[9] Lemon and Cheshire. Encoding Long
This paper has presented another protocol for
Options in the Dynamic Host
the DHCP Authentication protocol suite [3].
Configuration Protocol DHCPv4. RFC
The protocol, called CBDA, uses X.509 certifi-
Number 3396. Online (2002). Available:
cates to extend the functionality and usability
http://www.ietf.org/rfc/rfc3396.txt
of DHCP Authentication over large, varied, and
changing networks. This paper also discusses [10] Network Associates. Digital Signature
the implementation of another DHCP Authen- Toolkit Distribution. Formerly TIS Digital
tication protocol, Delayed Authentication, and Signature Toolkit. Contact Online (2003)
explained how the two protocols compare, and Available: http://www.nai.com/
discussed how CBDA may be easily implemented
from a Delayed Authentication implementation. [11] Schneier, Bruce. Applied Cryptography.
John Wiley and Sons, Chichester (1996).
Pages 574-577.
References
[1] Droms. Dynamic Host Configuration
Protocol. RFC Number 2131. Online
(1997). Available:
http://www.ietf.org/rfc/rfc2131.txt

[2] Droms, ed. Internet Engineering Task

Force. DHC Working Group.

14