DHC Working Group S. Medvinsky Internet Draft Motorola Document: Category: Standards Track P.Lalwaney Expires: January 2001 Nokia July 2000 Kerberos V Authentication Mode for Uninitialized Clients Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as , and expires January 2001. Please send comments to the authors. 1. Abstract The Dynamic Host Configuration Protocol (DHCP) [1] includes an option that allows authentication of all DHCP messages, as specified in [2]. This document specifies a DHCP authentication mode based on Kerberos V tickets. This provides mutual authentication between a DHCP client and server, as well as authentication of all DHCP messages. This document specifies Kerberos message exchanges between an uninitialized client and the KDC (Key Distribution Center) using an IAKERB proxy [7] so that the Kerberos key management phase is decoupled from, and precedes the address allocation and network configuration phase that uses the DHCP authentication option. In order to make use of the IAKERB proxy, this document specifies a transport mechanism that works with an uninitialized client (i.e. a Kerberos V Authentication Mode for Uninitialized Clients July 2000 client without an assigned IP address). In addition, the document specifies the format of the Kerberos authenticator to be used with the DHCP authentication option. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3. Introduction 3.1 Terminology o "DHCP client" A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address. o "DHCP server" A DHCP server is an Internet host that returns configuration parameters to DHCP clients. O "Ticket" A Kerberos term for a record that helps a client authenticate itself to a server; it contains the client's identity, a session key, a timestamp, and other information, all sealed using the server's secret key. It only serves to authenticate a client when presented along with a fresh Authenticator. o "Key Distribution Center" Key Distribution Center, a network service that supplies tickets and temporary session keys; or an instance of that service or the host on which it runs. The KDC services both initial ticket and Ticket- Granting Ticket (TGT) requests. The initial ticket portion is sometimes referred to as the Authentication Server (or service. The Ticket-Granting Ticket portion is sometimes referred to as the Ticket-Granting Server (or service). o "Realm" A Kerberos administrative domain that represents a group of principals registered at a KDC. A single KDC may be responsible for one or more realms. A fully qualified principal name includes a realm name along with a principal name unique within that realm. 3.2 Protocol Overview S. Medvinsky, P. Lalwaney -2- Kerberos V Authentication Mode for Uninitialized Clients July 2000 DHCP as defined in [1] defines the protocol exchanges for a client to obtain its IP address and network configuration information from a DHCP Server. Kerberos V5 as described in [6] defines the protocol and message exchanges to mutually authenticate two parties. It is our goal to provide authentication support for DHCP using Kerberos. This implies that the Kerberos key management exchange has to take place before a client gets its IP address from the DHCP Server. Kerberos assumes that the client has a network address and can contact the Key Distribution Center to obtain its credentials for authenticated communication with an application server. In this specification we utilize the key exchange using an IAKERB proxy described in [7]. This does not require any changes to either the IAKERB or the Kerberos V5 specification. This document also specifies a particular transport that allows an uninitialized client to contact an IAKERB proxy. The Kerberos ticket returned from the key management exchange discussed in Section 5 of this document is passed to the DHCP Server inside the DHCP authentication option with the new Kerberos authenticator type. This is described in Section 6 of this draft. 3.3 Related Work A prior Internet Draft [3] outlined the use of Kerberos-based authentication for DHCP. The proposal tightly coupled the Kerberos client state machines and the DHCP client state machines. As a result, the Kerberos key management messages were carried in DHCP messages, along with the Kerberos authenticators. In addition, the first DHCP message exchange (request, offer) is not authenticated. We propose a protocol exchange where Kerberos key management is decoupled from and precedes authenticated DHCP exchanges. This implies that the Kerberos ticket returned in the initial key management exchange could be used to authenticate servers assigning addresses by non-DHCP address assignment mechanisms like RSIP [4] and for service specific parameter provisioning mechanisms using SLP [5]. S. Medvinsky, P. Lalwaney -3- Kerberos V Authentication Mode for Uninitialized Clients July 2000 4. System Architecture Client -------- -------- | | 5.Authenticated DHCP | | | DHCP |<------------------------>| DHCP | | client | | server | | | | | | | | | |Kerberos| | | | Client | | | -------- -------- ^ | | | | ------- ------------------------------>| | Kerberos Key Mgmt | Proxy | messages: | | 1. AS Request / 2.AS Reply ------- 3. TGS Request / 4.TGS Reply ^ | Kerberos | Key Mgmt messages v (1, 2, 3, 4) -------- | | | KDC | | | -------- Figure 1: System blocks and message interactions between them In this architecture, the DHCP client obtains a Kerberos ticket from the Key Distribution Center (KDC) using standard Kerberos messages, as specified in [6]. The client, however, contacts the KDC via a proxy server, according to the IAKERB mechanism, described in [7]. The are several reasons why a client has to go through this proxy in order to contact the KDC: a)The client may not know the host address of the KDC and may be sending its first request message as a broadcast on a local network. The KDC may not be located on the local network, and even if it were - it will be unable to communicate with a client without an IP address. This document describes a specific mechanism that may be used by a client to communicate with the Kerberos proxy. S. Medvinsky, P. Lalwaney -4- Kerberos V Authentication Mode for Uninitialized Clients July 2000 b)The client may not know its Kerberos realm name. The proxy is able to fill in the missing client realm name in an AS Request message, as specified in IAKERB. Note that in the case that PKINIT pre-authenticator is used [8], the realm name in the AS Request may be the KDC realm name and not the clientÆs realm name. c) The client does not know the realm name of the DHCP server. According to IAKERB, when the client sends a TGS Request with a missing server realm name, the proxy will return to the client an error message containing the missing realm name. Note that in this case the proxy could return the client a wrong realm name and the client could be fooled into obtaining a ticket for the wrong DHCP server (on the same local network). However, the wrong DHCP server must still be a registered principal in a KDC database. In some circumstances this may be an acceptable compromise. Also, see the security considerations section. IAKERB describes the proxy as part of an application server - the DHCP server in this case. However, in this document we are not requiring the proxy to be integrated with the DHCP server. The same IAKERB mechanisms apply in the more general case, where the proxy is an independent application. This proxy, however, MUST be reachable by a client via a local network broadcast. After a client has obtained a Kerberos ticket for the DHCP server, it will use it as part of an authentication option in the DHCP messages. The only extension to the DHCP protocol is the addition of a new authenticator type based on Kerberos tickets. 4.1 Cross-Realm Authentication Figure 1 shows a client communicating with a single KDC via a proxy. However, the DHCP clientÆs realm may be different from the DHCP serverÆs realm. In that case, the client may need to first contact the KDC in its local realm to obtain a cross-realm TGT. Then, the client would use the cross-realm TGT to contact the KDC in the DHCP serverÆs realm, as specified in [6]. In the following example a client doesnÆt know its realm or the DHCP serverÆs realm, which happens to be different from the clientÆs realm. Here are the steps in obtaining the ticket for the DHCP server (based on [6] and [7]): 1) The client sends AS Request with NULL realm to the proxy. 2) The proxy fills in the realm and forwards the AS Request to the KDC in the clientÆs realm. 3) The KDC issues a TGT and sends back an AS Reply to the proxy. 4) The proxy forwards AS Reply to the client. S. Medvinsky, P. Lalwaney -5- Kerberos V Authentication Mode for Uninitialized Clients July 2000 5) The client sends TGS Request for a principal name "dhcpsrvr" with NULL realm to the proxy. 6) The proxy returns KRB_AP_ERR_REALM_REQUIRED error with the DHCP serverÆs realm to the client. 7) The client sends another TGS Request for a cross-realm TGT to the proxy. 8) The proxy forwards the TGS Request to the KDC in the clientÆs realm. 9) The KDC issues a cross-realm TGT and sends back a TGS Reply to the proxy. 10) The proxy forwards TGS Reply to the client. 11) The client sends a TGS Request to the proxy for a principal "dhcpsrvr" with the realm name filled in, using a cross-realm TGT. 12) The proxy forwards TGS Request to the KDC in the DHCP server's realm. 13) The KDC issues a ticket for the DHCP server and sends TGS Reply back to the proxy. 14) The proxy forwards TGS Reply to the client. In a most general case, the client may need to contact any number of KDCs in different realms before it can get a ticket for the DHCP server. In each case, the client would contact a KDC via the proxy server, as specified in Section 5 of this document. 4.2 Public Key Authentication This specification also allows clients to perform public key authentication to the KDC, based on the PKINIT specification [8]. In this case, the size of an AS Request and AS Reply messages is likely to exceed the size of typical link MTU's. Here is an example, where PKINIT is used by a DHCP client that is not a registered principal in the KDC principal database: 1) The client sends AS Request with a PKINIT Request pre- authenticator to the proxy. This includes the clientÆs signature and X.509 certificate. The KDC realm field is left as NULL. 2) The proxy fills in the realm and forwards the AS Request to the KDC in the filled in realm. This is the realm of the DHCP server. Here, the clientÆs realm is the name of a Certification Authority - not the same as the KDC realm. 3) The KDC issues a TGT and sends back an AS Reply with a PKINIT Reply pre-authenticator to the proxy. 4) The proxy forwards the AS Reply to the client. 5) The client sends TGS Request for a principal name "dhcpsrvr" with the realm found in the TGT to the proxy. 6) The proxy forwards TGS Request to the KDC in the DHCP serverÆs realm. 7) The KDC issues a ticket for the DHCP server and sends TGS Reply back to the proxy. S. Medvinsky, P. Lalwaney -6- Kerberos V Authentication Mode for Uninitialized Clients July 2000 8) The proxy forwards TGS Reply to the client. 5. Key Management Exchange that Precedes Network Address Allocation An uninitialized host (e.g. on power-on and reset) does not have a network address. It does have a link layer address or hardware address. At this time, the client may not have any information on its realm or the realm of the address allocation server (DHCP Server). In the Kerberos key management exchange, a client gets its ticket granting ticket (TGT) by contacting the Authentication Server in the KDC using the AS_Request / Reply messages (shown as messages 1 and 2 in Figure 1). The client then contacts the Ticket Granting Server in the KDC to get the DHCP server ticket (to be used for mutual authentication with the DHCP server) using the TGS_REQ / TGS_REP messages (shown as messages 3 and 4 in the above figure). It is also possible for the client to obtain a DHCP server ticket directly with the AS Request / Reply exchange, without the use of the TGT. In the use of Kerberos for DHCP authentication, the client (a) does not have an IP/network address (b) does not know he KDCÆs IP address (c) the KDC may not be on the local network and (d) the client may not know the DHCP ServerÆs IP address and realm. We therefore require a Kerberos proxy on the local network to accept broadcast Kerberos request messages (AS_REQ and TGS_REQ) from uninitialized clients and relay them to the appropriate KDC. The uninitialized client formulates a broadcast AS_REQ or TGS_REQ as follows: The request payload contains the client hardware address in addresses field with a negative value for the address type. Kerberos v5 [6] allows for the usage of negative address types for "local" use. Note that IAKERB [7] discourages the use of the addresses field as network addresses may not be known or may change in situation where proxies are used. In this draft we incorporate the negative values permitted in the Kerberos transport in the address type field of both the AS_REQ and TGS_REQ messages. The negative value SHOULD be the negative number of the hardware address type "htype" value (from assigned numbers RFC) used in RFC 2131. The address field of the message contains the clients hardware address. The request payload is UDP encapsulated and addressed to port 88 on the server/proxy. The UDP source port is selected by the client. The source and destination network addresses are the all-zeroÆs address and the broadcast address, respectively. For IPv4, the source IP address is set to 0.0.0.0 and the destination IP address is set to 255.255.255.255. The data link layer header source address corresponds to the link layer/hardware address of the client. The S. Medvinsky, P. Lalwaney -7- Kerberos V Authentication Mode for Uninitialized Clients July 2000 destination link layer address is the broadcast address at the link layer (e.g. for Ethernet the address is ffffffff). In the case where AS_REQ message contains a PKINIT pre-authenticator for public key-based client authentication (based on [8]), the message will probably not fit into a single UDP packet given typical link MTU's. It is assumed that the proxy server on a network is configured with a list of KDCÆs, their realms and their IP addresses. The proxy server will act as a client to the KDC and forward standard Kerberos messages to/from the KDC using unicast UDP or TCP transport mechanisms, according to [6]. Upon receiving a broadcast request from a client, the proxy MUST record the clientÆs hardware address that appears as the source address on the frame as well as in the addresses field of the request message. Based on the realm of the KDC specified in the request, the proxy determines the KDC to which this message is relayed as a unicast message from the proxy to the KDC. In the case that the client left the KDC realm name as NULL, it is up to the proxy to first determine the correct realm name and fill it in the request (according to [7]). On receiving a request, the KDC formulates a response (AS_REP or TGS_REP). It includes the clientÆs addresses field in the encrypted part of the ticket (according to [6]). This response is unicast to the proxy. Upon receiving the reply, the proxy MUST first determine the previously saved hardware address of the client. The proxy broadcasts the reply on its local network. This is a network layer broadcast. At the link level, it uses the hardware address obtained from the addresses field of the request. The client on receiving the response (link layer destination address as its hardware address, network layer address is the broadcast address) must verify that the hardware address in the ticket corresponds to its link layer address. Upon receiving a TGS_REP (or an AS_REP with the application server ticket) from the proxy, the client will have enough information to securely communicate with the application server (the DHCP Server in this case), as specified in the following section. S. Medvinsky, P. Lalwaney -8- Kerberos V Authentication Mode for Uninitialized Clients July 2000 6. Authenticated Message Exchange Between the DHCP Client and the DHCP Server The ticket returned in the TGS response is used by the DHCP client in the construction of the Kerberos authenticator. The Kerberos ticket serves two purposes: to establish a shared session key with the DHCP server, and is also included as part of a Kerberos authenticator in the DHCP request. If the size of the authenticator is greater than 255 bytes, the DHCP authentication option is repeated multiple times. When the values of all the authentication options are concatenated together, they will make up the complete authenticator. Once the session key is established, the Kerberos structure containing the ticket (AP REQ) can be omitted from the authenticator for subsequent messages sent by both the DHCP client and the DHCP server. The Kerberos authenticator for a DHCP request message is specified below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length | Protocol | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Replay Detection (64 bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication token (n octets) ... + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of this authenticator is in accordance with [2]. The code for the authentication option is TBD, and the length field contains the length of the remainder of the option, starting with the protocol field. The value of the protocol field for this authenticator MUST be set to 2. The algorithm field MUST take one of the following values: 1 - HMAC-MD5 2 - HMAC-SHA-1 Replay protection field is a monotonically increasing counter field. When the Kerberos AP REQ structure is present in the authenticator the counter may be set to any value. The AP REQ contains its own replay protection mechanism in the form of a timestamp. S. Medvinsky, P. Lalwaney -9- Kerberos V Authentication Mode for Uninitialized Clients July 2000 Once the session key has been established and the AP REQ is not included in the authenticator, this field MUST be monotonically increasing in the messages sent by the client. Kerberos authenticator token consists of type-length-value attributes: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | attribute value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following attributes are included in the Kerberos authenticator token: Type Attribute Name Value -------------------------------------------------------------------- 0 Message Integrity Code Depends on the value of the algorithm field. Its length is 16 bytes for HMAC-MD5 [9, 10] and 20 bytes for HMAC-SHA-1 [11, 10]. The HMAC key must be derived from Kerberos session key found in the Kerberos ticket according to the key derivation rules in [6]: HMAC Key = DK(sess key, key usage | 0x99) Here, DK is defined in [12] and the key usage value for DHCP is TBD. The HMAC is calculated over the entire DHCP message. The Message Integrity Code attribute MUST be set to all 0s for the computation of the HMAC. Because a DHCP relay agent may alter the values of the 'giaddr' and 'hops' fields in the DHCP message, the contents of those two fields MUST also be set to zero for the computation of the HMAC. Rules specified in Section 3 of [2] for the exclusion and S. Medvinsky, P. Lalwaney -10- Kerberos V Authentication Mode for Uninitialized Clients July 2000 processing of the relay agent information are applicable here too. This field MUST always be present in the Kerberos authenticator. 1 AP_REQ ASN.1 encoding of a Kerberos AP_REQ message, as specified in [6]. This MUST be included by the client when establishing a new session key. In all other cases, this attribute MUST be omitted. AP_REQ contains the Kerberos ticket for the DHCP server and also contains information needed by the DHCP server to authenticate the client. After verifying the AP_REQ and decrypting the Kerberos ticket, the DHCP server is able to extract a session key which it now shares with the DHCP client. The Kerberos authenticator token contains its own replay protection mechanism inside the AP_REQ structure. The AP_REQ contains a timestamp that must be within an agreed upon time window at the DHCP server. However, this does not require the DHCP clients to maintain an accurate clock between reboots. Kerberos allows clients to synchronize their clock with the KDC with the help of Kerberos KRB_AP_ERR_SKEW error message, as specified in [6]. The DHCP server MUST save both the session key and its associated expiration time found in the Kerberos ticket. Up until the expiration time, the server must accept client requests with the Kerberos authenticator that does not include the AP REQ, using the saved session key in calculating HMAC values. The Kerberos authenticator inside all DHCP server responses MUST NOT contain the AP REQ and MUST use the saved Kerberos session key in calculating HMAC values. When the session key expires, it is the client's responsibility to obtain a new ticket from the KDC and to include an AP REQ inside the Kerberos authenticator for the next DHCP request message. S. Medvinsky, P. Lalwaney -11- Kerberos V Authentication Mode for Uninitialized Clients July 2000 7. Detailed message flows for Kerberos and DHCP message Exchanges The following flow depicts the Kerberos exchange in which a AS REQ message is used to directly request the DHCP Server ticket. There are no changes to transport mechanisms below when the additional phase of using TGS requests/responses with TGTÆs is used. Client IAKERB Proxy KDC KB-client-------- AS_REQ ------> AS REQ Address type = - (htype) AS REQ Address= hw address src UDP port = senders port destination UDP port = 88 src IP = 0.0.0.0 destination IP = 255.255.255.255 src link layer address = clientÆs HW/link address [e.g Ethernet address] destination link layer address = link broadcast address [e.g. ffffffff for Ethernet] ---------------------------> (unicast to UDP port 88) <-------------------------- (unicast AS REP) Encrypted portion of ticket Includes clients HW address <---------------AS_REP ----------- Ticket includes clientÆs hardware address src UDP port = 88 destination UDP port = copied from src port in AS_REQ src IP = ProxyÆs IP address destination IP = 255.255.255.255 src link layer address = ProxyÆs HW/link address destination link layer address = ClientÆs link layer address from AS_REQ S. Medvinsky, P. Lalwaney -12- Kerberos V Authentication Mode for Uninitialized Clients July 2000 The client uses the ticket received from the KDC in the DHCP Authentication option as described in Section 6. Client DHCP-client DHCP Server ------DHCPDISCOVER ----> (Auth Protocol = 2, includes Kerberos authenticator with AP REQ ) ----------------------------------- | HMAC | AP REQ | ---------------------------------- | Ticket| Client Authent | -------------------------- 1. Server decrypts ticket (inside AP REQ) with service key 2. Server decrypts client authenticator (inside AP REQ) and checks content and checksum to validate the client. 3. Recompute HMAC with session key and compare. <-------DHCPOFFER---------- (Auth Protocol = 2, no AP REQ ) ---------DHCPREQUEST-------> (Auth Protocol = 2, no AP REQ) <--------DHCPACK------------- (Auth Protocol = 2, no AP REQ ) 8. Security Considerations DHCP clients that do not know the DHCP serverÆs realm name will get it from the proxy, as specified in IAKERB [7]. Since the proxy is not authenticated, a DHCP client can be fooled into obtaining a ticket for the wrong DHCP server in the wrong realm. S. Medvinsky, P. Lalwaney -13- Kerberos V Authentication Mode for Uninitialized Clients July 2000 This could happen when the client leaves out the server realm name in a TGS Request message to the proxy. It is also possible, however, for a client to directly request a DHCP server ticket with an AS Request message. In those cases, the same situation occurs when the client leaves out the realm name in an AS Request. This wrong DHCP server is still registered as a valid principal in a database of a KDC that can be trusted by the client. In some circumstances a client may assume that a DHCP server that is a Kerberos principal registered with a trusted KDC will not attempt to deliberately misconfigure a client. This specification provides a tradeoff between: 1) The DHCP clients knowing DHCP serverÆs realm ahead of time, which provides for full 2-way authentication at the cost of an additional configuration parameter. 2) The DHCP clients not requiring any additional configuration information, besides a password or a key (and a public key certificate if PKINIT is used). This is at the cost of not being able to fully authenticate the identity of the DHCP server. 9. References [1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages", draft-ietf-dhc-authentication-13.txt, June 2000. [3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V", draft-hornstein-dhc-kerbauth-02.txt, February 2000. [4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm Specific IP: Protocol Specification ", draft-ietf-nat-rsip- protocol-06.txt, March 2000. [5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service Location Protocol, Version 2", RFC 2608, June 1999. [6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- 05.txt, March 2000. S. Medvinsky, P. Lalwaney -14- Kerberos V Authentication Mode for Uninitialized Clients July 2000 [7]Swift, M., Trostle, J., "Initial Authentication and Pass Through Authentication Using Kerberos V5 and the GSS-API (IAKERB)", draft-ietf-cat-iakerb-03.txt, September 1999. [8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, J. Trostle, "Public Key Cryptography for Initial Authentication in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000. [9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC 2104, February 1997. [11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995. [12]Horowitz, M., "Key Derivation for Authentication, Integrity, and Privacy", draft-horowitz-key-derivation-02.txt, August 1998. [13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC 2026. 10. Author's Addresses Sasha Medvinsky Motorola 6450 Sequence Drive San Diego, CA 92121 Email: smedvinsky@gi.com Poornima Lalwaney Nokia 12278 Scripps Summit Drive San Diego, CA 92131 Email: poornima.lalwaney@nokia.com 11. Expiration This memo is filed as , and expires January 1, 2001. 12. Intellectual Property Notices S. Medvinsky, P. Lalwaney -15- Kerberos V Authentication Mode for Uninitialized Clients March 2000 This section contains two notices as required by [13] for standards track documents. Per [13], section 10.4(A): The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. Per [13] section 10.4(D): The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 13. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. S. Medvinsky, P. Lalwaney -16-