Dynamic Host Configuration Working V. Gupta
Group Sun Labs
Internet-Draft February 28, 2003
Expires: August 29, 2003
Flexible Authentication for DHCP Messages
<draft-gupta-dhcp-auth-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 29, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo proposes a new protocol for DHCP authentication within the
general framework outlined in RFC 3118 [4]. This protocol uses
public-key cryptography, in the form of digital signatures, for
authentication. This simplifies key management and supports mutual
authentication between clients and servers belonging to different
administrative domains.
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 [1].
Gupta Expires August 29, 2003 [Page 1]
Internet-Draft DHCP Authentication February 2003
Please send comments on this document to the DHCP mailing list.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Code, Length and Protocol . . . . . . . . . . . . . . . . . . 4
2.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Replay Detection Method (RDM) . . . . . . . . . . . . . . . . 5
2.4 Replay Detection Field . . . . . . . . . . . . . . . . . . . . 5
2.5 Key ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Authenticator . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Client, Server, and Relay Agent Considerations . . . . . . . 9
4. Roaming Support for DHCP Clients . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Revision History . . . . . . . . . . . . . . . . . . . . . . . 13
7. Future Directions . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
Gupta Expires August 29, 2003 [Page 2]
Internet-Draft DHCP Authentication February 2003
1. Introduction
The Dynamic Host Configuration Protocol (DHCP) provides an extensible
framework through which a host can acquire various configuration
parameters from a centrally managed server. Such parameters include
(among many others) the host's IP address, subnet mask, default
router, DNS domain, DNS server and NTP servers. The protocol, as
specified in RFC 2131 [2], is susceptible to various attacks
including source spoofing, message modification, replays and
eavesdropping.
RFC 3118 [4] outlines a mechanism (Protocol 1) for adding
authentication information to DHCP messages that guards against
source spoofing, message alteration and replays. It assumes that the
entities exchanging authenticated information share a secret key not
known to anyone else. The sender uses the key to compute a keyed
hash (or MAC) over the information to be protected and a replay
detection field. This MAC is sent along with the DHCP message. The
receiver recomputes the MAC over the same fields using its copy of
the key and compares the result against the MAC received with the
incoming message. A successful match authenticates the sender.
RFC 3118 also describes another mechanism (Protocol 0) that carries
an authentication token (a password) in the clear and only offers
weak authentication without message integrity protection.
This draft proposes a new protocol, Protocol 2, with the aim of
supporting public-key based authentication. Compared to schemes
based on secret keys, public-key mechanisms ease key management and
offer improved scalability. This draft relies on RFC 3396 [5] for
encoding options longer than 255 octets. Like RFC3118, this note
does not address confidentiality of DHCP messages.
Gupta Expires August 29, 2003 [Page 3]
Internet-Draft DHCP Authentication February 2003
2. Protocol 2
The format of the DHCP authentication option used in this draft (see
Figure 1) is the same as in RFC 3118 with the Authentication
Information field subdivided into two variable length fields.
Key ID: This is a generalization of the "secret ID" field in
Protocol 1 and identifies the public-key needed to verify the
authenticator. Several forms of Key ID are supported including
X.509 certificate chains, hashes of X.509 certificates, and opaque
values.
Authenticator: This is a generalization of the HMAC-MD5 field in
Protocol 1. It contains either a MAC or a digital signature
depending on whether the authentication algorithm uses symmetric-
or asymmetric- key cryptography.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Protocol (2) | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | |
+-+-+-+-+-+-+-+-+ +
| Replay Detection Field (64-bits) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Key ID Type | Key ID length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key ID Value ... (variable length) ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authenticator (variable length) ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the DHCP authentication
option for Protocol 2.
2.1 Code, Length and Protocol
The Code for the authentication option is 90. The Length field
contains the length of the entire option except for the code and
length octets. This length equals 11 plus the size of the
Gupta Expires August 29, 2003 [Page 4]
Internet-Draft DHCP Authentication February 2003
authentication information (in octets) and can typically be encoded
in a single octet. However for certain Key ID types (such as
individual certificates or certificate chains), it is possible that
the total length of the authentication option exceeds 255. In this
case, the authentication option MUST be encoded as described in RFC
3396 and the length field set accordingly.
The Protocol field MUST carry the value 0x02 for this specification.
2.2 Algorithm
The Algorithm field determines which public-key based algorithm is
used to compute the authenticator.
The following algorithms are defined. Algorithm 1 (RSA-MD5) MUST be
supported.
Algorithm
field Description Reference
----- ----------- ---------
1 RSA-MD5 signature PKCS#1
[6]
2 DSA signature FIPS 180-1
[7]
Figure 2: Authentication algorithms
2.3 Replay Detection Method (RDM)
This octet indicates the replay detection method used by the DHCP
client and server. It determines how the Replay Detection Field is
set by the sender and also how its contents are interpreted at the
receiver.
An RDM value of 0 MUST be supported. Other values of RDM will be
defined in a subsequent revision.
2.4 Replay Detection Field
The content and interpretation of this field is controlled by the RDM
(Replay Detection Method) field. If the RDM field contains 0x00, the
replay detection field MUST be set to the value of a monotonically
Gupta Expires August 29, 2003 [Page 5]
Internet-Draft DHCP Authentication February 2003
increasing counter as mandated in RFC 3118.
2.5 Key ID
The Key ID field is used to identify the key that the receiver of an
authenticated DHCP message can use to verify the authenticator. It
is composed of three sub-fields
Key ID Type: Identifies the type of Key ID information carried in
the Key ID field.
Key ID Length: Number of octets used to encode the Key ID Value
field.
Key ID Value: Contains the actual identifier of the key needed to
verify the authenticator.
The following Key ID Types are defined. Implementations MUST support
the OPAQUE Key ID type.
Key ID
Type Description
----- -----------
RESV (0) Reserved
OPAQUE (1) Indicates that the Key ID Value contains
an opaque value. How the receiver uses it
to look up a key is entirely a local matter
at the receiver. The presumption here is
that the sender and receiver have a previously
agreed method of mapping the opaque key ID
value to a key. This definition is consistent
with that of the "Secret ID" in Protocol 1.
X509_CERT_CHAIN Indicates that the Key ID Value subfield
(2) contains a chain of one or more DER encoded
X.509 certificates. The first certificate
in the chain is that of the sender and
each subsequent certificate certifies the
public key used in signing the immediately
preceding certificate. Chains containing
multiple certificates are useful if the
receiver does not have the authenticated
public key of the sender and may need to
follow a certificate chain to establish
the required trust.
Gupta Expires August 29, 2003 [Page 6]
Internet-Draft DHCP Authentication February 2003
The public key contained in the first
certificate MUST be for the same algorithm
as indicated in the Algorithm field. For
example, if the Algorithm field indicates
DSA, the first certificate MUST include a
DSA public key. Similarly, if the Algorithm
field indicates RSA-MD5, the certificate
MUST include an RSA public key authorized for
use in digital signatures. After verifying
the authenticity of the sender's certificate,
the receiver SHOULD cache this trusted
certificate and its MD5 hash. Doing so has
two benefits -- (i) it speeds verification of
subsequent messages from the same sender, and
(ii) allows the sender to save bandwidth by
including just a certificate hash rather
than a complete certificate chain inside
subsequent messages.
CERT_MD5_HASH Indicates that the Key ID Value is the
(3) MD5 hash of a certificate. This is useful
in situations where the sender has reason
to believe that the corresponding
certificate is already available to the
receiver (e.g. it may have been sent in
a previous message or the receiver is known
to have local access to a certificate repository
containing the sender's certificate). Due to
the collision resistance property of MD5, the
hash identifies a unique certificate with a high
degree of confidence. Sending the hash (16
octets) rather than the actual certificate
results in smaller messages.
4 - 255 Reserved
2.6 Authenticator
The computation and verification of the Authenticator field depends
on the type of the authentication algorithm. For RSA-MD5, the
authenticator is the RSA signature (with MD5 hash) computed using the
sender's private key as described in PKCS#1 [6]. For DSA, the
authenticator is the concatenation of two 20 octet numbers (r
followed by s) representing the DSA signature computed according to
FIPS 180-1 [7]. The two numbers are carried "raw" without DER
encoding. In both cases, it is the public-key corresponding to the
private-key used in signing that MUST be identified in the Key ID
Gupta Expires August 29, 2003 [Page 7]
Internet-Draft DHCP Authentication February 2003
field.
The input for these computations is the same. It is the entire DHCP
message (except as noted below) to be protected upto and including
the authentication option. Before signing or computing the MAC, the
authentication option (except for the authenticator) must be
completely filled out and the authenticator field must be set to
zeros. Since a DHCP relay agent may alter the values of the 'giaddr'
and 'hops' fields in the DHCP message, the contents of these two
fields MUST also be set to zero for computation of the signature or
MAC. A relay agent may append the DHCP relay agent option 82 after
the authentication option. Options that appear after the
authentication option will not be protected by the Authenticator
described above.
Gupta Expires August 29, 2003 [Page 8]
Internet-Draft DHCP Authentication February 2003
3. Client, Server, and Relay Agent Considerations
These considerations are not impacted in any way by the use of
Protocol 2 instead of Protocol 1. Readers are referred to RFC 3118
for the details.
Gupta Expires August 29, 2003 [Page 9]
Internet-Draft DHCP Authentication February 2003
4. Roaming Support for DHCP Clients
Roaming can be loosely defined as the ability of a customer to "use
any one of multiple Internet service providers (ISPs), while
maintaining a formal, customer-vendor relationship with only one"
(quoted from RFC 2486 [8]). Each roaming user is uniquely identified
by a Network Access Identifier (NAI) [8] which looks like
joe@acme.net and includes enough information to identify the ISP with
which that user has a formal customer-vendor relationship. Most ISPs
that offer roaming services today use PPP (over dial-up) as the
address allocation mechanism. In the future, ISPs that use DHCP for
address allocation (such as some DSL or Cable Modem ISPs) may also
wish to support roaming. In such a scenario, it is logical to use
NAIs as DHCP client identifiers so both types of ISPs can identify
users in a consistent fashion.
This section outlines how the authentication option may be used to
support DHCP clients roaming between different administrative
domains. For this illustration, we consider a DHCP client associated
with ISP-A that roams to a DHCP-enabled network belonging to ISP-B.
We assume that these two ISPs have a roaming agreement in place. The
agreement may be indirect, e.g. through a broker such as iPass [9]
or GRIC [10]. Before providing full network connectivity to the
client, ISP-B would like to verify that it can bill ISP-A for the
service. The following paragraphs describe one possible sequence of
steps through which this can be accomplished.
We assume that each client has a digital certificate issued by its
ISP (the ISP may out source the actual issuance of certificates but
that is unimportant for our discussion). The certificate is valid as
long as the customer's account active and is revoked when the account
is closed. Besides its own private key, the client also has a
trusted copy of its ISP's public key. These keys may be carried on
removable media such as a smart card. If keys are stored on the
client's local storage (e.g. a portable computer's hard disk), then
the private key MUST be stored encrypted with a user chosen password.
Doing so minimizes the risk of a security breach should the client be
stolen.
The example here uses RSA signatures for authentication.
1. The roaming client, C, establishes link connectivity (e.g. by
plugging into an RJ-45 slot for a 10BaseT connection or by
completing an 802.11 association) and sends out a DHCPDISCOVER
request with a request for authentication. The DHCP client
identifier (Option 61 defined in RFC 2132 [3]) is set to contain
the roaming user's Network Access Identifier.
Gupta Expires August 29, 2003 [Page 10]
Internet-Draft DHCP Authentication February 2003
2. By looking at the NAI from Step 1, a DHCP server, S, on the the
visited network can determine the ISP, ISP-A, to which the client
belongs. The server checks that its ISP, ISP-B, has a roaming
agreement with the client's ISP, ISP-A. If so, it responds with
a DHCPOFFER message containing an authentication option. In this
option, the Algorithm is set to RSA-MD5, the Key ID Type is set
to X509_CERT_CHAIN and the Key ID Value is set to include the
server's certificate (issued by ISP-B) and ISP-B's certificate
signed by ISP-A. If the agreement between ISP-A and ISP-B is
through a broker, K, then the certificate chain may instead
contain: Server's certificate signed by ISP-B, ISP-B's
certificate signed by K and K's certificate signed by ISP-A.
Other combinations are also possible depending on the public keys
that the client is expected to possess. The authenticator
contains a RSA-MD5 signature computed by the server using its
private key.
3. Using a locally available copy of ISP-A's public key, the client
can verify the server's public key and signature and and
authenticate the offer. If authentication is successful, the
client sends out a DHCPREQUEST message. In the authentication
option, Algorithm is set to RSA-MD5, the Key ID Type is set to
X509_CERT_CHAIN, the Key ID Value is set to include the client's
certificate issued by ISP-A and the authenticator contains an
RSA-MD5 signature computed by the client using its private key.
4. The server first verifies the client's certificate (this may
require it to interact with another entity such as a certificate
repository) and uses the public key it contains to verify the
client's signature. If verification succeeds, it sends back a
DHCPACK message completing the sign-on process, otherwise it
sends back a DHCPNAK.
Unlike typical dial-up roaming situations where only the client is
authenticated, the scheme outlined above provides mutual
authentication of the client and server.
Gupta Expires August 29, 2003 [Page 11]
Internet-Draft DHCP Authentication February 2003
5. Security Considerations
This document describes a new protocol based on public-key
cryptography for adding source authentication, integrity protection
and replay detection to DHCP messages. It does not address
confidentiality of these messages.
Gupta Expires August 29, 2003 [Page 12]
Internet-Draft DHCP Authentication February 2003
6. Revision History
Version Date Comments
------- ---- --------
00 Jun 23, 1998 Created initial version.
01 Oct 22, 1999 Incorporated feedback from
the DHCP working group meeting
in Oslo. Changes include:
RDM field expanded to 4 bits,
algorithm field is now a full
octet, key ID length now maintains
16-bit alignment, theft of service
discussion moved to a seprate
document, removed unnecessary
distinction between a single
certificate and a certificate chain
(the former is a special case).
02 Feb 28, 2003 Revived draft in response to renewed
working group interest in public-key
based authentication. Made modifications
to reflect the publication of RFC
3118 and RFC 3396 as proposed standards.
Gupta Expires August 29, 2003 [Page 13]
Internet-Draft DHCP Authentication February 2003
7. Future Directions
DISCUSSION: It seems reasonable to include an authenticator in the
very first message, i.e. DHCPDISCOVER. This gives DHCP servers an
opportunity to authenticate the client before sending back any
network configuration parameters.
TODO: Add nonce based replay protection. The basic idea is as
follows: DHCPDISCOVER message will include a "challenge" from the
client, DHCPOFFER will include the server's "response" and its own
"challenge", DHCPREQUEST will include the client's "response" etc.
Such nonce-based replay detection minimizes the amount of replay
related state that must be maintained across reboots.
Gupta Expires August 29, 2003 [Page 14]
Internet-Draft DHCP Authentication February 2003
8. Acknowledgments
The author wishes to thank members of the DHCP Security Threat Team -
- Ralph Droms, Barr Hibbs, Carl Smith, Bernie Volz and Mimi Zohar for
encouraging him to revive this draft and several individuals (whose
names have been unfortunately misplaced) for providing valuable
feedback on this draft at the Oslo IETF meeting.
Gupta Expires August 29, 2003 [Page 15]
Internet-Draft DHCP Authentication February 2003
References
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[4] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[5] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic
Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[6] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1.5",
PKCS 1, November 1993.
[7] NIST, "Digital Signature Standard", FIPS 180-1, 2000.
[8] Aboba, B. and M. Beadles, "Network Access Identifier", RFC 2486,
January 1999.
[9] <http://www.ipass.com/>
[10] <http://www.gric.com/>
Author's Address
Vipul Gupta
Sun Microsystems Laboratories
2600 Casey Avenue
MS UMTV29-235
Mountain View, CA 94303
USA
Phone: +1 650 336 1681
EMail: vipul.gupta@sun.com
Gupta Expires August 29, 2003 [Page 16]
Internet-Draft DHCP Authentication February 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gupta Expires August 29, 2003 [Page 17]