DHC Working Group                                          S. Medvinsky
Internet Draft                                                 Motorola
Document: <draft-smedvinsky-dhc-kerbauth-01.txt>
Category: Standards Track                                    P.Lalwaney
Expires: January 2001                                             Nokia

                                                              July 2000


        Kerberos V Authentication Mode for Uninitialized Clients


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   The distribution of this memo is unlimited.  It is filed as <draft-
   smedvinsky-dhc-kerbauth-01.txt>, and expires January 2001. Please
   send comments to the authors.



1. Abstract

   The Dynamic Host Configuration Protocol (DHCP) [1] includes an
   option that allows authentication of all DHCP messages, as specified
   in [2].  This document specifies a DHCP authentication mode based on
   Kerberos V tickets. This provides mutual authentication between a
   DHCP client and server, as well as authentication of all DHCP
   messages.

   This document specifies Kerberos message exchanges between an
   uninitialized client and the KDC (Key Distribution Center) using an
   IAKERB proxy [7] so that the Kerberos key management phase is
   decoupled from, and precedes the address allocation and network
   configuration phase that uses the DHCP authentication option.  In
   order to make use of the IAKERB proxy, this document specifies a
   transport mechanism that works with an uninitialized client (i.e. a

Kerberos V Authentication Mode for Uninitialized Clients     July 2000


   client without an assigned IP address). In addition, the document
   specifies the format of the Kerberos authenticator to be used with
   the DHCP authentication option.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119.

3. Introduction

   3.1 Terminology

   o "DHCP client"

   A DHCP client is an Internet host using DHCP to obtain configuration
   parameters such as a network address.

   o "DHCP server"

   A DHCP server is an Internet host that returns configuration
   parameters to DHCP clients.

   O "Ticket"

   A Kerberos term for a record that helps a client authenticate itself
   to a server; it contains the client's identity, a session key, a
   timestamp, and other information, all sealed using the server's
   secret key. It only serves to authenticate a client when presented
   along with a fresh Authenticator.

   o "Key Distribution Center"

   Key Distribution Center, a network service that supplies tickets and
   temporary session keys; or an instance of that service or the host
   on which it runs. The KDC services both initial ticket and Ticket-
   Granting Ticket (TGT) requests. The initial ticket portion is
   sometimes referred to as the Authentication Server (or service. The
   Ticket-Granting Ticket portion is sometimes referred to as the
   Ticket-Granting Server (or service).

   o "Realm"

   A Kerberos administrative domain that represents a group of
   principals registered at a KDC.  A single KDC may be responsible for
   one or more realms.  A fully qualified principal name includes a
   realm name along with a principal name unique within that realm.

3.2 Protocol Overview



S. Medvinsky, P. Lalwaney                                          -2-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000


   DHCP as defined in [1] defines the protocol exchanges for a client
   to obtain its IP address and network configuration information from
   a DHCP Server. Kerberos V5 as described in [6] defines the protocol
   and message exchanges to mutually authenticate two parties. It is
   our goal to provide authentication support for DHCP using Kerberos.
   This implies that the Kerberos key management exchange has to take
   place before a client gets its IP address from the DHCP Server.
   Kerberos assumes that the client has a network address and can
   contact the Key Distribution Center to obtain its credentials for
   authenticated communication with an application server.

   In this specification we utilize the key exchange using an IAKERB
   proxy described in [7]. This does not require any changes to either
   the IAKERB or the Kerberos V5 specification.  This document also
   specifies a particular transport that allows an uninitialized client
   to contact an IAKERB proxy.

   The Kerberos ticket returned from the key management exchange
   discussed in Section 5 of this document is passed to the DHCP Server
   inside the DHCP authentication option with the new Kerberos
   authenticator type. This is described in Section 6 of this draft.


3.3 Related Work

   A prior Internet Draft [3] outlined the use of Kerberos-based
   authentication for DHCP. The proposal tightly coupled the Kerberos
   client state machines and the DHCP client state machines. As a
   result, the Kerberos key management messages were carried in DHCP
   messages, along with the Kerberos authenticators. In addition, the
   first DHCP message exchange (request, offer) is not authenticated.

   We propose a protocol exchange where Kerberos key management is
   decoupled from and precedes authenticated DHCP exchanges. This
   implies that the Kerberos ticket returned in the initial key
   management exchange could be used to authenticate servers assigning
   addresses by non-DHCP address assignment mechanisms like RSIP [4]
   and for service specific parameter provisioning mechanisms using SLP
   [5].














S. Medvinsky, P. Lalwaney                                          -3-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000



4. System Architecture


     Client
    --------                            --------
   |        |   5.Authenticated DHCP   |        |
   |  DHCP  |<------------------------>| DHCP   |
   | client |                          | server |
   |        |                          |        |
   |        |                          |        |
   |Kerberos|                          |        |
   | Client |                          |        |
    --------                            --------
       ^
       |
       |
       |
       |                                -------
        ------------------------------>|       |
         Kerberos Key Mgmt             | Proxy |
         messages:                     |       |
          1. AS Request  / 2.AS Reply   -------
          3. TGS Request / 4.TGS Reply     ^
                                           | Kerberos
                                           | Key Mgmt messages
                                           v (1, 2, 3, 4)
                                        --------
                                       |        |
                                       |  KDC   |
                                       |        |
                                        --------

     Figure 1: System blocks and message interactions between them


   In this architecture, the DHCP client obtains a Kerberos ticket from
   the Key Distribution Center (KDC) using standard Kerberos messages,
   as specified in [6].  The client, however, contacts the KDC via a
   proxy server, according to the IAKERB mechanism, described in [7].
   The are several reasons why a client has to go through this proxy in
   order to contact the KDC:

  a)The client may not know the host address of the KDC and may be
     sending its first request message as a broadcast on a local
     network.  The KDC may not be located on the local network, and
     even if it were - it will be unable to communicate with a client
     without an IP address.  This document describes a specific
     mechanism that may be used by a client to communicate with the
     Kerberos proxy.



S. Medvinsky, P. Lalwaney                                          -4-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000


  b)The client may not know its Kerberos realm name.  The proxy is
     able to fill in the missing client realm name in an AS Request
     message, as specified in IAKERB.  Note that in the case that
     PKINIT pre-authenticator is used [8], the realm name in the AS
     Request may be the KDC realm name and not the clientÆs realm name.

  c) The client does not know the realm name of the DHCP server.

     According to IAKERB, when the client sends a TGS Request with a
     missing server realm name, the proxy will return to the client an
     error message containing the missing realm name.

     Note that in this case the proxy could return the client a wrong
     realm name and the client could be fooled into obtaining a ticket
     for the wrong DHCP server (on the same local network).  However,
     the wrong DHCP server must still be a registered principal in a
     KDC database.  In some circumstances this may be an acceptable
     compromise.  Also, see the security considerations section.

     IAKERB describes the proxy as part of an application server - the
     DHCP server in this case.  However, in this document we are not
     requiring the proxy to be integrated with the DHCP server.  The
     same IAKERB mechanisms apply in the more general case, where the
     proxy is an independent application.  This proxy, however, MUST be
     reachable by a client via a local network broadcast.

     After a client has obtained a Kerberos ticket for the DHCP server,
     it will use it as part of an authentication option in the DHCP
     messages.  The only extension to the DHCP protocol is the addition
     of a new authenticator type based on Kerberos tickets.

4.1 Cross-Realm Authentication

   Figure 1 shows a client communicating with a single KDC via a proxy.
   However, the DHCP clientÆs realm may be different from the DHCP
   serverÆs realm.  In that case, the client may need to first contact
   the KDC in its local realm to obtain a cross-realm TGT.  Then, the
   client would use the cross-realm TGT to contact the KDC in the DHCP
   serverÆs realm, as specified in [6].

   In the following example a client doesnÆt know its realm or the DHCP
   serverÆs realm, which happens to be different from the clientÆs
   realm.  Here are the steps in obtaining the ticket for the DHCP
   server (based on [6] and [7]):

        1) The client sends AS Request with NULL realm to the proxy.
        2) The proxy fills in the realm and forwards the AS Request to
           the KDC in the clientÆs realm.
        3) The KDC issues a TGT and sends back an AS Reply to the
           proxy.
        4) The proxy forwards AS Reply to the client.


S. Medvinsky, P. Lalwaney                                          -5-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000


        5) The client sends TGS Request for a principal name "dhcpsrvr"
           with NULL realm to the proxy.
        6) The proxy returns KRB_AP_ERR_REALM_REQUIRED error with the
           DHCP serverÆs realm to the client.
        7) The client sends another TGS Request for a cross-realm TGT
           to the proxy.
        8) The proxy forwards the TGS Request to the KDC in the
           clientÆs realm.
        9) The KDC issues a cross-realm TGT and sends back a TGS Reply
           to the proxy.
       10) The proxy forwards TGS Reply to the client.
       11) The client sends a TGS Request to the proxy for a principal
       "dhcpsrvr" with the realm name filled in, using a cross-realm
       TGT.
       12) The proxy forwards TGS Request to the KDC in the DHCP      
       server's realm.
       13) The KDC issues a ticket for the DHCP server and sends TGS
       Reply back to the proxy.
       14) The proxy forwards TGS Reply to the client.

   In a most general case, the client may need to contact any number of
   KDCs in different realms before it can get a ticket for the DHCP
   server.  In each case, the client would contact a KDC via the proxy
   server, as specified in Section 5 of this document.

4.2 Public Key Authentication

   This specification also allows clients to perform public key
   authentication to the KDC, based on the PKINIT specification [8].
   In this case, the size of an AS Request and AS Reply messages is
   likely to exceed the size of typical link MTU's.

   Here is an example, where PKINIT is used by a DHCP client that is
   not a registered principal in the KDC principal database:

        1) The client sends AS Request with a PKINIT Request pre-
           authenticator to the proxy.  This includes the clientÆs
           signature and X.509 certificate.  The KDC realm field is
           left as NULL.
        2) The proxy fills in the realm and forwards the AS Request to
           the KDC in the filled in realm.  This is the realm of the
           DHCP server.  Here, the clientÆs realm is the name of a
           Certification Authority - not the same as the KDC realm.
        3) The KDC issues a TGT and sends back an AS Reply with a
           PKINIT Reply pre-authenticator to the proxy.
        4) The proxy forwards the AS Reply to the client.
        5) The client sends TGS Request for a principal name "dhcpsrvr"
           with the realm found in the TGT to the proxy.
        6) The proxy forwards TGS Request to the KDC in the DHCP
           serverÆs realm.
        7) The KDC issues a ticket for the DHCP server and sends TGS
           Reply back to the proxy.

S. Medvinsky, P. Lalwaney                                          -6-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000


        8) The proxy forwards TGS Reply to the client.


   5. Key Management Exchange that Precedes Network Address Allocation

   An uninitialized host (e.g. on power-on and reset) does not have a
   network address. It does have a link layer address or hardware
   address. At this time, the client may not have any information on
   its realm or the realm of the address allocation server (DHCP
   Server).

   In the Kerberos key management exchange, a client gets its ticket
   granting ticket (TGT) by contacting the Authentication Server in the
   KDC using the AS_Request / Reply messages (shown as messages 1 and 2
   in Figure 1). The client then contacts the Ticket Granting Server in
   the KDC to get the DHCP server ticket (to be used for mutual
   authentication with the DHCP server) using the TGS_REQ / TGS_REP
   messages (shown as messages 3 and 4 in the above figure).  It is
   also possible for the client to obtain a DHCP server ticket directly
   with the AS Request / Reply exchange, without the use of the TGT.

   In the use of Kerberos for DHCP authentication, the client (a) does
   not have an IP/network address (b) does not know he KDCÆs IP address
   (c) the KDC may not be on the local network and (d) the client may
   not know the DHCP ServerÆs IP address and realm.  We therefore
   require a Kerberos proxy on the local network to accept broadcast
   Kerberos request messages (AS_REQ and TGS_REQ) from uninitialized
   clients and relay them to the appropriate KDC.

   The uninitialized client formulates a broadcast AS_REQ or TGS_REQ as
   follows:

   The request payload contains the client hardware address in
   addresses field with a negative value for the address type. Kerberos
   v5 [6] allows for the usage of negative address types for "local"
   use. Note that IAKERB [7] discourages the use of the addresses field
   as network addresses may not be known or may change in situation
   where proxies are used. In this draft we incorporate the negative
   values permitted in the Kerberos transport in the address type field
   of both the AS_REQ and TGS_REQ messages. The negative value SHOULD
   be the negative number of the hardware address type "htype" value
   (from assigned numbers RFC) used in RFC 2131. The address field of
   the message contains the clients hardware address.

   The request payload is UDP encapsulated and addressed to port 88 on
   the server/proxy. The UDP source port is selected by the client. The
   source and destination network addresses are the all-zeroÆs address
   and the broadcast address, respectively. For IPv4, the source IP
   address is set to 0.0.0.0 and the destination IP address is set to
   255.255.255.255. The data link layer header source address
   corresponds to the link layer/hardware address of the client. The


S. Medvinsky, P. Lalwaney                                          -7-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000


   destination link layer address is the broadcast address at the link
   layer (e.g. for Ethernet the address is ffffffff).

   In the case where AS_REQ message contains a PKINIT pre-authenticator
   for public key-based client authentication (based on [8]), the
   message will probably not fit into a single UDP packet given typical
   link MTU's.

   It is assumed that the proxy server on a network is configured with
   a list of KDCÆs, their realms and their IP addresses. The proxy
   server will act as a client to the KDC and forward standard Kerberos
   messages to/from the KDC using unicast UDP or TCP transport
   mechanisms, according to [6].

   Upon receiving a broadcast request from a client, the proxy MUST
   record the clientÆs hardware address that appears as the source
   address on the frame as well as in the addresses field of the
   request message. Based on the realm of the KDC specified in the
   request, the proxy determines the KDC to which this message is
   relayed as a unicast message from the proxy to the KDC.  In the case
   that the client left the KDC realm name as NULL, it is up to the
   proxy to first determine the correct realm name and fill it in the
   request (according to [7]).

   On receiving a request, the KDC formulates a response (AS_REP or
   TGS_REP). It includes the clientÆs addresses field in the encrypted
   part of the ticket (according to [6]). This response is unicast to
   the proxy.

   Upon receiving the reply, the proxy MUST first determine the
   previously saved hardware address of the client.  The proxy
   broadcasts the reply on its local network. This is a network layer
   broadcast. At the link level, it uses the hardware address obtained
   from the addresses field of the request.

   The client on receiving the response (link layer destination address
   as its hardware address, network layer address is the broadcast
   address) must verify that the hardware address in the ticket
   corresponds to its link layer address.

   Upon receiving a TGS_REP (or an AS_REP with the application server
   ticket) from the proxy, the client will have enough information to
   securely communicate with the application server (the DHCP Server in
   this case), as specified in the following section.









S. Medvinsky, P. Lalwaney                                          -8-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000


    6. Authenticated Message Exchange Between the DHCP Client and the
   DHCP Server

   The ticket returned in the TGS response is used by the DHCP client
   in the construction of the Kerberos authenticator.  The Kerberos
   ticket serves two purposes: to establish a shared session key with
   the DHCP server, and is also included as part of a Kerberos
   authenticator in the DHCP request.

   If the size of the authenticator is greater than 255 bytes, the DHCP
   authentication option is repeated multiple times.  When the values
   of all the authentication options are concatenated together, they
   will make up the complete authenticator.

   Once the session key is established, the Kerberos structure
   containing the ticket (AP REQ) can be omitted from the authenticator
   for subsequent messages sent by both the DHCP client and the DHCP
   server.

   The Kerberos authenticator for a DHCP request message is specified
   below:

   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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +              Replay Detection (64 bits)                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +              Authentication token (n octets)           ...    +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of this authenticator is in accordance with [2]. The code
   for the authentication option is TBD, and the length field contains
   the length of the remainder of the option, starting with the
   protocol field.

   The value of the protocol field for this authenticator MUST be set
   to 2.

   The algorithm field MUST take one of the following values:
        1 - HMAC-MD5
        2 - HMAC-SHA-1

   Replay protection field is a monotonically increasing counter field.
   When the Kerberos AP REQ structure is present in the authenticator
   the counter may be set to any value.  The AP REQ contains its own
   replay protection mechanism in the form of a timestamp.

S. Medvinsky, P. Lalwaney                                          -9-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000



   Once the session key has been established and the AP REQ is not
   included in the authenticator, this field MUST be monotonically
   increasing in the messages sent by the client.

   Kerberos authenticator token consists of type-length-value
   attributes:

   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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following attributes are included in the Kerberos authenticator
   token:

   Type         Attribute Name          Value
   --------------------------------------------------------------------
   0            Message Integrity Code  Depends on the value of the
                                        algorithm field.  Its length is
                                        16 bytes for HMAC-MD5 [9, 10]
                                        and 20 bytes for HMAC-SHA-1
                                        [11, 10].  The HMAC key must be
                                        derived from Kerberos session
                                        key found in the Kerberos
                                        ticket according to the key
                                        derivation rules in [6]:

                                          HMAC Key = DK(sess key,
                                                      key usage | 0x99)

                                        Here, DK is defined in [12] and
                                        the key usage value for DHCP is
                                        TBD.

                                        The HMAC is calculated over the
                                        entire DHCP message. The
                                        Message Integrity Code
                                        attribute MUST be set to all 0s
                                        for the computation of the
                                        HMAC.  Because a DHCP relay
                                        agent may alter the values of
                                        the 'giaddr' and 'hops' fields
                                        in the DHCP message, the
                                        contents of those two fields
                                        MUST also be set to zero for
                                        the computation of the HMAC.
                                        Rules specified in Section 3 of
                                        [2] for the exclusion and

S. Medvinsky, P. Lalwaney                                         -10-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000


                                        processing of the relay agent
                                        information are applicable here
                                        too.

                                        This field MUST always be
                                        present in the Kerberos
                                        authenticator.

   1            AP_REQ                  ASN.1 encoding of a Kerberos
                                        AP_REQ message, as specified
                                        in [6]. This MUST be included
                                        by the client when establishing
                                        a new session key.  In all
                                        other cases, this attribute
                                        MUST be omitted.

   AP_REQ contains the Kerberos ticket for the DHCP server and also
   contains information needed by the DHCP server to authenticate the
   client.  After verifying the AP_REQ and decrypting the Kerberos
   ticket, the DHCP server is able to extract a session key which it
   now shares with the DHCP client.

   The Kerberos authenticator token contains its own replay protection
   mechanism inside the AP_REQ structure.  The AP_REQ contains a
   timestamp that must be within an agreed upon time window at the DHCP
   server.  However, this does not require the DHCP clients to maintain
   an accurate clock between reboots.  Kerberos allows clients to
   synchronize their clock with the KDC with the help of Kerberos
   KRB_AP_ERR_SKEW error message, as specified in [6].

   The DHCP server MUST save both the session key and its associated
   expiration time found in the Kerberos ticket.  Up until the
   expiration time, the server must accept client requests with the
   Kerberos authenticator that does not include the AP REQ, using the
   saved session key in calculating HMAC values.

   The Kerberos authenticator inside all DHCP server responses MUST NOT
   contain the AP REQ and MUST use the saved Kerberos session key in
   calculating HMAC values.

   When the session key expires, it is the client's responsibility to
   obtain a new ticket from the KDC and to include an AP REQ inside the
   Kerberos authenticator for the next DHCP request message.










S. Medvinsky, P. Lalwaney                                         -11-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000


7. Detailed message flows for Kerberos and DHCP message Exchanges

   The following flow depicts the Kerberos exchange in which a AS REQ
   message is used to directly request the DHCP Server ticket. There
   are no changes to transport mechanisms below when the additional
   phase of using TGS requests/responses with TGTÆs is used.

   Client                         IAKERB Proxy                 KDC

   KB-client-------- AS_REQ ------>

   AS REQ Address type = - (htype)
   AS REQ Address= hw address

   src UDP port = senders port
   destination UDP port = 88

   src IP = 0.0.0.0
   destination IP = 255.255.255.255

   src link layer address =
   clientÆs HW/link address [e.g Ethernet address]

   destination link layer address =
   link broadcast address [e.g. ffffffff for Ethernet]


                                         --------------------------->
                                            (unicast to UDP port 88)



                                          <--------------------------
                                             (unicast AS REP)
                                         Encrypted portion of ticket
                                         Includes clients HW address


      <---------------AS_REP -----------


     Ticket includes clientÆs hardware address

     src UDP port = 88
     destination UDP port = copied from src port in AS_REQ

     src IP = ProxyÆs IP address
     destination IP = 255.255.255.255

     src link layer address = ProxyÆs HW/link address
     destination link layer address =
         ClientÆs link layer address from AS_REQ


S. Medvinsky, P. Lalwaney                                         -12-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000





    The client uses the ticket received from the KDC in the DHCP
Authentication option as described in Section 6.


     Client
     DHCP-client                                   DHCP Server

             ------DHCPDISCOVER ---->
             (Auth Protocol = 2, includes Kerberos
              authenticator with AP REQ )
                                   -----------------------------------
                                   |  HMAC  |     AP   REQ           |
                                    ----------------------------------
                                            | Ticket| Client Authent |
                                            --------------------------

                                         1. Server decrypts ticket
                                         (inside AP REQ) with service
                                         key
                                         2. Server decrypts client
                                         authenticator (inside AP REQ)
                                         and checks content and
                                         checksum to validate the
                                         client.
                                         3. Recompute HMAC with session
                                         key and compare.


          <-------DHCPOFFER----------
          (Auth Protocol = 2, no AP REQ )



         ---------DHCPREQUEST------->
         (Auth Protocol = 2, no AP REQ)


          <--------DHCPACK-------------
           (Auth Protocol = 2, no AP REQ )




8. Security Considerations

   DHCP clients that do not know the DHCP serverÆs realm name will get
   it from the proxy, as specified in IAKERB [7].  Since the proxy is
   not authenticated, a DHCP client can be fooled into obtaining a
   ticket for the wrong DHCP server in the wrong realm.

S. Medvinsky, P. Lalwaney                                         -13-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000



   This could happen when the client leaves out the server realm name
   in a TGS Request message to the proxy.  It is also possible,
   however, for a client to directly request a DHCP server ticket with
   an AS Request message.  In those cases, the same situation occurs
   when the client leaves out the realm name in an AS Request.

   This wrong DHCP server is still registered as a valid principal in a
   database of a KDC that can be trusted by the client.  In some
   circumstances a client may assume that a DHCP server that is a
   Kerberos principal registered with a trusted KDC will not attempt to
   deliberately misconfigure a client.

   This specification provides a tradeoff between:

        1) The DHCP clients knowing DHCP serverÆs realm ahead of time,
           which provides for full 2-way authentication at the cost of
           an additional configuration parameter.
        2) The DHCP clients not requiring any additional configuration
           information, besides a password or a key (and a public key
           certificate if PKINIT is used).  This is at the cost of not
           being able to fully authenticate the identity of the DHCP
           server.



9. References


   [1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol",
      RFC 2131, Bucknell University, March 1997.

   [2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
      draft-ietf-dhc-authentication-13.txt, June 2000.

   [3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V",
      draft-hornstein-dhc-kerbauth-02.txt, February 2000.

   [4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm
      Specific IP: Protocol Specification ", draft-ietf-nat-rsip-
      protocol-06.txt, March 2000.

   [5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service
      Location Protocol, Version 2", RFC 2608, June 1999.

   [6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
      05.txt, March 2000.





S. Medvinsky, P. Lalwaney                                         -14-        

Kerberos V Authentication Mode for Uninitialized Clients     July 2000



   [7]Swift, M., Trostle, J., "Initial Authentication and Pass Through
      Authentication Using Kerberos V5 and the GSS-API (IAKERB)",
      draft-ietf-cat-iakerb-03.txt, September 1999.

   [8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
      J. Trostle, "Public Key Cryptography for Initial Authentication
      in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000.

   [9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
      1992.

   [10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
      Message Authentication," RFC 2104, February 1997.

   [11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.

   [12]Horowitz, M., "Key Derivation for Authentication, Integrity, and
      Privacy", draft-horowitz-key-derivation-02.txt, August 1998.

   [13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC
   2026.



 10. Author's Addresses

   Sasha Medvinsky
   Motorola
   6450 Sequence Drive
   San Diego, CA 92121
   Email: smedvinsky@gi.com

   Poornima Lalwaney
   Nokia
   12278 Scripps Summit Drive
   San Diego, CA  92131
   Email: poornima.lalwaney@nokia.com


11. Expiration

   This memo is filed as <draft-smedvinsky-dhc-kerbauth-01.txt>, and
   expires January 1, 2001.



12. Intellectual Property Notices






S. Medvinsky, P. Lalwaney                                         -15-        

Kerberos V Authentication Mode for Uninitialized Clients    March 2000


      This section contains two notices as required by [13] for
   standards track documents.  Per [13], section 10.4(A):

     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 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 implementers or users of this specification
   can be obtained from the IETF Secretariat.

      Per [13] section 10.4(D):

      The IETF has been notified of intellectual property rights
   claimed in regard to some or all of the specification contained in
   this document.  For more information consult the online list of
   claimed rights.

   13. Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.  The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its successors or
   assigns. This document and the information contained herein is
   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





S. Medvinsky, P. Lalwaney                                         -16-