draft-ietf-dhc-security-arch-00.txt   draft-ietf-dhc-security-arch-01.txt 
Dynamic Host Configuration WG Olafur Gudmundsson Dynamic Host Configuration WG Olafur Gudmundsson
INTERNET DRAFT Trusted Information Systems INTERNET DRAFT Trusted Information Systems
<draft-ietf-dhc-security-arch-00.txt> March 26, 1997 <draft-ietf-dhc-security-arch-01.txt> July 30, 1997
Security Architecture for DHCP Security Architecture for DHCP
<draft-ietf-dhc-security-arch-00.txt> <draft-ietf-dhc-security-arch-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its areas,
areas, and its working groups. Note that other groups may also and its working groups. Note that other groups may also distribute
distribute working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other documents
documents at any time. It is inappropriate to use Internet- at any time. It is inappropriate to use Internet-Drafts as reference
Drafts as reference material or to cite them other than as material or to cite them other than as ``work in progress.''
``work in progress.''
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check the
the ``1id-abstracts.txt'' listing contained in the Internet- ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Drafts Shadow Directories on ftp.is.co.za (Africa), Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
This document addresses the general security requirements of This document addresses the general security requirements of both
both v4 and v6 versions of DHCP. This document lists security DHCPv4 and DHCPv6. This document lists security requirements and
requirements and proposes as security model, which meets scaling proposes a security model, which meets scaling requirements,
requirements, security requirements and efficiency requirements. security requirements and efficiency requirements.
The proposed security model uses public key cryptography and a The proposed security model uses public key cryptography and a
proposed trusted key distribution mechanism to authenticate proposed trusted key distribution mechanism to authenticate clients
clients and servers. The authentication protocol can also and servers. Once clients have authenticated themself less expensive
exchange keying material for more efficiently protecting mechanishms can be used to protect subsequent communication. The
successive communication between client and server. The security model also addresses securing relay agents and server to
security model also addresses securing relay agents. server protocols.
1. DHCP security requirements 1. DHCP security requirements
One of the problems of designing a security model for DHCP[DHCP] One of the problems of designing a security model for DHCP[DHCP] is
is the wide variety in use and preconditions that different the wide variety in use and preconditions that different sites/
sites/clients have. The fact that sites deploy redundant servers clients have. The fact that sites deploy redundant servers and
and the lack of a server to server protocol further complicates the lack of a server to server protocol further complicates
things, proposed server to server protocol is an Internet things[Server,Intserver].
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]
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" 1.1. Authentication, confidentiality, data integrity
This word or the adjective "REQUIRED" means that the item is an RFC-1825[RFC1825] contains a great description of these terms and
absolute requirement of this specification. their uses. Authentication is the process of establishing the
identity of some entity. Once identity has been authenticated,
that identity can be used for access control, accounting etc.
o "MUST NOT" There are number of authentication technologies available.
This phrase means that the item is an absolute prohibition of Public key cryptography is a powerful tool that relies on complex
this specification. mathematical operations to provide information that only the holder
of the private key could have generated. This technology can be
used for all the functions named in the title of this section.
o "SHOULD" Shared secret authentication is the process of digesting the data
transmitted and obfuscating the digest by applying a transformation
by a key that is only used by the two entities. This technology
can be used to provide both authentication and data integrity.
Each pair can share multiple shared secrets, it is important
that each secret have an identifier attached to it.
This word or the adjective "RECOMMENDED" means that there may Confidentiality can be accomplished by encrypting the data contents
exist valid reasons in particular circumstances to ignore this of the outgoing packet. Shared secrets can be used as keys for
item, but the full implications should be understood and the symmetric encryption.
case carefully weighed before choosing a different course.
o "SHOULD NOT" 1.2. Shared secrets
This phrase means that there may exist valid reasons in Shared secrets are between two entities; there is NEVER a need to
particular circumstances when the listed behavior is acceptable share these secrets with other entities. The hosts storing the
or even useful, but the full implications should be understood secrets MUST protect the secrets as well as possible.
and the case carefully weighed before implementing any behavior
described with this label.
o "MAY" 1.3 Terminology and DHCP v6 considerations
This word or the adjective "OPTIONAL" means that this item is This document uses DHCPv4 terminology as it is more familiar than
truly optional. One vendor may choose to include the item the new DHCPv6[DHCPv6] terminology. When this document talks
because a particular marketplace requires it or because it about DISCOVER messages the same will apply to DHCP v6 Solicit
enhances the product, for example; another vendor may omit the Message. No changes are needed in the protocol section 6 to
same item. support DHCPv6; some currently proposed DHCPv6[DHCPv6EXT]
security options need to be modified.
Expires September 26, 1997 [Page 2] The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
2. Proposed DHCP security requirements 2. Proposed DHCP security requirements
The proposed requirements can be summarized in the following The proposed requirements can be summarized in the following rules.
rules.
Initial Client/Server Authentication - Initial Client/Server Authentication
1. Server MUST authenticate client identity. 1. Server MUST authenticate client identity.
2. Client SHOULD authenticate the server identity as
authorized server
Initial Relay Agent/Server Authentication 2. Client SHOULD authenticate the server identity as an
authorized server.
3. Server MUST authenticate relay agent identity as authorized - Initial Relay Agent/Server Authentication
relay agent. 3. Server MUST authenticate relay agent identity as an
4. Relay Agent MUST authenticate server identity as authorized authorized relay agent.
server.
Successive Client to Server and Relay Agent to Server 4. Relay Agent MUST authenticate server identity as an
Communication authorized server.
5. Client and Server MUST agree on security model for HAND JUSTIFY
- Successive Client to Server and Relay Agent to Server Communication
5. Client and Server MUST have agred on security model for
protecting future communication. protecting future communication.
Server/Relay agent advertisements - Server/Relay agent advertisements
6. Advertisements MUST be verifiable by all recipients. 6. Advertisements MUST be verifiable by all recipients.
DHCP security cannot be accomplished in a vacuum; fortunately - Server/Server communication
there are available (or soon will be) protocols that DHCP can
take advantage of. First and foremost DNSSEC[DNSSEC] or some 7. All communication MUST be protected for data integrity.
other KEY distribution mechanism must be available. Servers MAY request that communication be encrypted.
IPSEC[RFC1825,IPSEC] will be able to handle requirement 5. It is
not clear if IPSEC for IPv6, in some cases using local link DHCP security cannot be accomplished in a vacuum; as DHCP is not a
addresses, can address requirement 1-4. In the case of IPv4 DHCP general purpose communication protocol. Fortunately there are
MUST perform authentication. available (or soon will be) protocols that DHCP can take advantage
of. First and foremost DNSSEC[RFC2065] 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 the
initial authentication.
2.1. DHCP Identity 2.1. DHCP Identity
In order to secure DHCP all clients MUST have an identity, this In order to secure DHCP all clients MUST have an identity, this
identity can possibly be one of the following: host name, user identity can possibly be one of the following: host name, user
identity, account code. The "prime" identity MUST have a public identity, account code. The "prime" identity MUST have a public key
KEY stored in the key distribution mechanism. The client MUST stored in the key distribution mechanism. The client MUST know its
know its identity before contacting the server. Each client identity before contacting the server. Each client MUST have access
MUST have access to the correct private key before contacting to the correct private key before contacting the DHCP server.
the DHCP server.
For example if the identity selected for a host is its host name If the identity selected for a host is its host name and the key
and the key distribution mechanism is DNS, then the public key distribution mechanism is DNS, then the public key used to
used to authenticate the host is stored under the host name in authenticate the host is stored under the host name in its home
its home zone. The private key needs to be stored in the zone. The private key needs to be stored in the computer at all
computer at all times. If the identity selected is the user then times. If the identity selected is the user then the key is stored
the key is stored under the user name in DNS (e.g.: ogud.tis.com under the user name in DNS (e.g.: ogud.tis.com for me), and the user
for me), and user needs to load the computer with the private needs to load the computer with the private key before the host
key before the host can contact the server. If the identity of can contact the server. If the identity of the host is just
there to uniquely identify the host, the host still needs a
private key.
Expires September 26, 1997 [Page 3] 2.2. DHCP communication protection
the host is just there to uniquely identify the host, the host DHCP is a protocol that carries publicly known information, thus
still needs a private key. there is limited need for confidentiality. DHCP requires data
integrity protection for communication. The option to allow DHCP
servers/clients to request confidentiality SHOULD be part of any
security architecture.
2.2. Policy issues. 2.3. Policy issues.
This document does not address access control issues as that is This document does not address access control issues as that is a
a policy issue for each site, but effective access control policy issue for each site. Effective access control depends on
depends on correct authentication, thus this work will make correct authentication, thus this work will make access control
access control simpler. This document does not address the simpler. This document does not address the issue of protecting the
issue of protecting the private key on either server, agent or private key on either server, agent or client.
client.
3. Client Authentication: 2.4 Security threats to DHCP
One of the goals of this document is to convince the working 2.4.1 Attacks against servers
group that achieving initial authentication is the most
important step. Once server and client have established each There are many possible attacks possible against servers, including
other's identity the remaining problems can easily be solved. denial of service by exhausting the servers allocated address space.
Another denial of service attack is to overload the server causing
it not to respond to clients.
Once servers start updating DNS and other directory services, DHCP
servers can be spoofed to register incorrect information in those
services.
Another possible attack is to gain unauthorized access to some
resources, such as network access.
2.4.2 Attacks against clients
This is a less known problem, but should not be ignored. Fake
servers can provide clients with partially correct information
that allows the attacker to route traffic through certain host
where critical information can be collected. This becomes
important to detect and prevent when encrypted traffic is
allowed to pass through firewalls.
Clients can be configured with bogus data, so that they will assume
that the network is down. In some cases it is hard to get a
client to reconfigure itself. Clients can also be configured
with addresses of other clients, causing address conflicts.
The bright side of this problem is that it is not that hard to
detect fake servers by monitoring the network for DHCP traffic.
2.5. Complications in implementing the security models
A Client that issues DISCOVER message does not have any IP address
that works outside the local network, and may not even work on
the local network. This prevents the clients from checking with
outside information sources. Servers on the other hand are fully
configured and can use any information sources accessible.
Clients will not wait long for OFFER message, some security checks
may take longer than the DHCP retransmission timeout. If DHCP
servers had an option to inform clients that DISCOVER messages
are being worked on and client should expect an answer in short
order, then this problem would be solved.
Some DHCP servers do not have CPU cycles to spare to do security
checks. This is a bogus argument, since inexpensive powerful
computers are available and sites should upgrade if security is
of concern.
3. DHCP Security components
3.1 Authentication services
In order for DHCP servers to be able to determine if a client
request should be serviced it is essential for the server to be
able to establish the client's identity. There are two kinds of
identities that are possible, local mutually agreed upon
identities and global identities.
Local identity is sufficient if the client will only be configured
from a small set of servers, and if there are no expectations
that the client will migrate to another location. This is an
acceptable solution for a site where all computers are
stationary but are configured from DHCP for administrative
reasons. Solutions of this kind have certain scaling problems.
Global identity on the other hand is needed when a client can
connect to multiple servers and it provides some of its
identity.
An example of local identity is a name or number that is
configured in the client and server. This could be the name of the
client on the local network. A good example of global identity
is a DNS domain name.
3.2 Time service
To prevent replay attacks, DHCP messages must contain time
information that clients and servers check and act upon. Clock
synchronization service can be provided by an outside
entity[RFC1305] once a client is configured, but bounds must be
placed on acceptable skew while a client is off line or migrates
between locations. Clients SHOULD not trust time information
from servers until after servers have been validated as such.
Clients should always assume that the network is insecure.
3.3 Data confidentiality
This is not desired service at this point, but it can be added at a
later point for all communication except DISCOVER and possibly OFFER
and REQUEST. All subsequent communication can be encrypted.
3.4 Possible security models for DHCP
This section will present a few possible security models and the
reasons why each one may be useful. This section IS NOT an
advocacy for any of the descibed models
3.4.1 The "No security" model
This is the current situation. The motivation for not changing
anything is that security is hard. Considering that DHCP for IPv4 is
a hack built on an older hack (BOOTP), there is not enough
flexibility in the protocol to add security.
A smart client attached to a broadcast network can learn everything
it needs to know to configure itself by listening to network
traffic. The client can either monitor DHCP traffic and/or all
network traffic to find gateways, servers and unused addresses.
There is no protection against this.
DHCPv6 can on the other hand be extended and modified to fit any
security model selected. Sites will migrate to IPv6 soon, and
the ones that do not deserve what they get.
In this model DHCP clients will be able to do harm and be harmed
by bogus servers. This model is not acceptable when DHCP servers
perform update operations on a client's behalf. Sites MAY
select this model but this is strongly discouraged.
3.4.2 The "Simple" model
A DHCP client is configured with a token that allows it to
authenticate itself to the servers in the DHCP DISCOVER message.
If servers can authenticate the token and the client associated
with the token is allowed to communicate with the server the
server will reply with OFFER message.
In this model servers will know with which client they are dealing,
and that should be sufficient protection against most of the
attacks against the servers. If a client is able to authenticate
the server response, the client might be protected against bad
servers.
With minor extensions to DHCP, all subsequent communication can be
protected.
3.4.3 The "Comprehensive" Model
In this model DHCP servers and clients have the ability to
authenticate each other. The requirement here is that clients must
be able to authenticate the server without any communication as
they can not trust the information from the server. This model
also must prevent replay attacks.
This model protects all traffic between clients and servers, making
it impossible to stage any attacks other than denial of service
attacks due to CPU overload of servers.
4. Client Authentication:
Initial authentication is the most important step. Once server and
client have established each other's identity the remaining
problems can solved.
The problem of initial client authentication cannot be solved by The problem of initial client authentication cannot be solved by
IPSEC, as the client does not have an IP identity when it IPSEC, as the client does not have an IP identity when it requests
requests service for the first time from server. Once client service for the first time from the server. Once the client has
has been configured it can enter IPSEC security associations been configured it can enter IPSEC security associations with
with other DHCP servers during the lifetime of the IP address other DHCP servers during the lifetime of the IP address lease.
lease.
3.1 Types of DHCP clients and their identification needs. 4.1 Types of DHCP clients and their identification needs.
To DHCP there are two kinds of clients. Clients that request In DHCP there are two types of clients: clients that request some of
some of their net identity, and clients that request ALL of their net identity from DHCP, and clients that request all of their
their net identity from DHCP. From a security point of view, the net identity from DHCP. From a security point of view, the
second type of client is no different, because these clients second type of client is no different, because these clients
must have some identity (for example MAC address) that can be must have some identity (for example MAC address) that can be
used to uniquely identify them. Previous DHCP security used to uniquely identify them. Previous DHCP security
proposals[DHCAUTH] have suggested the use of shared secrets and proposals[DHCAUTH] have suggested the use of shared secrets and
passwords to identify clients. It is also possible to use some passwords to identify clients. It is also possible to use some
kind of challenge/response system to identify clients. These form of challenge/response system to identify clients. These
approaches have limited scaling ability and require a server to approaches have limited scaling ability and require a server to
server protocol. But in many environments these weaker server protocol. But in many environments these weaker
authentication mechanisms are adequate. authentication mechanisms are adequate.
The most general case is the identification of a computer that The most general case is the identification of a computer that
connects to a world wide ISP network and expects the same connects to a world wide ISP network and expects the same identity
identity regardless of location. In this case it is unlikely regardless of location. In this case it is unlikely that the same
that the same DHCP server serves both India and Iceland. A DHCP server serves both India and Iceland. A network of this
network of this kind can have a collaborative agreement between kind can have a collaborative agreement between a number of
number of different ISPs, with multiple administrative domains. different ISPs, with multiple administrative domains. It is not
It is not reasonable/scalable that all DHCP servers in this reasonable/scalable that all DHCP servers in this network know
network know shared secrets, or passwords for all computers that shared secrets, or passwords for all computers that are allowed
are allowed to connect. From a security standpoint it is a bad to connect. From a security standpoint it is a bad practice to
practice to distribute shared secrets or passwords to many distribute shared secrets or passwords to many places.
places.
3.2. Motivation for single strong authentication schema. 4.2. Motivation for single strong authentication schema.
Expires September 26, 1997 [Page 4] It is better to mandate ONE strong authentication protocol for all
The author feels that it is better to mandate ONE strong DHCP interaction, rather than allow for multiple ones and allow
authentication protocol for all DHCP interaction, rather than sites to choose the wrong one. The protocol below uses strong
allow for multiple ones and allow sites to choose the wrong one. authentication with public key signatures and encryption. The
The protocol below is a strong authentication using public key security of the protocol depends on the difficulty in breaking
signatures and encryption. The security of the protocol depends the private keys used. The site security depends on the sites
on the difficulty in breaking the private keys used. The site protecting the private keys. By mandating one protocol at this
security depends on the sites protecting the private keys. By point, we also eliminate the need for negotiating what
mandating one protocol at this point we also eliminate the need authentication protocol to use. At this point, the public key
for negotiating what authentication protocol to use. At this algorithm is MUST be RSA.
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. 4.3 Motivation for global DNS identities for DHCP clients
This protocol depends on a reliable certified public key Once the global identity is registered with an information service,
distribution mechanism like DNSSEC[DNSSEC]. Each host and server this identity is available within the limits of the information
supplies it's identity, this identity indicates where the service. DNS is the most common information service used by
associated public key is stored. For DNS the identity is FQDN computers.
(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 DNSSEC[RFC2065] strengthens DNS[RFC1035] against information
self signed keys. Instead certified keys are distributed via corruption and provides distribution of public keys. If every host
trusted 3rd party (eg. DNSSEC). One of the preconditions of that is configured by DHCP has a public key stored in DNS then
this protocol is that client and server MUST roughly agree on servers can verify digital signatures generated by that key.
current time. The role of the current time information below is Once clients are configured it is possible for client to verify
to prevent replay attacks. If client does not know the current that the server it was configured by is a good DHCP server. In
time, it MUST request it before starting the authentication order to do this, either SRV[SRV] records or ALLOC[DHCPVERSERV]
process. Servers and Relay agents MUST provide current time upon DNS record must list the DHCP servers for each domain.
request without any security checks.
If the client does not know the current time, it must be able to IPSEC can be preconfigured with SPI's but there is no definition for
ask the local relay agent/server for the current time without the format of the 'destination address'. If it is DNS format, DHCP
authentication and get an answer. entities MAY enter IPSEC relationship without a key exchange once
client has received DHCP ACK message.
4.1. DHCP authentication protocol overview. 5. DHCP security options and their processing
In the following discussion, DHCP fields not important to the 5.1 DNS Identity option
overall security schema are omitted. Following protocol outline
assumes that the key distribution mechanism is DNS.
Expires September 26, 1997 [Page 5] This option allows the DHCP entities to advertise their own public
1. Client: keys which are stored in DNS and DNSSEC provides secure key rerival
Sends server discovery packet containing mechanism.
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: Field value size in bytes
If current time is within accepted range ------------- ------ -----------
Look up client public key in key distribution mechanism option TBD 1
verify signature length 0-255 1
is this client allowed to connect? selector 0-64K 2
If all above checks are passed server sends back name variable < 250
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 The name specified in this option does not have to be the same name
configure itself that the client is requesting/using.
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: 5.2 Signature option
Server generates a random key to use and it sends to client This is an option that carries any type of signature that can be
key identifier specified.
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 Field value size in bytes
point the client can assume its normal processing and send ------------- ------ -----------
further requests to server protected by the security model option TBD 1
selected. The protocol for a relay agent is similar but is length 0-255 1
omitted here. algorithm 1-253 1
ID 0-2^16 2
current time 0-2^32 4
signature data binary variable < 246
Expires September 26, 1997 [Page 6] The following algorithms are defined and must be supported by all
implementations.
4.2. Additions to the protocol overview. 0 No signature data
1 RSA/MD5 as specified in PKCS1[NETSEC], this is
identical to algorithm 1 in DNSSEC.
The protocol outlined above does not spell out all the possible 100 HMAC-MD5 as specified in RFC2104[RFC2014]
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 The ID is a 16 bit number that is identical to the key indentifier
client key? in the DNSSEC SIG record. This identifier is used to select a
The Client in its verification phase must be able to determine key from the key set of the name. If there are multiple keys in
what are the authorized DHCP servers. This may require a new DNS the key set that match this ID and can be used for DHCP and are
record, or use the SRV[SRV] record. the same size, the verifier must be ready to try all of the keys
What does a client do if it is not able to convince itself that until verification succeeds.
it is talking to a good DHCP server?
Due to the fact that some of the operations required by this The current time value states at what time the signature is
protocol take longer than the time-out values in unsecured DHCP, generated, in Universal Time. DHCP entity SHOULD accept signatures
these need to be changed for Security aware servers and clients. that are within 60 seconds of local time. If the signature is not
There may be a need for a server to send back an ACK to a client within these bounds the whole packet should be rejected.
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 The size of the signature data field depends on the algorithm used
ignorant server the server must return an error code informing and for some algorithms, the key size. MD5 digests are 16 bytes.
the client that it does not understand the request. Security RSA signatures are always the same size as the modulus of the
aware servers similarly must treat security ignorant clients key. Signature data can never exceed 246 bytes, this restricts
differently, but how must be determined. the key sizes used to about 1968 bits.
4.3. Justification for the authentication protocol The data covered by signatures is defined in section 5.3.1. The
Signature option MUST be the LAST option in the DHCP packet, adding
a Signature option MUST NOT result in too large of a packet,
other options MUST be removed to make space for the signature
option.
There are number of reasons why the protocol does not attempt to There are special considerations for Relay agents. A Relay Agent
create a security association in the first round. By explicitly that adds a relay agent option(s) to a signed DHCP packet MUST
requesting the security association, the client is notifying the add a Signature option after its option(s) and its signature
server that it trusts the server and wants to establish a long MUST cover the whole outgoing packet. If the incoming
term relationship with it. There is no reason to establish a signature is addressed to this Relay Agent, the Relay Agent MUST
security association with a server the client does not trust. remove that signature from the outgoing packet before adding its
option(s) to the packet. If the incoming signature is a digital
signature (alg=1) it MUST be retained.
If a server selects a shared secret or encryption as a message 5.3.1 Data covered by signature option
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 The whole outgoing DHCP packet is covered, including the signature
an administrative domain. This protocol solves the distribution option.
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 For DISCOVER/SOLICIT the signature is calculated over
Expires September 26, 1997 [Page 7] Modified outgoing packet
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? For all other messages the signature is calculated over
This protocol accomplishes requirements 1 through 4. It carries digest of last valid incoming packet | Modified outgoing packet
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 The modified outgoing packet is the whole DHCP packet with following
need to store in DNS the list of authorized DHCP servers and differences:
agents in a zone.
The "root keys" that client stores, can be the keys for "." or 'giaddr' and 'hops' fields must be set to all zero.
for the outermost domain that the client can talk to servers in. All bytes in the signature data must be set 0xa6.
The main reason for having the server select the secret keying The digest of the last incoming packet from the other entity is to
material for the security association, has to do with random associate the outgoing packet to the request or last answer.
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 5.3 Wait option
Rule 5 above states that client (or relay agent) and server must This option allows the server to inform the client that it is
agree on a security model for securing all communication. The currently validating the clients identity and request that the
authentication protocol above accomplishes the required dynamic client wait the specified time before retransmitting the query.
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] Field value size in bytes
The author feels that mechanisms B and D are the only ones ------------- ------ -----------
practical for DHCP. Digital signatures are not worth the option TBD 1
computational and bandwidth cost for one on one communication. length 3 1
IPSEC will become viable at some point in the future and can/ seconds 1-6 1
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 This option is to throttle back security aware clients while server
than Message digests but are much more expensive to generate. is authenticating the clients identity. The client MUST ignore
Some Digital signatures are inexpensive to verify but not all. this option if it has received 2 previous ones from same server
RSA is inexpensive to verify but DSA is not. Given the expensive for the same message.
computation of digital signatures it is hard to justify their
use once identity has been established.
6. Impact of Agents on security model. 6. "Simple" DHCP authentication protocol
Given that in many cases clients need Agents to connect them to This protocol is along the lines of the simple model described in
DHCP servers, it is important that agents cannot modify the section 3.4.2. The foundation that this protocol offers can be used
contents of the DHCP request. It is also important that Agents to build a comprehensive protocol.
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 protocol depends on a reliable certified public key
distribution mechanism like DNSSEC[DNSSEC]. Each client supplies
its identity in the initial DISCOVER message. This identity
indicates where the associated public key is stored. For DNS the
identity is the FQDN (Fully Qualified Domain Name), accompanied
by the key algorithm number and public key footprint. For other
key distribution mechanisms there must be enough information to
This is a special case where one entity is talking to many. In Expires January 30, 1998 [Page10]
order to protect this form of communication from malicious retrieve the key from that source.
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. To successfully validate a server public key, clients must be
configured with the root key(s) for the key distribution
certification tree.
Relay agents can potentially conduct "man in the middle" attacks The protocols below make use of currently undefined options, these
on a system that uses them. In the schema above relay agents can options must be specified before this proposal can be adopted.
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 6.1 DHCP authentication protocol overview
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 In the following discussion, DHCP options not important to the
contacted is a valid server, relay agents may conduct attacks as overall schema are not included.
Expires September 26, 1997 [Page 9] 6.1.1 Client: DISCOVER message MUST include
fake server. In this attack the relay agent claims to be the
server to the client and the client to the server. IDENTITY option (contains identity type, name, unique selector)
Careful design of the protocol should be able to prevent this. Signature option (alg=1) signed by public key in IDENTITY option.
6.1.2 Server: DHCP-OFFER message
If server is able to validate DISCOVER message from a client it
shares a secret with it MUST include following options.
IDENTITY option
Signature option (alg=100)
If the client is able to verify this message, it has authenticated
the server and the authentication protocol is complete. Future
communication can be protected by this secret.
If the server is able to validate DISCOVER message from a client
that it does not share a secret with, the following options MUST
be included.
IDENTITY option
Signature option (alg=1)
If the server needs more time to complete authentication it can send
back
WAIT option
Signature option 0
If the server refuses to offer service, as the time in request is
out of bounds, the server sends back OFFER which MUST contain
only the following options: (EMPTY OFFER).
IDENTITY option
Signature option
If server is unable to authenticate the identity of the client, the
Expires January 30, 1998 [Page11]
server MUST ignore the client messages. The server SHOULD log the
event and CAN ignore requests from the same hardware address for a
fixed time.
6.1.3 Client DHCP-REQUEST processing
If the server has accepted the client's identity, the client can now
send the REQUEST message, and this message MUST be signed by its
public key in order for other servers to verify that their
offers were declined. The following options MUST be present:
IDENTITY
Security option (alg=1)
6.2 Future communication
Once a client that does not share a secret with the server selected
has been configured, it can optionally authenticate the server as
specified in[DHCPVERSERV]. All future communiction between the
client and the server MUST contain data protection. It can also
attempt to exchange secrets with the server via an optional
protocol extension "To Be Determined". If IPSEC is available it
CAN be used to protect future communication until the client is
renumbered. The client and server can also elect to use RSA
signatures on all communication.
6.3 Computational complexity of Simple Authentication Protocol
This protocol places most of the cost of the expensive public key
operations on the client. Servers need to generate signatures on all
messages to clients that do not share secrets with them.
The cost of verifying the public keys of the client can be to a
large extent offloaded to the DNSSEC server if a DNS transaction
signature mechanism[RFC2065,TSIG] is used to protect the
communication.
6.4 Client security requirements
Security enabled DHCP clients MUST be able to store their identity
and private key between reboots. These same clients SHOULD have
a clock that keeps reasonable good time. The client SHOULD be
able to store multiple Server Identities and Shared secrets
between reboots. Clients MUST be able to perform the following
security operations: RSA/MD5 digital signatures and HMAC-MD5.
6.5 Server security requirements
Security enabled DHCP servers MUST be able to store identities and
shared secrets with a large number of clients. Servers MUST be able
to perform RSA/MD5 and HMAC-MD5 operations. Servers MUST be
configured with either secure DNS resolver, or other form of
trusted communication with DNSSEC server.
Expires January 30, 1998 [Page12]
7. Security considerations 7. Security considerations
This document is about security. This document addresses how to add security features to the
unsecured DHCP protocol.
8. References 7. References
[DHCP] R. Droms, "Dynamic Host Configuration Protocol", RFC [DHCP] R. Droms, "Dynamic Host Configuration Protocol", RFC
1541, Bucknell University, October 1993. 2131, Bucknell University, April 1997.
[DHCAUTH] R. Droms, "Authentication for DHCP Messages", [DHCAUTH] R. Droms, "Authentication for DHCP Messages",
Internet Draft <draft-ietf-dhc-authentication-03.txt> November Internet Draft <draft-ietf-dhc-authentication-03.txt> November
1996 1996
[DNSSEC] D. Eastlake, C. Kaufman, "Domain Name System Security [DHCPv6] J. Bound, C. Perkins,
Extensions", RFC 2065, January 1997. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
[DHCPv6EXT] C. Perkins, "Extensions for DHCPv6", Internet Draft
<draft-ietf-dhc-v6exts-06.txt> May 1997
[DHCPVERSERV] R. Watson, O. Gudmundsson,
"DHCP Server verification by client via DNSSEC",
<draft-watson-dhc-serv-ver-00.txt> July 1997.
[HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", February 1997 Hashing for Message Authentication", RFC 2104, February 1997
[Intserver] R. Droms, K. Kinnear, "An Inter-server Protocol for
DHCP", Internet Draft <draft-ietf-dhc-interserver-alt-00.txt>,
April 1997
[Server] R. Droms, R. Cole, "An Inter-server Protocol for
DHCP", Internet Draft <draft-ietf-dhc-interserver-01.txt>
March 1997.
[IPSEC] R. Atkinson, "Security Architecture for the Internet [IPSEC] R. Atkinson, "Security Architecture for the Internet
Protocol", Internet Draft <draft-ietf-ipsec-arch-sec-01.txt>, Protocol", Internet Draft <draft-ietf-ipsec-arch-sec-01.txt>,
November 1996. November 1996.
[RFC1035] P. Mockapetris, "Domain Names - Implementation and
Specification," RFC 1034, ISI, November 1987.
[RFC1305] Mills, D., "Network Time Protocol (v3)", RFC 1305,
March 1992.
[RFC1825] R. Atkinson, "Security Architecture for the Internet [RFC1825] R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 1825, September 1995. Protocol", RFC 1825, September 1995.
[Server] R. Droms, R. Cole, "An Inter-server Protocol for DHCP" [RFC2065] D. Eastlake, C. Kaufman, "Domain Name System Security
Internet Draft <draft-ietf-dhc-interserver-01.txt> March 1997. Extensions", RFC 2065, January 1997.
[SRV] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the [SRV] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the
Expires January 30, 1998 [Page13]
location of services (DNS SRV)", RFC 2052, October 1996. location of services (DNS SRV)", RFC 2052, October 1996.
[RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
[NETSEC] C. Kaufman, R. Perlman, M. Speniner, "Network
Security: PRIVATE Communications in a PUBLIC World", Prentice
Hall 1995.
9. Author address 9. Author address
Olafur Gudmundsson Olafur Gudmundsson
Trusted Information System Trusted Information System
3060 Washington Road 3060 Washington Road
Glenwood, MD 21738 Glenwood, MD 21738
+1 301 854 5794 +1 301 854 5794
<ogud@tis.com> <ogud@tis.com>
Expires January 30, 1998 [Page14]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/