One document matched: draft-gupta-dhcp-auth-01.txt-28658.txt
Differences from 01.txt-00.txt
INTERNET-DRAFT Vipul Gupta
SUN Microsystems, Inc
Oct 22, 1998
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 [Bra96]. Internet Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and 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.
Abstract
This memo proposes a new protocol (Protocol 2) for DHCP
authentication within the general framework outlined by Droms and
Arbaugh [DrAr98]. This protocol supports the use of digital
signatures and multiple forms of replay detection in authenticating
Dynamic Host Configuration Protocol (DHCP) messages. The use of
digital signatures simplifies key management and also allows
authentication of mobile clients that roam between different
administrative domains.
1. Introduction:
The Dynamic Host Configuration Protocol (DHCP) [Drom97] provides
an extensible framework through which a host can acquire various
configuration parameters from a centrally managed server.
Configuration parameters that may be obtained through DHCP
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 is susceptible to various
Gupta DHCP Authentication (Protocol 2) [Page 1]
INTERNET-DRAFT Expires April, 1999 Oct 1999
security attacks including source spoofing, message modification,
replays and eavesdropping.
[DrAr99] outlines a mechanism (Protocol 1) for adding
authentication information to DHCP messages. The mechanism
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 this
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 shared key. It compares the
result against the MAC value received with the incoming message.
A successful match authenticates the sender.
Another protocol, Protocol 0, is also described in [DrAr99] but
it carries an authentication token (a password) in the clear and
only offers weak authentication.
This draft proposes a new protocol, Protocol 2, with the aim of
supporting public-key based authentication. It also includes hooks
for future support of multiple forms of replay detection (e.g.
using nonces). Like [DrAr99], this note does not address
confidentiality of DHCP messages.
This note is not a stand-alone document and must be read in
conjunction with [DrAr99]. Additionally, the reader is assumed to
be familiar with the following:
o Dynamic Host Configuration Protocol [Drom97]
o DHCP Continuation Option Code [ArKe97]
DISCUSSION:
DHCP options use a single byte for the length field and this
imposes a limit of 255 bytes on the length of a DHCP option.
This draft (like some others) underscores the need to carry
options longer than 255 bytes inside DHCP messages. The DHCP
Continuation Option Code draft proposes one possible solution.
Unfortunately, this draft [ArKe97] is expired. The working group
needs to either revive that draft or agree upon another solution
(such as implicitly coalescing multiple options whenever they
have the same option code).
1.1 Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL"
Gupta DHCP Authentication (Protocol 2) [Page 2]
INTERNET-DRAFT Expires April, 1999 Oct 1999
in this document are to be interpreted as described in RFC 2119
[Brad97].
2. Protocol 2
The general format of the DHCP authentication option in this draft
closely resembles the format in [DrAr99] with minor exceptions.
The "Global Replay Counter" field has been renamed "Replay
Detection Field" to indicate support for multiple forms
of replay detection. Some of these mechanisms may use this
field to carry values that are not monotonically increasing.
For example, one can envision using nonces for replay detection
(as is done in IKE [RFC 2409]). Since nonces are generated
randomly, a sequence of nonces will not be monotonically
increasing (unlike the replay detection counter specified
in [DrAr99]).
The Authentication Information field (starting after the byte
containing RDM) is now subdivided into two variable length fields:
1. Key ID -- This is a generalization of the "secret ID"
field in Protocol 1 and identifies the public-key or
shared-key needed to verify the authenticator.
Several forms of key ID are supported including X.509
certificates, hashes of X.509 certificates, certificate
chains and opaque values.
2. Authenticator -- This is a generalization of the "MAC" 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.
Gupta DHCP Authentication (Protocol 2) [Page 3]
INTERNET-DRAFT Expires April, 1999 Oct 1999
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Replay Detection Field (64-bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | RESV | Key ID Type | Key ID length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key ID Value ... (variable length) ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authenticator (variable length) ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Code for the authentication option is TBD. The Length field
contains the length of the entire option except for the code and
length bytes. This length equals 11 plus the size of the
authentication information (in bytes) and can typically be encoded
in a single byte. However, for certain Key ID types (such as
certificates) it is possible that the total length of the
authentication option exceeds 255. In this case, the DHCP
continuation option code [ArKe97] MUST be used and the length
field MUST be set accordingly (see DISCUSSION in Section 1).
2.1 Algorithm
The Algorithm field determines which of several secret-key or
public-key based authentication algorithms is used to compute
the authenticator information.
The following algorithms are supported (Public-key algorithms
are identified by an asterisk next to their name):
Algorithm
field Description Reference
----- ----------- ---------
1 HMAC-MD5 keyed hash [Rive92], [KBC97]
2 HMAC-SHA keyed hash [NIS94a], [KBC97]
3 DSA* signature [NIS94b]
4 RSA-MD5* RSA encryption [RSA78]
of MD5 hash
Gupta DHCP Authentication (Protocol 2) [Page 4]
INTERNET-DRAFT Expires April, 1999 Oct 1999
Algorithm 1 (HMAC-MD5) MUST be supported.
DISCUSSION:
Edward Lewis has suggested choosing the same values as
used in the DNS records of type KEY and SIG. This
needs to be investigated further.
2.2 Replay Detection Field
The content and interpretation of this field is controlled by
the RDM (Replay Detection Method) bits (described below). As
mentioned in Section 2.3, RDM values other than 0 are currently
reserved. When RDM is 0, the Replay Detection Field is defined
to mimic the "Global Replay Counter" in Protocol 1 [DrA99].
2.3 The Replay Detection Method (RDM) bits
This four-bit field 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.
RDM field Description
--------- -----------
O When the RDM bits are 0, the Replay Detection
field is used in exactly the same manner
as the "Global Counter Field" of Protocol 1
specified in [DrAr99].
1-15 These values are RESERVED and some of them will
be defined in a subsequent revision.
An RDM value of 0 MUST be supported.
2.4 The Resrved bits
The lower four bits in the byte containing RDM are reserved.
These MUST be set to zero and ignored by the receiver.
Subsequent revisions of this protocol may define new processing
behavior for these bits.
2.4 Key ID
The Key ID field is composed of three sub-fields including
a RESERVED byte-long field which MUST be set to zero. Other
sub-fields are:
Key ID Type This identifies the type of Key ID
Gupta DHCP Authentication (Protocol 2) [Page 5]
INTERNET-DRAFT Expires April, 1999 Oct 1999
information carried in the Key ID field.
Key ID Length Length of the Key ID Value field
expressed in bytes.
Key ID Value Contains the actual Key ID which
identifies either a secret key or a
public 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.
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. After verifying
Gupta DHCP Authentication (Protocol 2) [Page 6]
INTERNET-DRAFT Expires April, 1999 Oct 1999
the authenticity of the sender's certificate,
the receiver MUST 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 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
bytes) rather than the actual certificate
results in smaller messages.
4 - 255 RESERVED
DISCUSSION:
Edward Lewis has suggested the inclusion of other certificate
types (e.g. PGP). Need to compile this list based on Working
Group input.
2.5 Authenticator
The computation and verification of the Authenticator field
depends on the type of the authentication Algorithm.
When the Algorithm is one of HMAC-MD5 or HMAC-SHA1, the
authenticator is computed using the HMAC generation algorithm
with the MD5 [Rive2] or SHA [NIS94a] hash functions as described
in [KBC97]. When the Algorithm is DSS [NIS94b], the authenticator
contains the DER encoding of two 20 byte numbers (r followed by
s) representing the DSA signature. When the Algorithm is RSA-MD5,
the authenticator contains the RSA encryption output (using the
sender's private key) of an MD5 hash. In the case of DSS and
RSA-MD5, it is the public-key corresponding to the private-key
used for signing that MUST be identified in the Key ID field.
Gupta DHCP Authentication (Protocol 2) [Page 7]
INTERNET-DRAFT Expires April, 1999 Oct 1999
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 zeroes. 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.
3. Client, Server, and Relay Agent Considerations
These considerations are not affected in any way by the use of
Protocol 2 instead of Protocol 1. Readers are referred to [DrAr99]
for the details.
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 [AbBe99]). Each roaming user is uniquely
identified by a Network Access Identifier (NAI) [AbBe99] 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 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 [iPass] or GRIC [GRIC].
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
Gupta DHCP Authentication (Protocol 2) [Page 8]
INTERNET-DRAFT Expires April, 1999 Oct 1999
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 following example uses DSA 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) is set
to contain the roaming user's Network Access Identifier.
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 DSA, 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 DSA 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 DSA, 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 a DSA signature computed by the client using its
private key.
4. The server first verifies the client's certificate (this
Gupta DHCP Authentication (Protocol 2) [Page 9]
INTERNET-DRAFT Expires April, 1999 Oct 1999
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.
5. Security Considerations
This document describes a mechanism for adding source
authentication, integrity protection and replay detection to DHCP
messages. This mechanism does not address message confidentiality.
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
byte, 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).
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 making "theft of service" even
harder for malicious clients.
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.
Gupta DHCP Authentication (Protocol 2) [Page 10]
INTERNET-DRAFT Expires April, 1999 Oct 1999
Such nonce-based replay detection minimizes the amount of replay
related state that must be maintained across reboots.
References
[AbBe99] Aboba, B. and Beadles, M., "Network Access Identifier"
RFC 2486, Jan. 1999.
[ArKe97] Arbaugh, W. and Keromytis, A., "DHCP Continuation
Option Code", Internet-draft <draft-ietf-dhc-options-
cont-00.txt>, work in progress, Nov. 1997.
[Brad96] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, Oct. 1996.
[Brad97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2219, Mar. 1997.
[Drom97] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, Mar. 1997.
[DrAr99] Droms, R. and Arbaugh, W., "Authentication for DHCP
Messages", Internet-draft <draft-ietf-dhc-
authentication-11.txt>, work in progress, Jun. 1999.
[GRIC] See http://www.gric.com/
[iPass] See http://www.ipass.com/
[KBC97] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC:
Keyed-Hashing for Message Authentication," RFC 2104,
Feb. 1997.
[Mill92] Mills, D., "Network Time Protocol (Version 3)", RFC
1305, Mar. 1992.
[NIS94a] NIST, "Secure Hash Standard", FIPS 180-1, National
Institute of Standards and Technology, U.S. Department of
Commerce, May 1994.
[NIS94b] NIST, "Digital Signature Standard", FIPS 186, National
Institute of Standards and Technology, U.S. Department
of Commerce, May, 1994.
[Rive92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Apr. 1992.
Gupta DHCP Authentication (Protocol 2) [Page 11]
INTERNET-DRAFT Expires April, 1999 Oct 1999
[RSA78] Rivest, R., Shamir, A., and Adleman, L., "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM, v. 21, n. 2,
Feb. 1978.
Author's Address
Vipul Gupta
Sun Microsystems, Inc.
901 San Antonio Rd.
Palo Alto, CA 94303
Tel: +1 650 786 3614
Fax: +1 650 786 6445
EMail: vipul.gupta@sun.com
Gupta DHCP Authentication (Protocol 2) [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 18:37:26 |