diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt | 1594 |
1 files changed, 0 insertions, 1594 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt b/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt deleted file mode 100644 index 89e6452..0000000 --- a/crypto/heimdal/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt +++ /dev/null @@ -1,1594 +0,0 @@ - -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] - - |
