DHC Working Group Ken Hornstein INTERNET-DRAFT NRL Category: Standards Track Ted Lemon 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 , and expires October 1, 2000. Hornstein, et al. Standards Track [Page 28]