--- /dev/null
+
+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]
+
+
git.samba.org / samba.git / blobdiff