path: root/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt

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]