1595 lines
57 KiB
Plaintext
1595 lines
57 KiB
Plaintext
|
|
DHC Working Group Ken Hornstein
|
|
INTERNET-DRAFT NRL
|
|
Category: Standards Track Ted Lemon
|
|
<draft-hornstein-dhc-kerbauth-02.txt> Internet Engines, Inc.
|
|
20 February 2000 Bernard Aboba
|
|
Expires: September 1, 2000 Microsoft
|
|
Jonathan Trostle
|
|
Cisco Systems
|
|
|
|
DHCP Authentication Via Kerberos V
|
|
|
|
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.
|
|
|
|
The distribution of this memo is unlimited.
|
|
|
|
1. Copyright Notice
|
|
|
|
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
|
|
|
2. Abstract
|
|
|
|
The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for
|
|
host configuration. In some circumstances, it is useful for the DHCP
|
|
client and server to be able to mutually authenticate as well as to
|
|
guarantee the integrity of DHCP packets in transit. This document
|
|
describes how Kerberos V may be used in order to allow a DHCP client and
|
|
server to mutually authenticate as well as to protect the integrity of
|
|
the DHCP exchange. The protocol described in this document is capable of
|
|
handling both intra-realm and inter-realm authentication.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 1]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
3. Introduction
|
|
|
|
The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for
|
|
host configuration. In some circumstances, it is useful for the DHCP
|
|
client and server to be able to mutually authenticate as well as to
|
|
guarantee the integrity of DHCP packets in transit. This document
|
|
describes how Kerberos V may be used in order to allow a DHCP client and
|
|
server to mutually authenticate as well as to protect the integrity of
|
|
the DHCP exchange. The protocol described in this document is capable
|
|
of handling both intra-realm and inter-realm authentication.
|
|
|
|
3.1. Terminology
|
|
|
|
This document uses the following terms:
|
|
|
|
DHCP client
|
|
A DHCP client or "client" is an Internet host using DHCP to
|
|
obtain configuration parameters such as a network address.
|
|
|
|
DHCP server
|
|
A DHCP server or "server" is an Internet host that returns
|
|
configuration parameters to DHCP clients.
|
|
|
|
Home KDC The KDC corresponding to the DHCP client's realm.
|
|
|
|
Local KDC The KDC corresponding to the DHCP server's realm.
|
|
|
|
3.2. Requirements language
|
|
|
|
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
|
|
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
|
|
described in [1].
|
|
|
|
4. Protocol overview
|
|
|
|
In DHCP authentication via Kerberos V, DHCP clients and servers utilize
|
|
a Kerberos session key in order to compute a message integrity check
|
|
value included within the DHCP authentication option. The message
|
|
integrity check serves to authenticate as well as integrity protect the
|
|
messages, while remaining compatible with the operation of a DHCP relay.
|
|
Replay protection is also provided by a replay counter within the
|
|
authentication option, as described in [3].
|
|
|
|
Each server maintains a list of session keys and identifiers for
|
|
clients, so that the server can retrieve the session key and identifier
|
|
used by a client to which the server has provided previous configuration
|
|
information. Each server MUST save the replay counter from the previous
|
|
authenticated message. To avoid replay attacks, the server MUST discard
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 2]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
any incoming message whose replay counter is not strictly greater than
|
|
the replay counter from the previous message.
|
|
|
|
DHCP authentication, described in [3], must work within the existing
|
|
DHCP state machine described in [4]. For a client in INIT state, this
|
|
means that the client must obtain a valid TGT, as well as a session key,
|
|
within the two round-trips provided by the
|
|
DHCPDISCOVER/OFFER/REQUEST/ACK sequence.
|
|
|
|
In INIT state, the DHCP client submits an incomplete AS_REQ to the DHCP
|
|
server within the DHCPDISCOVER message. The DHCP server then completes
|
|
the AS_REQ using the IP address to be assigned to the client, and
|
|
submits this to the client's home KDC in order to obtain a TGT on the
|
|
client's behalf. Once the home KDC responds with an AS_REP, the DHCP
|
|
server extracts the client TGT and submits this along with its own TGT
|
|
to the home KDC, in order to obtain a user-to-user ticket to the DHCP
|
|
client. The AS_REP as well as the AP_REQ are included by the DHCP server
|
|
in the DHCPOFFER. The DHCP client can then decrypt the AS_REP to obtain
|
|
a home realm TGT and TGT session key, using the latter to decrypt the
|
|
user-to-user ticket to obtain the user-to-user session key. It is the
|
|
user-to-user session key that is used to authenticate and integrity
|
|
protect the client's DHCPREQUEST, and DHCPDECLINE messages. Similarly,
|
|
this same session key is used to compute the integrity attribute in the
|
|
server's DHCPOFFER, DHCPACK and DHCPNAK messages, as described in [3].
|
|
|
|
In the INIT-REBOOT, REBINDING, or RENEWING states, the server can submit
|
|
the home realm TGT in the DHCPREQUEST, along with authenticating and
|
|
integrity protecting the message using an integrity attribute within the
|
|
authentication option. The integrity attribute is computed using the
|
|
existing session key. The DHCP server can then return a renewed user-
|
|
to-user ticket within the DHCPACK message. The authenticated DHCPREQUEST
|
|
message from a client in INIT-REBOOT state can only be validated by
|
|
servers that used the same session key to compute the integrity
|
|
attribute in their DHCPOFFER messages.
|
|
|
|
Other servers will discard the DHCPREQUEST messages. Thus, only servers
|
|
that used the user-to-user session key selected by the client will be
|
|
able to determine that their offered configuration information was not
|
|
selected, returning the offered network address to the server's pool of
|
|
available addresses. The servers that cannot validate the DHCPREQUEST
|
|
message will eventually return their offered network addresses to their
|
|
pool of available addresses as described in section 3.1 of the DHCP
|
|
specification [4].
|
|
|
|
When sending a DHCPINFORM, there are two possible procedures. If the
|
|
client knows the DHCP server it will be interacting with, then it can
|
|
obtain a ticket to the DHCP server from the local realm KDC. This will
|
|
require obtaining a TGT to its home realm, as well as possibly a cross-
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 3]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
realm TGT to the local realm if the local and home realms differ. Once
|
|
the DHCP client has a local realm TGT, it can then request a DHCP server
|
|
ticket in a TGS_REQ. The DHCP client can then include AP_REQ and
|
|
integrity attributes within the DHCPINFORM. The integrity attribute is
|
|
computed as described in [3], using the session key obtained from the
|
|
TGS_REP. The DHCP server replies with a DHCPACK/DHCPNAK, authenticated
|
|
using the same session key.
|
|
|
|
If the DHCP client does not know the DHCP server it is interacting with
|
|
then it will not be able to obtain a ticket to it and a different
|
|
procedure is needed. In this case, the client will include in the
|
|
DHCPINFORM an authentication option with a ticket attribute containing
|
|
its home realm TGT. The DHCP server will then use this TGT in order to
|
|
request a user-to-user ticket from the home KDC in a TGS_REQ. The DHCP
|
|
server will return the user-to-user ticket and will authenticate and
|
|
integrity protect the DHCPACK/DHCPNAK message. This is accomplished by
|
|
including AP_REQ and integrity attributes within the authentication
|
|
option included with the DHCPACK/DHCPNAK messages.
|
|
|
|
In order to support the DHCP client's ability to authenticate the DHCP
|
|
server in the case where the server name is unknown, the Kerberos
|
|
principal name for the DHCP server must be of type KRB_NT_SRV_HST with
|
|
the service name component equal to 'dhcp'. For example, the DHCP server
|
|
principal name for the host srv.foo.org would be of the form
|
|
dhcp/srv.foo.org. The client MUST validate that the DHCP server
|
|
principal name has the above format. This convention requires that the
|
|
administrator ensure that non-DHCP server principals do not have names
|
|
that match the above format.
|
|
|
|
4.1. Authentication Option Format
|
|
|
|
A summary of the authentication option format for DHCP authentication
|
|
via Kerberos V is shown below. The fields are transmitted from left to
|
|
right.
|
|
|
|
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 | Algorithm |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Global Replay Counter |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Global Replay Counter |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Attributes...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Code
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 4]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
TBD - DHCP Authentication
|
|
|
|
Length
|
|
|
|
The length field is a single octet and indicates the length of the
|
|
Protocol, Algorith, and Authentication Information fields. Octets
|
|
outside the range of the length field should be ignored on reception.
|
|
|
|
Protocol
|
|
|
|
TBD - DHCP Kerberos V authentication
|
|
|
|
Algorithm
|
|
|
|
The algorithm field is a single octet and defines the specific
|
|
algorithm to be used for computation of the authentication option.
|
|
Values for the field are as follows:
|
|
|
|
0 - reserved
|
|
1 - HMAC-MD5
|
|
2 - HMAC-SHA
|
|
3 - 255 reserved
|
|
|
|
Global Replay Counter
|
|
|
|
As described in [3], the global replay counter field is 8 octets in
|
|
length. It MUST be set to the value of a monotonically increasing
|
|
counter. Using a counter value such as the current time of day (e.g.,
|
|
an NTP-format timestamp [10]) can reduce the danger of replay
|
|
attacks.
|
|
|
|
Attributes
|
|
|
|
The attributes field consists of type-length-value attributes of the
|
|
following format:
|
|
|
|
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
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Type | Reserved | Payload Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Attribute value...
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
Type
|
|
The type field is a single octet and is defined as follows:
|
|
|
|
0 - Integrity check
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 5]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
1 - TICKET
|
|
2 - Authenticator
|
|
3 - EncTicketPart
|
|
10 - AS_REQ
|
|
11 - AS_REP
|
|
12 - TGS_REQ
|
|
13 - TGS_REP
|
|
14 - AP_REQ
|
|
15 - AP_REP
|
|
20 - KRB_SAFE
|
|
21 - KRB_PRIV
|
|
22 - KRB_CRED
|
|
25 - EncASRepPart
|
|
26 - EncTGSRepPart
|
|
27 - EncAPRepPart
|
|
28 - EncKrbPrvPart
|
|
29 - EncKrbCredPart
|
|
30 - KRB_ERROR
|
|
|
|
Note that the values of the Type field are the same as in the
|
|
Kerberos MSG-TYPE field. As a result, no new number spaces are
|
|
created for IANA administration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 6]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
The following attribute types are allowed within the following
|
|
messages:
|
|
|
|
DISCOVER OFFER REQUEST DECLINE # Attribute
|
|
--------------------------------------------------------
|
|
0 1 1 1 0 Integrity check
|
|
0 0 0-1 0 1 Ticket
|
|
1 0 0 0 10 AS_REQ
|
|
0 1 0 0 11 AS_REP
|
|
0 1 0 0 14 AP_REQ
|
|
0 0-1 0 0 30 KRB_ERROR
|
|
|
|
RELEASE ACK NAK INFORM INFORM # Attribute
|
|
w/known w/unknown
|
|
server server
|
|
---------------------------------------------------------------
|
|
1 1 1 1 0 0 Integrity check
|
|
0 0 0 0 1 1 Ticket
|
|
0 0 0 0 0 10 AS_REQ
|
|
0 0 0 0 0 11 AS_REP
|
|
0 0-1 0 1 0 14 AP_REQ
|
|
0 0 0-1 0 0 30 KRB_ERROR
|
|
|
|
4.2. Client behavior
|
|
|
|
The following section, which incorporates material from [3], describes
|
|
client behavior in detail.
|
|
|
|
4.2.1. INIT state
|
|
|
|
When in INIT state, the client behaves as follows:
|
|
|
|
|
|
[1] As described in [3], the client MUST include the authentication
|
|
request option in its DHCPDISCOVER message along with option 61
|
|
[11] to identify itself uniquely to the server. An AS_REQ attribute
|
|
MUST be included within the authentication request option. This
|
|
(incomplete) AS_REQ will set the FORWARDABLE and RENEWABLE flags
|
|
and MAY include pre-authentication data (PADATA) if the client
|
|
knows what PADATA its home KDC will require. The ADDRESSES field in
|
|
the AS_REQ will be ommitted since the client does not yet know its
|
|
IP address. The ETYPE field will be set to an encryption type that
|
|
the client can accept.
|
|
|
|
[2] The client MUST validate DHCPOFFER messages that include an
|
|
authentication option. Messages including an authentication option
|
|
with a KRB_ERROR attribute and no integrity attribute are treated
|
|
as though they are unauthenticated. More typically, authentication
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 7]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
options within the DHCPOFFER message will include AS_REP, AP_REQ,
|
|
and integrity attributes. To validate the authentication option,
|
|
the client decrypts the enc-part of the AS_REP in order to obtain
|
|
the TGT session key. This is used to decrypt the enc-part of the
|
|
AP_REQ in order to obtain the user-to-user session key. The user-
|
|
to-user session key is then used to compute the message integrity
|
|
check as described in [3], and the computed value is compared to
|
|
the value within the integrity attribute. The client MUST discard
|
|
any messages which fail to pass validation and MAY log the
|
|
validation failure.
|
|
|
|
As described in [3], the client selects one DHCPOFFER message as
|
|
its selected configuration. If none of the DHCPOFFER messages
|
|
received by the client include an authentication option, the client
|
|
MAY choose an unauthenticated message as its selected
|
|
configuration. DHCPOFFER messages including an authentication
|
|
option with a KRB_ERROR attribute and no integrity attribute are
|
|
treated as though they are unauthenticated. The client SHOULD be
|
|
configurable to accept or reject unauthenticated DHCPOFFER
|
|
messages.
|
|
|
|
[3] The client replies with a DHCPREQUEST message that MUST include an
|
|
authentication option. The authentication option MUST include an
|
|
integrity attribute, computed as described in [3], using the user
|
|
to user session key recovered in step 2.
|
|
|
|
[4] As noted in [3], the client MUST validate a DHCPACK message from
|
|
the server that includes an authentication option. DHCPACK or
|
|
DHCPNAK messages including an authentication option with a
|
|
KRB_ERROR attribute and no integrity attribute are treated as
|
|
though they are unauthenticated. The client MUST silently discard
|
|
the DHCPACK if the message fails to pass validation and MAY log the
|
|
validation failure. If the DHCPACK fails to pass validation, the
|
|
client MUST revert to the INIT state and return to step 1. The
|
|
client MAY choose to remember which server replied with an invalid
|
|
DHCPACK message and discard subsequent messages from that server.
|
|
|
|
4.2.2. INIT-REBOOT state
|
|
|
|
When in INIT-REBOOT state, if the user-to-user ticket is still valid,
|
|
the client MUST re-use the session key from the DHCP server user-to-user
|
|
ticket in its DHCPREQUEST message. This is used to generate the
|
|
integrity attribute contained within the authentication option, as
|
|
described in [3]. In the DHCPREQUEST, the DHCP client also includes its
|
|
home realm TGT in a ticket attribute in the authentication option in
|
|
order to assist the DHCP server in renewing the user-to-user ticket. To
|
|
ensure that the user-to-user ticket remains valid throughout the DHCP
|
|
lease period so that the renewal process can proceed, the Kerberos
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 8]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
ticket lifetime SHOULD be set to exceed the DHCP lease time. If the
|
|
user-to-user ticket is expired, then the client MUST return to the INIT
|
|
state.
|
|
|
|
The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages
|
|
if no authenticated messages were received. DHCPACK/DHCPNAK messages
|
|
with an authentication option containing a KRB_ERROR attribute and no
|
|
integrity attribute are treated as though they are unauthenticated. The
|
|
client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
|
|
messages as specified in section 3.2 of the DHCP specification [4].
|
|
|
|
4.2.3. RENEWING state
|
|
|
|
When in RENEWING state, the DHCP client can be assumed to have a valid
|
|
IP address, as well as a TGT to the home realm, a user-to-user ticket
|
|
provided by the DHCP server, and a session key with the DHCP server, all
|
|
obtained during the original DHCP conversation. If the user-to-user
|
|
ticket is still valid, the client MUST re-use the session key from the
|
|
user-to-user ticket in its DHCPREQUEST message to generate the integrity
|
|
attribute contained within the authentication option.
|
|
|
|
Since the DHCP client can renew the TGT to the home realm, it is
|
|
possible for it to continue to hold a valid home realm TGT. However,
|
|
since the DHCP client did not obtain the user-to-user ticket on its own,
|
|
it will need to rely on the DHCP server to renew this ticket. In the
|
|
DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket
|
|
attribute in the authentication option in order to assist the DHCP
|
|
server in renewing the user-to-user ticket.
|
|
|
|
If the DHCP server user-to-user ticket is expired, then the client MUST
|
|
return to INIT state. To ensure that the user-to-user ticket remains
|
|
valid throughout the DHCP lease period so that the renewal process can
|
|
proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP
|
|
lease time. If client receives no DHCPACK messages or none of the
|
|
DHCPACK messages pass validation, the client behaves as if it had not
|
|
received a DHCPACK message in section 4.4.5 of the DHCP specification
|
|
[4].
|
|
|
|
4.2.4. REBINDING state
|
|
|
|
When in REBINDING state, the DHCP client can be assumed to have a valid
|
|
IP address, as well as a TGT to the home realm, a user-to-user ticket
|
|
and a session key with the DHCP server, all obtained during the original
|
|
DHCP conversation. If the user-to-user ticket is still valid, the
|
|
client MUST re-use the session key from the user-to-user ticket in its
|
|
DHCPREQUEST message to generate the integrity attribute contained within
|
|
the authentication option, as described in [3].
|
|
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 9]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
Since the DHCP client can renew the TGT to the home realm, it is
|
|
possible for it to continue to hold a valid home realm TGT. However,
|
|
since the DHCP client did not obtain the user-to-user ticket on its own,
|
|
it will need to rely on the DHCP server to renew this ticket. In the
|
|
DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket
|
|
attribute in the authentication option in order to assist the DHCP
|
|
server in renewing the user-to-user ticket.
|
|
|
|
If the user-to-user ticket is expired, then the client MUST return to
|
|
INIT state. To ensure that the user-to-user ticket remains valid
|
|
throughout the DHCP lease period so that the renewal process can
|
|
proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP
|
|
lease time. If client receives no DHCPACK messages or none of the
|
|
DHCPACK messages pass validation, the client behaves as if it had not
|
|
received a DHCPACK message in section 4.4.5 of the DHCP specification
|
|
[4].
|
|
|
|
4.2.5. DHCPRELEASE message
|
|
|
|
Clients sending a DHCPRELEASE MUST include an authentication option. The
|
|
authentication option MUST include an integrity attribute, computed as
|
|
described in [3], using the user to user session key.
|
|
|
|
4.2.6. DHCPDECLINE message
|
|
|
|
Clients sending a DHCPDECLINE MUST include an authentication option. The
|
|
authentication option MUST include an integrity attribute, computed as
|
|
described in [3], using the user to user session key.
|
|
|
|
4.2.7. DHCPINFORM message
|
|
|
|
Since the client already has some configuration information, it can be
|
|
assumed that it has the ability to obtain a home or local realm TGT
|
|
prior to sending the DHCPINFORM.
|
|
|
|
If the DHCP client knows which DHCP server it will be interacting with,
|
|
then it SHOULD include an authentication option containing AP_REQ and
|
|
integrity attributes within the DHCPINFORM. The DHCP client first
|
|
requests a TGT to the local realm via an AS_REQ and then using the TGT
|
|
returned in the AS_REP to request a ticket to the DHCP server from the
|
|
local KDC in a TGS_REQ. The session key obtained from the TGS_REP will
|
|
be used to generate the integrity attribute as described in [3].
|
|
|
|
If the DHCP client does not know what DHCP server it will be talking to,
|
|
then it cannot obtain a ticket to the DHCP server. In this case, the
|
|
DHCP client MAY send an unauthenticated DHCPINFORM or it MAY include an
|
|
authentication option including a ticket attribute only. The ticket
|
|
attribute includes a TGT for the home realm. The client MUST validate
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 10]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
that the DHCP server name in the received Kerberos AP_REQ message is of
|
|
the form dhcp/.... as described in section 4.
|
|
|
|
The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages
|
|
if no authenticated messages were received. DHCPACK/DHCPNAK messages
|
|
with an authentication option containing a KRB_ERROR attribute and no
|
|
integrity attribute are treated as though they are unauthenticated. The
|
|
client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
|
|
messages as specified in section 3.2 of the DHCP specification [4].
|
|
|
|
4.3. Server behavior
|
|
|
|
This section, which relies on material from [3], describes the behavior
|
|
of a server in response to client messages.
|
|
|
|
4.3.1. After receiving a DHCPDISCOVER message
|
|
|
|
For installations where IP addresses are required within tickets, the
|
|
DHCP server MAY complete the AS_REQ by filling in the ADDRESSES field
|
|
based on the IP address that it will include in the DHCPOFFER. The DHCP
|
|
server sends the AS_REQ to the home KDC with the FORWARDABLE flag set.
|
|
The home KDC then replies to the DHCP server with an AS_REP. The DHCP
|
|
server extracts the client TGT from the AS_REP and forms a TGS_REQ,
|
|
which it sends to the home KDC.
|
|
|
|
If the DHCP server and client are in different realms, then the DHCP
|
|
server will need to obtain a TGT to the home realm from the KDC of its
|
|
own (local) realm prior to sending the TGS_REQ. The TGS_REQ includes the
|
|
DHCP server's TGT within the home realm, has the ENC-TKT-IN-SKEY flag
|
|
set and includes the client home realm TGT in the ADDITIONAL-TICKETS
|
|
field, thus requesting a user-to ticket to the DHCP client. The home
|
|
KDC then returns a user-to-user ticket in a TGS_REP. The user-to-user
|
|
ticket is encrypted in the client's home realm TGT session key.
|
|
|
|
In order to recover the user-to-user session key, the DHCP server
|
|
decrypts the enc-part of the TGS_REP. To accomplish this, the DHCP
|
|
server uses the session key that it shares with the home realm, obtained
|
|
in the AS_REQ/AS_REP conversation that it used to obtain its own TGT to
|
|
the home realm.
|
|
|
|
The DHCP server then sends a DHCPOFFER to the client, including AS_REP,
|
|
AP_REQ and integrity attributes within the authentication option. The
|
|
AS_REP attribute encapsulates the AS_REP sent to the DHCP server by the
|
|
home KDC. The AP_REQ attribute includes an AP_REQ constructed by the
|
|
DHCP server based on the TGS_REP sent to it by the home KDC. The server
|
|
also includes an integrity attribute generated as specified in [3] from
|
|
the user-to-user session key. The server MUST record the user-to-user
|
|
session key selected for the client and use that session key for
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 11]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
validating subsequent messages with the client.
|
|
|
|
4.3.2. After receiving a DHCPREQUEST message
|
|
|
|
The DHCP server uses the user-to-user session key in order to validate
|
|
the integrity attribute contained within the authentication option,
|
|
using the method specified in [3]. If the message fails to pass
|
|
validation, it MUST discard the message and MAY choose to log the
|
|
validation failure.
|
|
|
|
If the message passes the validation procedure, the server responds as
|
|
described in [4], including an integrity attribute computed as specified
|
|
in [3] within the DHCPACK or DHCPNAK message.
|
|
|
|
If the authentication option included within the DHCPREQUEST message
|
|
contains a ticket attribute then the DHCP server will use the home realm
|
|
TGT included in the ticket attribute in order to renew the user-to-user
|
|
ticket, which it returns in an AP_REQ attribute within the DHCPACK.
|
|
DHCPACK or DHCPNAK messages then include an integrity attribute
|
|
generated as specified in [3], using the new user-to-user session key
|
|
included within the AP_REQ.
|
|
|
|
4.3.3. After receiving a DHCPINFORM message
|
|
|
|
The server MAY choose to accept unauthenticated DHCPINFORM messages, or
|
|
only accept authenticated DHCPINFORM messages based on a site policy.
|
|
|
|
When a client includes an authentication option in a DHCPINFORM message,
|
|
the server MUST respond with an authenticated DHCPACK or DHCPNAK
|
|
message. If the DHCPINFORM message includes an authentication option
|
|
including AP_REQ and integrity attributes, the DHCP server decrypts the
|
|
AP_REQ attribute and then recovers the session key. The DHCP server than
|
|
validates the integrity attribute included in the authentication option
|
|
using the session key. If the integrity attribute is invalid then the
|
|
DHCP server MUST silently discard the DHCPINFORM message.
|
|
|
|
If the authentication option only includes a ticket attribute and no
|
|
integrity or AP_REQ attributes, then the DHCP server should assume that
|
|
the client needs the server to obtain a user-to-user ticket from the
|
|
home realm KDC. In this case, the DHCP server includes the client home
|
|
realm TGT and its own home realm TGT in a TGS_REQ to the home realm KDC.
|
|
It then receives a user-to-user ticket from the home realm KDC in a
|
|
TGS_REP. The DHCP server will then include AP_REQ and integrity
|
|
attributes within the DHCPACK/DHCPNAK.
|
|
|
|
If the client does not include an authentication option in the
|
|
DHCPINFORM, the server can either respond with an unauthenticated
|
|
DHCPACK message, or a DHCPNAK if the server does not accept
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 12]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
unauthenticated clients.
|
|
|
|
4.3.4. After receiving a DHCPRELEASE message
|
|
|
|
The DHCP server uses the session key in order to validate the integrity
|
|
attribute contained within the authentication option, using the method
|
|
specified in [3]. If the message fails to pass validation, it MUST
|
|
discard the message and MAY choose to log the validation failure.
|
|
|
|
If the message passes the validation procedure, the server responds as
|
|
described in [4], marking the client's network address as not allocated.
|
|
|
|
4.3.5. After receiving a DHCPDECLINE message
|
|
|
|
The DHCP server uses the session key in order to validate the integrity
|
|
attribute contained within the authentication option, using the method
|
|
specified in [3]. If the message fails to pass validation, it MUST
|
|
discard the message and MAY choose to log the validation failure.
|
|
|
|
If the message passes the validation procedure, the server proceeds as
|
|
described in [4].
|
|
|
|
4.4. Error handling
|
|
|
|
When an error condition occurs during a Kerberos exchange, Kerberos
|
|
error messages can be returned by either side. These Kerberos error
|
|
messages MAY be logged by the receiving and sending parties.
|
|
|
|
In some cases, it may be possible for these error messages to be
|
|
included within the authentication option via the KRB_ERROR attribute.
|
|
However, in most cases, errors will result in messages being silently
|
|
discarded and so no response will be returned.
|
|
|
|
For example, if the home KDC returns a KRB_ERROR in response to the
|
|
AS_REQ submitted by the DHCP server on the client's behalf, then the
|
|
DHCP server will conclude that the DHCPDISCOVER was not authentic, and
|
|
will silently discard it.
|
|
|
|
However, if the AS_REQ included PADATA and the home KDC responds with an
|
|
AS_REP, then the DHCP server can conclude that the client is authentic.
|
|
If the subsequent TGS_REQ is unsuccessful, with a KRB_ERROR returned by
|
|
the home KDC in the TGS_REP, then the fault may lie with the DHCP server
|
|
rather than with the client. In this case, the DHCP server MAY choose to
|
|
return a KRB_ERROR within the authentication option included in the
|
|
DHCPOFFER. The client will then treat this as an unauthenticated
|
|
DHCPOFFER.
|
|
|
|
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 13]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
Similarly, if the integrity attribute contained in the DHCPOFFER proves
|
|
invalid, the client will silently discard the DHCPOFFER and instead
|
|
accept an offer from another server if one is available. If the
|
|
integrity attribute included in the DHCPACK/DHCPNAK proves invalid, then
|
|
the client behaves as if it did not receive a DHCPACK/DHCPNAK.
|
|
|
|
When in INIT-REBOOT, REBINDING or RENEWING state, the client will
|
|
include a ticket attribute and integrity attribute within the
|
|
authentication option of the DHCPREQUEST, in order to assist the DHCP
|
|
server in renewing the user-to-user ticket. If the integrity attribute
|
|
is invalid, then the DHCP server MUST silently discard the DHCPREQUEST.
|
|
|
|
However, if the integrity attribute is successfully validated by the
|
|
DHCP server, but the home realm TGT included in the ticket attribute is
|
|
invalid (e.g. expired), then the DHCP server will receive a KRB_ERROR in
|
|
response to its TGS_REQ to the home KDC. In this case, the DHCP server
|
|
MAY respond with a DHCPNAK including a KRB_ERROR attribute and no
|
|
integrity attribute within the authentication option. This will force
|
|
the client back to the INIT state, where it can receive a valid home
|
|
realm TGT.
|
|
|
|
Where the client included PADATA in the AS_REQ attribute of the
|
|
authentication option within the DHCPDISCOVER and the AS_REQ was
|
|
successfully validated by the KDC, the DHCP server will conclude that
|
|
the DHCP client is authentic. In this case if the client successfully
|
|
validates the integrity attribute in the DHCPOFFER, but the server does
|
|
not validate the integrity attribute in the client's DHCPREQUEST, the
|
|
server MAY choose to respond with an authenticated DHCPNAK containing a
|
|
KRB_ERROR attribute.
|
|
|
|
4.5. PKINIT issues
|
|
|
|
When public key authentication is supported with Kerberos as described
|
|
in [8], the client certificate and a signature accompany the initial
|
|
request in the preauthentication fields. As a result, it is conceivable
|
|
that the incomplete AS_REQ included in the DHCPDISCOVER packet may
|
|
exceed the size of a single DHCP option, or even the MTU size. As noted
|
|
in [4], a single option may be as large as 255 octets. If the value to
|
|
be passed is larger than this the client concatenates together the
|
|
values of multiple instances of the same option.
|
|
|
|
4.6. Examples
|
|
|
|
4.6.1. INIT state
|
|
|
|
In the intra-realm case where the DHCP Kerberos mutual authentication is
|
|
successful, the conversation will appear as follows:
|
|
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 14]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
DHCP DHCP
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ) ->
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ
|
|
U-2-U ->
|
|
<- TGS_REP
|
|
<- DHCPOFFER,
|
|
(AS_REP,
|
|
AP_REQ,
|
|
Integrity)
|
|
DHCPREQUEST
|
|
(Integrity) ->
|
|
<- DHCPACK
|
|
(Integrity)
|
|
|
|
In the case where the KDC returns a KRB_ERROR in response to the AS_REQ,
|
|
the server will silently discard the DHCPDISCOVER and the conversation
|
|
will appear as follows:
|
|
|
|
DHCP DHCP
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ) ->
|
|
AS_REQ ->
|
|
<- KRB_ERROR
|
|
|
|
In the inter-realm case where the DHCP Kerberos mutual authentication is
|
|
successful, the conversation will appear as follows:
|
|
|
|
DHCP DHCP Home Local
|
|
Client Server KDC KDC
|
|
-------------- ------------- --------- ---------
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ) ->
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ ->
|
|
(cross realm,
|
|
for home
|
|
KDC)
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 15]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
<- TGS_REP
|
|
|
|
TGS_REQ
|
|
U-2-U ->
|
|
<- TGS_REP
|
|
<- DHCPOFFER,
|
|
(AS_REP,
|
|
AP_REQ,
|
|
Integrity)
|
|
DHCPREQUEST
|
|
(Integrity) ->
|
|
<- DHCPACK
|
|
(Integrity)
|
|
|
|
In the case where the client includes PADATA in the AS_REQ attribute
|
|
within the authentication option of the DHCPDISCOVER and the KDC returns
|
|
an error-free AS_REP indicating successful validation of the PADATA, the
|
|
DHCP server will conclude that the DHCP client is authentic. If the KDC
|
|
then returns a KRB_ERROR in response to the TGS_REQ, indicating a fault
|
|
that lies with the DHCP server, the server MAY choose not to silently
|
|
discard the DHCPDISCOVER. Instead it MAY respond with a DHCPOFFER
|
|
including a KRB_ERROR attribute within the authentication option. The
|
|
client will then treat this as an unauthenticated DHCPOFFER. The
|
|
conversation will appear as follows:
|
|
|
|
DHCP DHCP
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ
|
|
w/PADATA) ->
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ
|
|
U-2-U ->
|
|
<- KRB_ERROR
|
|
<- DHCPOFFER,
|
|
(KRB_ERROR)
|
|
DHCPREQUEST ->
|
|
<- DHCPACK
|
|
|
|
In the intra-realm case where the client included PADATA in the AS_REQ
|
|
attribute of the authentication option and the AS_REQ was successfully
|
|
validated by the KDC, the DHCP server will conclude that the DHCP client
|
|
is authentic. In this case if the client successfully validates the
|
|
integrity attribute in the DHCPOFFER, but the server does not validate
|
|
the integrity attribute in the client's DHCPREQUEST, the server MAY
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 16]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
choose to respond with an authenticated DHCPNAK containing a KRB_ERROR
|
|
attribute. The conversation will appear as follows:
|
|
|
|
DHCP DHCP
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ
|
|
w/PADATA) ->
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ
|
|
U-2-U ->
|
|
<- TGS_REP
|
|
<- DHCPOFFER,
|
|
(AS_REP,
|
|
AP_REQ,
|
|
Integrity)
|
|
DHCPREQUEST
|
|
(Integrity) ->
|
|
<- DHCNAK
|
|
(KRB_ERROR,
|
|
Integrity)
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ) ->
|
|
|
|
In the intra-realm case where the DHCP client cannot validate the
|
|
integrity attribute in the DHCPOFFER, the client silently discards the
|
|
DHCPOFFER. The conversation will appear as follows:
|
|
|
|
DHCP DHCP
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ) ->
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ
|
|
U-2-U ->
|
|
<- TGS_REP
|
|
<- DHCPOFFER,
|
|
(AS_REP,
|
|
AP_REQ,
|
|
Integrity)
|
|
DHCPREQUEST
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 17]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
[To another server]
|
|
(Integrity) ->
|
|
|
|
In the intra-realm case where the DHCP client cannot validate the
|
|
integrity attribute in the DHCPACK, the client reverts to INIT state.
|
|
The conversation will appear as follows:
|
|
|
|
DHCP DHCP
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ) ->
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ
|
|
U-2-U ->
|
|
<- TGS_REP
|
|
<- DHCPOFFER,
|
|
(AS_REP,
|
|
AP_REQ,
|
|
Integrity)
|
|
DHCPREQUEST
|
|
(Integrity) ->
|
|
<- DHCPACK
|
|
(Integrity)
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ) ->
|
|
|
|
4.6.2. INIT-REBOOT, RENEWING or REBINDING
|
|
|
|
In the intra-realm or inter-realm case where the original user-to-user
|
|
ticket is still valid, and the DHCP server still has a valid TGT to the
|
|
home realm, the conversation will appear as follows:
|
|
|
|
DHCP DHCP Home
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
|
|
DHCPREQUEST
|
|
(TGT,
|
|
Integrity) ->
|
|
TGS_REQ
|
|
U-2-U ->
|
|
<- TGS_REP
|
|
<- DHCPACK
|
|
(AP_REQ,
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 18]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
Integrity)
|
|
|
|
In the intra-realm or inter-realm case where the DHCP server validates
|
|
the integrity attribute in the DHCPREQUEST, but receives a KRB_ERROR in
|
|
response to the TGS_REQ to the KDC, the DHCP sever MAY choose not to
|
|
silently discard the DHCPREQUEST and MAY return an authenticated DHCPNAK
|
|
to the client instead, using the user-to-user session key previously
|
|
established with the client. The conversation appears as follows:
|
|
|
|
DHCP DHCP Home
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
|
|
DHCPREQUEST
|
|
(TGT,
|
|
Integrity) ->
|
|
TGS_REQ
|
|
U-2-U ->
|
|
<- KRB_ERROR
|
|
<- DHCPNAK
|
|
(KRB_ERROR,
|
|
Integrity)
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ) ->
|
|
|
|
In the intra-realm or inter-realm case where the DHCP server cannot
|
|
validate the integrity attribute in the DHCPREQUEST, the DHCP server
|
|
MUST silently discard the DHCPREQUEST and the conversation will appear
|
|
as follows:
|
|
|
|
DHCP DHCP
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
|
|
DHCPREQUEST
|
|
(TGT,
|
|
Integrity) ->
|
|
Silent discard
|
|
[Sequence repeats
|
|
until timeout]
|
|
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ) ->
|
|
|
|
In the intra-realm or inter-realm case where the original user-to-user
|
|
ticket is still valid, the server validates the integrity attribute in
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 19]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
the DHCPREQUEST, but the client fails to validate the integrity
|
|
attribute in the DHCPACK, the client will silently discard the DHCPACK.
|
|
The conversation will appear as follows:
|
|
|
|
DHCP DHCP
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
|
|
DHCPREQUEST
|
|
(TGT,
|
|
Integrity) ->
|
|
|
|
<- DHCPACK
|
|
(AP_REQ,
|
|
Integrity)
|
|
DHCPDISCOVER
|
|
(Incomplete
|
|
AS_REQ) ->
|
|
|
|
4.6.3. DHCPINFORM (with known DHCP server)
|
|
|
|
In the case where the DHCP client knows the DHCP server it will be
|
|
interacting with, the DHCP client will obtain a ticket to the DHCP
|
|
server and will include AP_REQ and integrity attributes within the
|
|
DHCPINFORM.
|
|
|
|
Where the DHCP Kerberos mutual authentication is successful, the
|
|
conversation will appear as follows:
|
|
|
|
DHCP DHCP
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ ->
|
|
<- TGS_REP
|
|
DHCPINFORM
|
|
(AP_REQ,
|
|
Integrity) ->
|
|
<- DHCPACK
|
|
(Integrity)
|
|
|
|
In the inter-realm case where the DHCP Kerberos mutual authentication is
|
|
successful, the conversation will appear as follows:
|
|
|
|
DHCP DHCP Home Local
|
|
Client Server KDC KDC
|
|
-------------- ------------- --------- ---------
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 20]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ ->
|
|
<- TGS_REP
|
|
TGS_REQ ->
|
|
<- TGS_REP
|
|
DHCPINFORM
|
|
(AP_REQ,
|
|
Integrity) ->
|
|
<- DHCPACK
|
|
(Integrity)
|
|
|
|
In the inter-realm case where the DHCP server fails to validate the
|
|
integrity attribute in the DHCPINFORM, the server MUST silently discard
|
|
the DHCPINFORM. The conversation will appear as follows:
|
|
|
|
DHCP DHCP Home Local
|
|
Client Server KDC KDC
|
|
-------------- ------------- --------- ---------
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ ->
|
|
<- TGS_REP
|
|
TGS_REQ ->
|
|
<- TGS_REP
|
|
DHCPINFORM
|
|
(AP_REQ,
|
|
Integrity) ->
|
|
<- DHCPACK
|
|
(Integrity)
|
|
DHCPINFORM
|
|
(AP_REQ,
|
|
Integrity) ->
|
|
|
|
In the inter-realm case where the DHCP client fails to validate the
|
|
integrity attribute in the DHCPACK, the client MUST silently discard the
|
|
DHCPACK. The conversation will appear as follows:
|
|
|
|
DHCP DHCP Home Local
|
|
Client Server KDC KDC
|
|
-------------- ------------- --------- ---------
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ ->
|
|
<- TGS_REP
|
|
TGS_REQ ->
|
|
<- TGS_REP
|
|
DHCPINFORM
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 21]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
(AP_REQ,
|
|
Integrity) ->
|
|
|
|
4.6.4. DHCPINFORM (with unknown DHCP server)
|
|
|
|
In the case where the DHCP client does not know the DHCP server it will
|
|
be interacting with, the DHCP client will only include a ticket
|
|
attribute within the DHCPINFORM. Thus the DHCP server will not be able
|
|
to validate the authentication option.
|
|
|
|
Where the DHCP client is able to validate the DHCPACK and no error
|
|
occur, the onversation will appear as follows:
|
|
|
|
DHCP DHCP
|
|
Client Server KDC
|
|
-------------- ------------- ---------
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
DHCPINFORM
|
|
(Ticket) ->
|
|
TGS_REQ
|
|
U-2-U ->
|
|
<- TGS_REP
|
|
<- DHCPACK
|
|
(AP_REQ,
|
|
Integrity)
|
|
|
|
In the inter-realm case where the DHCP server needs to obtain a TGT to
|
|
the home realm, and where the client successfully validates the DHCPACK,
|
|
the conversation will appear as follows:
|
|
|
|
DHCP DHCP Home Local
|
|
Client Server KDC KDC
|
|
-------------- ------------- --------- ---------
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
DHCPINFORM
|
|
(Ticket) ->
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ ->
|
|
(cross realm,
|
|
for home
|
|
KDC)
|
|
<- TGS_REP
|
|
|
|
TGS_REQ
|
|
U-2-U ->
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 22]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
<- TGS_REP
|
|
<- DHCPACK
|
|
(AP_REQ,
|
|
Integrity)
|
|
|
|
In the inter-realm case where the local KDC returns a KRB_ERROR in
|
|
response to the TGS_REQ from the DHCP server, the DHCP server MAY return
|
|
a KRB_ERROR within the DHCP authentication option included in a DHCPNAK.
|
|
The conversation will appear as follows:
|
|
|
|
DHCP DHCP Home Local
|
|
Client Server KDC KDC
|
|
-------------- ------------- --------- ---------
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
DHCPINFORM
|
|
(Ticket) ->
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ ->
|
|
(cross realm,
|
|
for home
|
|
KDC)
|
|
<- KRB_ERROR
|
|
<- DHCPNAK
|
|
(KRB_ERROR)
|
|
|
|
|
|
In the inter-realm case where the DHCP client fails to validate the
|
|
integrity attribute in the DHCPACK, the client MUST silently discard the
|
|
DHCPACK. The conversation will appear as follows:
|
|
|
|
DHCP DHCP Home Local
|
|
Client Server KDC KDC
|
|
-------------- ------------- --------- ---------
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
DHCPINFORM
|
|
(Ticket) ->
|
|
AS_REQ ->
|
|
<- AS_REP
|
|
TGS_REQ ->
|
|
(cross realm,
|
|
for home
|
|
KDC)
|
|
<- TGS_REP
|
|
|
|
TGS_REQ
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 23]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
U-2-U ->
|
|
<- TGS_REP
|
|
<- DHCPACK
|
|
(AP_REQ,
|
|
Integrity)
|
|
DHCPINFORM
|
|
(Ticket) ->
|
|
|
|
5. References
|
|
|
|
|
|
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
|
Levels", BCP 14, RFC 2119, March 1997.
|
|
|
|
[2] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service
|
|
(V5)", RFC 1510, September 1993.
|
|
|
|
[3] Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
|
|
Internet draft (work in progress), draft-ietf-dhc-
|
|
authentication-11.txt, June 1999.
|
|
|
|
[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
|
|
1997.
|
|
|
|
[5] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
|
|
Extensions", RFC 2132, March 1997.
|
|
|
|
[6] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
|
|
|
|
[7] Jain, V., Congdon, P., Roese, J., "Network Port Authentication",
|
|
IEEE 802.1 PAR submission, June 1999.
|
|
|
|
[8] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray,
|
|
J., Trostle, J., "Public Key Cryptography for Initial
|
|
Authentication in Kerberos", Internet draft (work in progress),
|
|
draft-ietf-cat-kerberos-pk-init-09.txt, June 1999.
|
|
|
|
[9] Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B.,
|
|
Medvinsky, A., Hur, M., "Public Key Cryptography for Cross-Realm
|
|
Authentication in Kerberos", Internet draft (work in progress),
|
|
draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999.
|
|
|
|
[10] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
|
|
1992.
|
|
|
|
[11] Henry, M., "DHCP Option 61 UUID Type Definition", Internet draft
|
|
(work in progress), draft-henry-DHCP-opt61-UUID-type-00.txt,
|
|
November 1998.
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 24]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
6. Security Considerations
|
|
|
|
DHCP authentication, described in [3], addresses the following threats:
|
|
|
|
Modification of messages
|
|
Rogue servers
|
|
Unauthorized clients
|
|
|
|
This section describes how DHCP authentication via Kerberos V addresses
|
|
each of these threats.
|
|
|
|
6.1. Client security
|
|
|
|
As noted in [3], it may be desirable to ensure that IP addresses are
|
|
only allocated to authorized clients. This can serve to protect against
|
|
denial of service attacks. To address this issue it is necessary for
|
|
DHCP client messages to be authenticated. In order to guard against
|
|
message modification, it is also necessary for DHCP client messages to
|
|
be integrity protected.
|
|
|
|
Note that this protocol does not make use of KRB_SAFE, so as to allow
|
|
modification of mutable fields by the DHCP relay. Replay protection is
|
|
therefore provided within the DHCP authentication option itself.
|
|
|
|
In DHCP authentication via Kerberos V the DHCP client will authenticate,
|
|
integrity and replay-protect the DHCPREQUEST, DHCPDECLINE and
|
|
DHCPRELEASE messages using a user-to-user session key obtained by the
|
|
DHCP server from the home KDC. If the DHCP client knows the DHCP server
|
|
it will be interacting with, then the DHCP client MAY also authenticate,
|
|
integrity and replay-protect the DHCPINFORM message using a session key
|
|
obtained from the local realm KDC for the DHCP server it expects to
|
|
converse with.
|
|
|
|
Since the client has not yet obtained a session key, DHCPDISCOVER
|
|
packets cannot be authenticated using the session key. However, the
|
|
client MAY include pre-authentication data in the PADATA field included
|
|
in the DHCPDISCOVER packet. Since the PADATA will then be used by the
|
|
DHCP server to request a ticket on the client's behalf, the DHCP server
|
|
will learn from the AS_REP whether the PADATA was acceptable or not.
|
|
Therefore in this case, the DHCPDISCOVER will be authenticated but not
|
|
integrity protected.
|
|
|
|
Where the DHCP client does not know the DHCP server it will be
|
|
interacting with ahead of time, the DHCPINFORM message will not be
|
|
authenticated, integrity or replay protected.
|
|
|
|
Note that snooping of PADATA and TGTs on the wire may provide an
|
|
attacker with a means of mounting a dictionary attack, since these items
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 25]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
are typically encrypted with a key derived from the user's password.
|
|
Thus use of strong passwords and/or pre-authentication methods utilizing
|
|
strong cryptography (see [8]) are recommended.
|
|
|
|
6.2. Network access control
|
|
|
|
DHCP authentication has been proposed as a method of limiting access to
|
|
network media that are not physically secured such as wireless LANs and
|
|
ports in college residence halls. However, it is not particularly well
|
|
suited to this purpose since even if address allocation is denied an
|
|
inauthentic client may use a statically assigned IP address instead, or
|
|
may attempt to access the network using non-IP protocols. As a result,
|
|
other methods, described in [6]-[7], have been proposed for controlling
|
|
access to wireless media and switched LANs.
|
|
|
|
6.3. Server security
|
|
|
|
As noted in [3], it may be desirable to protect against rogue DHCP
|
|
servers put on the network either intentionally or by accident. To
|
|
address this issue it is necessary for DHCP server messages to be
|
|
authenticated. In order to guard against message modification, it is
|
|
also necessary for DHCP server messages to be integrity protected.
|
|
Replay protection is also provided within the DHCP authentication
|
|
option.
|
|
|
|
All messages sent by the DHCP server are authenticated and integrity and
|
|
replaly protected using a session key. This includes the DHCPOFFER,
|
|
DHCPACK, and DHCPNAK messages. The session key is used to compute the
|
|
DHCP authentication option, which is verified by the client.
|
|
|
|
In order to provide protection against rogue servers it is necessary to
|
|
prevent rogue servers from obtaining the credentials necessary to act as
|
|
a DHCP server. As noted in Section 4, the Kerberos principal name for
|
|
the DHCP server must be of type KRB_NT_SRV_HST with the service name
|
|
component equal to 'dhcp'. The client MUST validate that the DHCP server
|
|
principal name has the above format. This convention requires that the
|
|
administrator ensure that non-DHCP server principals do not have names
|
|
that match the above format.
|
|
|
|
7. IANA Considerations
|
|
|
|
This draft does not create any new number spaces for IANA
|
|
administration.
|
|
|
|
8. Acknowledgements
|
|
|
|
The authors would like to acknowledge Ralph Droms and William Arbaugh,
|
|
authors of the DHCP authentication draft [3]. This draft incorporates
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 26]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
material from their work; however, any mistakes in this document are
|
|
solely the responsibility of the authors.
|
|
|
|
9. Authors' Addresses
|
|
|
|
Ken Hornstein
|
|
US Naval Research Laboratory
|
|
Bldg A-49, Room 2
|
|
4555 Overlook Avenue
|
|
Washington DC 20375 USA
|
|
|
|
Phone: +1 (202) 404-4765
|
|
EMail: kenh@cmf.nrl.navy.mil
|
|
|
|
Ted Lemon
|
|
Internet Engines, Inc.
|
|
950 Charter Street
|
|
Redwood City, CA 94063
|
|
|
|
Phone: +1 (650) 779 6031
|
|
Email: mellon@iengines.net
|
|
|
|
Bernard Aboba
|
|
Microsoft Corporation
|
|
One Microsoft Way
|
|
Redmond, WA 98052
|
|
|
|
Phone: +1 (425) 936-6605
|
|
EMail: bernarda@microsoft.com
|
|
|
|
Jonathan Trostle
|
|
170 W. Tasman Dr.
|
|
San Jose, CA 95134, U.S.A.
|
|
|
|
Email: jtrostle@cisco.com
|
|
Phone: +1 (408) 527-6201
|
|
|
|
|
|
10. Intellectual Property Statement
|
|
|
|
The IETF takes no position regarding the validity or scope of any
|
|
intellectual property or other rights that might be claimed to pertain
|
|
to the implementation or use of the technology described in this
|
|
document or the extent to which any license under such rights might or
|
|
might not be available; neither does it represent that it has made any
|
|
effort to identify any such rights. Information on the IETF's
|
|
procedures with respect to rights in standards-track and standards-
|
|
related documentation can be found in BCP-11. Copies of claims of
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 27]
|
|
|
|
|
|
INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000
|
|
|
|
|
|
rights made available for publication and any assurances of licenses to
|
|
be made available, or the result of an attempt made to obtain a general
|
|
license or permission for the use of such proprietary rights by
|
|
implementors or users of this specification can be obtained from the
|
|
IETF Secretariat.
|
|
|
|
The IETF invites any interested party to bring to its attention any
|
|
copyrights, patents or patent applications, or other proprietary rights
|
|
which may cover technology that may be required to practice this
|
|
standard. Please address the information to the IETF Executive
|
|
Director.
|
|
|
|
11. Full Copyright Statement
|
|
|
|
Copyright (C) The Internet Society (2000). 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 implmentation 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."
|
|
|
|
12. Expiration Date
|
|
|
|
This memo is filed as <draft-hornstein-dhc-kerbauth-02.txt>, and
|
|
expires October 1, 2000.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hornstein, et al. Standards Track [Page 28]
|
|
|
|
|