One document matched: draft-ietf-dhc-security-arch-00.txt
Security Architecture for DHCP
<draft-ietf-dhc-security-arch-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document addresses the general security requirements of
both v4 and v6 versions of DHCP. This document lists security
requirements and proposes as security model, which meets scaling
requirements, security requirements and efficiency requirements.
The proposed security model uses public key cryptography and a
proposed trusted key distribution mechanism to authenticate
clients and servers. The authentication protocol can also
exchange keying material for more efficiently protecting
successive communication between client and server. The
security model also addresses securing relay agents.
1. DHCP security requirements
One of the problems of designing a security model for DHCP[DHCP]
is the wide variety in use and preconditions that different
sites/clients have. The fact that sites deploy redundant servers
and the lack of a server to server protocol further complicates
things, proposed server to server protocol is an Internet
draft[Server]. This document assumes fair knowledge of DHCP.
1.1. What is authentication?
Authentication is the process of establishing the identity of
some entity. Once identity has been authenticated that identity
Expires September 26, 1997 [Page 1]
Internet Draft March 26, 1997
can be used for access control, accounting etc.. Public key
cryptography is a powerful tool that relies on complex
mathematical operations to provide information that only the
holder of the private key could have generated. For more
background information see RFC-1825[RFC1825].
1.1. Requirements
Throughout this document, the words that are used to define the
significance of particular requirements are capitalized. These
words are:
o "MUST"
This word or the adjective "REQUIRED" means that the item is an
absolute requirement of this specification.
o "MUST NOT"
This phrase means that the item is an absolute prohibition of
this specification.
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the
case carefully weighed before choosing a different course.
o "SHOULD NOT"
This phrase means that there may exist valid reasons in
particular circumstances when the listed behavior is acceptable
or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior
described with this label.
o "MAY"
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the
same item.
Expires September 26, 1997 [Page 2]
Internet Draft March 26, 1997
2. Proposed DHCP security requirements
The proposed requirements can be summarized in the following
rules.
Initial Client/Server Authentication
1. Server MUST authenticate client identity.
2. Client SHOULD authenticate the server identity as
authorized server
Initial Relay Agent/Server Authentication
3. Server MUST authenticate relay agent identity as authorized
relay agent.
4. Relay Agent MUST authenticate server identity as authorized
server.
Successive Client to Server and Relay Agent to Server
Communication
5. Client and Server MUST agree on security model for
protecting future communication.
Server/Relay agent advertisements
6. Advertisements MUST be verifiable by all recipients.
DHCP security cannot be accomplished in a vacuum; fortunately
there are available (or soon will be) protocols that DHCP can
take advantage of. First and foremost DNSSEC[DNSSEC] or some
other KEY distribution mechanism must be available.
IPSEC[RFC1825,IPSEC] will be able to handle requirement 5. It is
not clear if IPSEC for IPv6, in some cases using local link
addresses, can address requirement 1-4. In the case of IPv4 DHCP
MUST perform authentication.
2.1. DHCP Identity
In order to secure DHCP all clients MUST have an identity, this
identity can possibly be one of the following: host name, user
identity, account code. The "prime" identity MUST have a public
KEY stored in the key distribution mechanism. The client MUST
know its identity before contacting the server. Each client
MUST have access to the correct private key before contacting
the DHCP server.
For example if the identity selected for a host is its host name
and the key distribution mechanism is DNS, then the public key
used to authenticate the host is stored under the host name in
its home zone. The private key needs to be stored in the
computer at all times. If the identity selected is the user then
the key is stored under the user name in DNS (e.g.: ogud.tis.com
for me), and user needs to load the computer with the private
key before the host can contact the server. If the identity of
Expires September 26, 1997 [Page 3]
Internet Draft March 26, 1997
the host is just there to uniquely identify the host, the host
still needs a private key.
2.2. Policy issues.
This document does not address access control issues as that is
a policy issue for each site, but effective access control
depends on correct authentication, thus this work will make
access control simpler. This document does not address the
issue of protecting the private key on either server, agent or
client.
3. Client Authentication:
One of the goals of this document is to convince the working
group that achieving initial authentication is the most
important step. Once server and client have established each
other's identity the remaining problems can easily be solved.
The problem of initial client authentication cannot be solved by
IPSEC, as the client does not have an IP identity when it
requests service for the first time from server. Once client
has been configured it can enter IPSEC security associations
with other DHCP servers during the lifetime of the IP address
lease.
3.1 Types of DHCP clients and their identification needs.
To DHCP there are two kinds of clients. Clients that request
some of their net identity, and clients that request ALL of
their net identity from DHCP. From a security point of view, the
second type of client is no different, because these clients
must have some identity (for example MAC address) that can be
used to uniquely identify them. Previous DHCP security
proposals[DHCAUTH] have suggested the use of shared secrets and
passwords to identify clients. It is also possible to use some
kind of challenge/response system to identify clients. These
approaches have limited scaling ability and require a server to
server protocol. But in many environments these weaker
authentication mechanisms are adequate.
The most general case is the identification of a computer that
connects to a world wide ISP network and expects the same
identity regardless of location. In this case it is unlikely
that the same DHCP server serves both India and Iceland. A
network of this kind can have a collaborative agreement between
number of different ISPs, with multiple administrative domains.
It is not reasonable/scalable that all DHCP servers in this
network know shared secrets, or passwords for all computers that
are allowed to connect. From a security standpoint it is a bad
practice to distribute shared secrets or passwords to many
places.
3.2. Motivation for single strong authentication schema.
Expires September 26, 1997 [Page 4]
Internet Draft March 26, 1997
The author feels that it is better to mandate ONE strong
authentication protocol for all DHCP interaction, rather than
allow for multiple ones and allow sites to choose the wrong one.
The protocol below is a strong authentication using public key
signatures and encryption. The security of the protocol depends
on the difficulty in breaking the private keys used. The site
security depends on the sites protecting the private keys. By
mandating one protocol at this point we also eliminate the need
for negotiating what authentication protocol to use. At this
point the public key algorithm has not been selected. The two
leading candidates are RSA and ECC (Elliptical Curve
Cryptography).
4. General DHCP Client authentication protocol.
This protocol depends on a reliable certified public key
distribution mechanism like DNSSEC[DNSSEC]. Each host and server
supplies it's identity, this identity indicates where the
associated public key is stored. For DNS the identity is FQDN
(Fully Qualified Domain Name), accompanied by key algorithm
number and public key footprint. For other key distribution
mechanisms there must be enough information to retrieve the key
from that source. To successfully validate a server public key,
clients must be configured with root key(s) for the key
distribution certification tree.
This protocol never transmits public keys as it is easy to forge
self signed keys. Instead certified keys are distributed via
trusted 3rd party (eg. DNSSEC). One of the preconditions of
this protocol is that client and server MUST roughly agree on
current time. The role of the current time information below is
to prevent replay attacks. If client does not know the current
time, it MUST request it before starting the authentication
process. Servers and Relay agents MUST provide current time upon
request without any security checks.
If the client does not know the current time, it must be able to
ask the local relay agent/server for the current time without
authentication and get an answer.
4.1. DHCP authentication protocol overview.
In the following discussion, DHCP fields not important to the
overall security schema are omitted. Following protocol outline
assumes that the key distribution mechanism is DNS.
Expires September 26, 1997 [Page 5]
Internet Draft March 26, 1997
1. Client:
Sends server discovery packet containing
Identity (this can be one of host identity, claimed identity,
charging identity)
client's own public key identity
Optionally its host identity
current time
security options/transformations supported
DHCP requests for at least address, DNS server and gateway
address.
all preceding data is signed by client private key
corresponding to the public key specified above.
2. Server:
If current time is within accepted range
Look up client public key in key distribution mechanism
verify signature
is this client allowed to connect?
If all above checks are passed server sends back
server Public KEY identity
Security model selected
key identifier ( if needed by security Model)
current time.
information client requested for configuration (Address, DNS
server, gateway)
all above signed by the Server private KEY.
3. Client can now
configure itself
Look up server Public Key in DNS.
if Server key is found, client SHOULD validate packet and
Server KEY using DNS
client should also verify that DNS server is actually a valid
DNS server.
Sends server
key identifier requesting keying material
current time
signed by client public key
4. Server:
Server generates a random key to use and it sends to client
key identifier
Keying material
Lifetime of the security association.
Current time
This data is encrypted using clients public key
The client decrypts the packet with its private key. At this
point the client can assume its normal processing and send
further requests to server protected by the security model
selected. The protocol for a relay agent is similar but is
omitted here.
Expires September 26, 1997 [Page 6]
Internet Draft March 26, 1997
4.2. Additions to the protocol overview.
The protocol outlined above does not spell out all the possible
error states that can be entered. This needs to be specified in
the full protocol. Some of the possible errors include the
following cases:
What does the server do if it is unable to retrieve/validate the
client key?
The Client in its verification phase must be able to determine
what are the authorized DHCP servers. This may require a new DNS
record, or use the SRV[SRV] record.
What does a client do if it is not able to convince itself that
it is talking to a good DHCP server?
Due to the fact that some of the operations required by this
protocol take longer than the time-out values in unsecured DHCP,
these need to be changed for Security aware servers and clients.
There may be a need for a server to send back an ACK to a client
indicating that a request has been received and is being
processed to stop client from retransmitting requests.
In the case of security aware client trying to talk to security
ignorant server the server must return an error code informing
the client that it does not understand the request. Security
aware servers similarly must treat security ignorant clients
differently, but how must be determined.
4.3. Justification for the authentication protocol
There are number of reasons why the protocol does not attempt to
create a security association in the first round. By explicitly
requesting the security association, the client is notifying the
server that it trusts the server and wants to establish a long
term relationship with it. There is no reason to establish a
security association with a server the client does not trust.
If a server selects a shared secret or encryption as a message
protection mechanism then the key selected by the server is for
use between one client and one server for a limited time. If
there is a group of DHCP servers for this site, then the server
to server protocol MAY be used to distribute the secret to all
the servers. If redundant servers do not share secrets then a
client MUST authenticate itself to each server. If a security
association outlives its lease time, it MUST be renewed or
deleted.
In this protocol, there is no need for shared secrets to leave
an administrative domain. This protocol solves the distribution
problem of shared secrets and eliminates the need for clients to
remember shared secrets. The explicit expiration of shared
secrets greatly simplifies server management of shared secrets.
The only information that a client needs to know is its own
Expires September 26, 1997 [Page 7]
Internet Draft March 26, 1997
identity, its public/private key pair and the root public key
for the key distribution mechanism. An added benefit of this
protocol is that it does not require the DHCP server to store
the authentication information for clients that may connect to
it. The public keys used are retrieved from an external source.
This means that there will be minimal change in how servers are
run. This protocol does not address the access control issue;
that is a separate problem.
4.4. What does the authentication protocol accomplish?
This protocol accomplishes requirements 1 through 4. It carries
enough information to enable requirement 5. For server and
client to validate each other public keys they may want to walk
the DNS tree to the root to create a chain of valid keys. The
client cannot trust the DNS server supplied by the server but it
can trust the signed verifiable data that the DNS server
provides. This requires that the DHCP client be able to do
DNSSEC verification locally.
To determine that the Server is not an impostor there may be a
need to store in DNS the list of authorized DHCP servers and
agents in a zone.
The "root keys" that client stores, can be the keys for "." or
for the outermost domain that the client can talk to servers in.
The main reason for having the server select the secret keying
material for the security association, has to do with random
number entropy. Many computers do not have good sources of
randomness available at boot time. A server that has been
running for a while, on the other hand, has access to better
sources of randomness. The protocol when specified should
include guidelines on how to generate good random keys on
servers.
5. Protecting ongoing client/server communication
Rule 5 above states that client (or relay agent) and server must
agree on a security model for securing all communication. The
authentication protocol above accomplishes the required dynamic
setup for this. Once a security aware Server and security aware
Client have authenticated each other they have entered a
security association. This security association will determine
how all successive communication is protected. Below is a list
of available mechanisms that accomplish this task.
A. None (Current state of affairs) NOT recommended
B. Message digest with shared secret. (Protects the contents
of the packet).
C. Digital signature. (Provides more assurance at higher
cost).
D. Encrypted communication (Provides confidentiality).
E. IPSEC.
Expires September 26, 1997 [Page 8]
Internet Draft March 26, 1997
The author feels that mechanisms B and D are the only ones
practical for DHCP. Digital signatures are not worth the
computational and bandwidth cost for one on one communication.
IPSEC will become viable at some point in the future and can/
should be used to protect the communication. The working group
needs to decide whether to deploy a message protection mechanism
in the DHCP protocol or wait for IPSEC. This document recommends
that B be implemented using HMAC[HMAC] technique combined with
one of the following message digest algorithms MD5, SHA-1 or
RIPEMD-160.
Digital signatures provide a stronger authentication mechanism
than Message digests but are much more expensive to generate.
Some Digital signatures are inexpensive to verify but not all.
RSA is inexpensive to verify but DSA is not. Given the expensive
computation of digital signatures it is hard to justify their
use once identity has been established.
6. Impact of Agents on security model.
Given that in many cases clients need Agents to connect them to
DHCP servers, it is important that agents cannot modify the
contents of the DHCP request. It is also important that Agents
authenticate server advertisements. Agents should not be allowed
to modify client requests in any way, other than that required
to route the requests. There is no need for the client to enter
a security association with its Relay Agent.
6.1. Server/Relay agent advertisements.
This is a special case where one entity is talking to many. In
order to protect this form of communication from malicious
attacks these advertisements MUST be digitally signed using the
advertisers public key. It is possible to create a group shared
secret or group encryption key. This is not a good arrangement
for anything that lasts longer than a short time. Short time can
be a few minutes to a few hours; longer than that it is not a
secure arrangement. If one party leaks this key information,
outsiders can forge traffic.
6.2. Security threats from relay agents.
Relay agents can potentially conduct "man in the middle" attacks
on a system that uses them. In the schema above relay agents can
conduct denial of service attacks. This is a simple fact of
life and there is no way to overcome that.
It is not clear that relay agents can conduct any other kind of
attacks as they are not able to forge any of the contents of the
packets.
In the case where clients do not validate that the server
contacted is a valid server, relay agents may conduct attacks as
Expires September 26, 1997 [Page 9]
Internet Draft March 26, 1997
fake server. In this attack the relay agent claims to be the
server to the client and the client to the server.
Careful design of the protocol should be able to prevent this.
7. Security considerations
This document is about security.
8. References
[DHCP] R. Droms, "Dynamic Host Configuration Protocol", RFC
1541, Bucknell University, October 1993.
[DHCAUTH] R. Droms, "Authentication for DHCP Messages",
Internet Draft <draft-ietf-dhc-authentication-03.txt> November
1996
[DNSSEC] D. Eastlake, C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", February 1997
[IPSEC] R. Atkinson, "Security Architecture for the Internet
Protocol", Internet Draft <draft-ietf-ipsec-arch-sec-01.txt>,
November 1996.
[RFC1825] R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 1825, September 1995.
[Server] R. Droms, R. Cole, "An Inter-server Protocol for DHCP"
Internet Draft <draft-ietf-dhc-interserver-01.txt> March 1997.
[SRV] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.
9. Author address
Olafur Gudmundsson
Trusted Information System
3060 Washington Road
Glenwood, MD 21738
+1 301 854 5794
<ogud@tis.com>
Expires September 25, 1997 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 23:36:20 |