INTERNET-DRAFT Ari Medvinsky Common Authentication Technology Working Group Matthew Hur Alexander Medvinsky CyberSafe Corporation B. Clifford Neuman USC/ISI March 98 (Expires September, 98) Public Key Utilizing Tickets for Application Servers (PKTAPP) 0. Status Of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract Public key based Kerberos for Distributed Authentication[1], (PKDA) proposed by Sirbu & Chuang, describes PK based authentication that eliminates the use of a centralized key distribution center while retaining the advantages of Kerberos tickets. This draft describes how, without any modification, the PKINIT specification[2] may be used to implement the ideas introduced in PKDA. The benefit is that only a single PK Kerberos extension is needed to address the goals of PKINIT & PKDA. 2. Introduction With the proliferation of public key cryptography, a number of public key extensions to Kerberos have been proposed to provide interoperability with the PK infrastructure and to improve the Kerberos authentication system [4]. Among these are PKINIT[2] (under development in the CAT working group) and more recently PKDA [1] proposed by Sirbu & Chuang of CMU. One of the principal goals of PKINIT is to provide for interoperability between a PK infrastructure and Kerberos. Using PKINIT, a user can authenticate to the KDC via a public key certificate. A ticket granting ticket (TGT), returned by the KDC, enables a PK user to obtain tickets and authenticate to kerberized services. The PKDA proposal goes a step further. It supports direct client to server authentication, eliminating the need for an online key distribution center. In this draft, we describe how, without any modification, the PKINIT protocol may be applied to achieve the goals of PKDA. For direct client to server authentication, the client will use PKINIT to authenticate to the end server (instead of a central KDC), which then, will issue a ticket for itself. The benefit of this proposal, is that a single PK extension to Kerberos can addresses the goals of PKINIT and PKDA. 3. PKDA background The PKDA proposal provides direct client to server authentication, thus eliminating the need for an online key distribution center. A client and server take part in an initial PK based authentication exchange, with an added caveat that the server acts as a Kerberos ticket granting service and issues a traditional Kerberos ticket for itself. In subsequent communication, the client makes use of the Kerberos ticket, thus eliminating the need for public key operations on the server. This approach has an advantage over SSL in that the server does not need to save state (cache session keys). Furthermore, an additional benefit, is that Kerberos tickets can facilitate delegation (see Neuman[3]). Below is a brief overview of the PKDA protocol. For a more detailed description see [1]. SCERT_REQ: Client to Server The client requests a certificate from the server. If the server’s certificate is cached locally, SCERT_REQ and SCERT_REP are omitted. SCERT_REP: Server to Client The server returns its certificate to the client. PKTGS_REQ: Client to Server The client sends a request for a service ticket to the server. To authenticate the request, the client signs, among other fields, a time stamp and a newly generated symmetric key . The time stamp is used to foil replay attacks; the symmetric key is used by the server to secure the PKTGS_REP message. The client provides a certificate in the request (the certificate enables the server to verify the validity of the client’s signature) and seals it along with the signed information using the server’s public key. PKTGS_REP: Server to Client The server returns a service ticket (which it issued for itself) along with the session key for the ticket. The session key is protected by the client-generated key from the PKTGS_REQ message. AP_REQ: Client to Server After the above exchange, the client can proceed in a normal fashion, using the conventional Kerberos ticket in an AP_REQ message. 4. PKINIT background One of the principal goals of PKINIT is to provide for interoperability between a public key infrastructure and Kerberos. Using a public key certificate, a client can authenticate to the KDC and receive a TGT which enables the client to obtain service tickets to kerberized services.. In PKINIT, the AS-REQ and AS-REP messages remain the same; new preauthentication data types are used to conduct the PK exchange. Client and server certificates are exchanged via the preauthentication data. Thus, the exchange of certificates , PK authentication, and delivery of a TGT can occur in two messages. Below is a brief overview of the PKINIT protocol. For a more detailed description see [2]. PreAuthentication data of AS-REQ: Client to Server The client sends a list of trusted certifiers, a signed PK authenticator, and its certificate. The PK authenticator, based on the Kerberos authenticator, contains the name of the KDC, a timestamp, and a nonce. PreAuthentication data of AS-REP: Server to Client The server responds with its certificate and the key used for decrypting the encrypted part of the AS-REQ. This key is encrypted with the client’s public key. AP_REQ: Client to Server After the above exchange, the client can proceed in a normal fashion, using the conventional Kerberos ticket in an AP_REQ message. 5. Application of PKINIT to achieve equivalence to PKDA While PKINIT is normally used to retrieve a ticket granting ticket (TGT), it may also be used to request an end service ticket. When used in this fashion, PKINIT is functionally equivalent to PKDA. We introduce the concept of a local ticket granting server (LTGS) to illustrate how PKINIT may be used for issuing end service tickets based on public key authentication. It is important to note that the LTGS may be built into an application server, or it may be a stand-alone server used for issuing tickets within a well-defined realm, such as a single machine. We will discuss both of these options. 5.1. The LTGS The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT preauthentication data. When a client submits an AS-REQ to the LTGS, it specifies an application server, in order to receive an end service ticket instead of a TGT. 5.1.1. The LTGS as a standalone server The LTGS may run as a separate process that serves applications which reside on the same machine. This serves to consolidate administrative functions and provide an easier migration path for a heterogeneous environment consisting of both public key and Kerberos. The LTGS would use one well-known port (port #88 - same as the KDC) for all message traffic and would share a symmetric with each service. After the client receives a service ticket, it then contacts the application server directly. This approach is similar to the one suggested by Sirbu , et al [1]. 5.1.1.1. Ticket Policy for PKTAPP Clients It is desirable for the LTGS to have access to a PKTAPP client ticket policy. This policy will contain information for each client, such as the maximum lifetime of a ticket, whether or not a ticket can be forwardable, etc. PKTAPP clients, however, use the PKINIT protocol for authentication and are not required to be registered as Kerberos principals. As one possible solution, each public key Certification Authority could be registered in a secure database, along with the ticket policy information for all PKTAPP clients that are certified by this Certification Authority. 5.1.1.2. LTGS as a Kerberos Principal Since the LTGS serves only PKTAPP clients and returns only end service tickets for other services, it does not require a Kerberos service key or a Kerberos principal identity. It is therefore not necessary for the LTGS to even be registered as a Kerberos principal. The LTGS still requires public key credentials for the PKINIT exchange, and it may be desired to have some global restrictions on the Kerberos tickets that it can issue. It is recommended (but not required) that this information be associated with a Kerberos principal entry for the LTGS. 5.1.1.3. Kerberos Principal Database Since the LTGS issues tickets for Kerberos services, it will require access to a Kerberos principal database containing entries for at least the end services. Each entry must contain a service key and may also contain restrictions on the service tickets that are issued to clients. It is recommended that (for ease of administration) this principal database be centrally administered and distributed (replicated) to all hosts where an LTGS may be running. In the case that there are other clients that do not support PKINIT protocol, but still need access to the same Kerberos services, this principal database will also require entries for Kerberos clients and for the TGS entries. 5.1.2. The LTGS as part of an application server The LTGS may be combined with an application server. This accomplishes direct client to application server authentication; however, it requires that applications be modified to process AS-REQ and AS-REP messages. The LTGS would communicate over the port assigned to the application server or over the well known Kerberos port for that particular application. 5.1.2.2. Ticket Policy for PKTAPP Clients Application servers normally do not have access to a distributed principal database. Therefore, they will have to find another means of keeping track of the ticket policy information for PKTAPP clients. It is recommended that this ticket policy be kept in a directory service (such as LDAP). 5.1.2.3. LTGS Credentials Each LTGS (combined with an application service) will require public key credentials in order to use the PKINIT protocol. These credentials can be stored in a single file that is secured by an operating system and possibly encrypted with a password-derived symmetric key (which may be stashed somewhere on the machine for convenience). For added security, the LTGS private keys can be stored inside a temper-resistant hardware module. 5.1.2.1. Compatibility With Standard Kerberos Even though an application server is combined with the LTGS, for backward compatibility it should still accept service tickets that have been issued by the KDC. This will allow Kerberos clients that do not support PKTAPP to authenticate to the same application server (with the help of a KDC). 5.1.3. Cross-Realm Authentication According to the PKINIT draft, the client's realm is the X.500 name of the Certification Authority that issued the client certificate. A Kerberos application service will be in a standard Kerberos realm, which implies that the LTGS will need to issue cross-realm end service tickets. This is the only case, where cross-realm end service tickets are issued. In a standard Kerberos model, a client first acquires a cross-realm TGT, and then gets an end service ticket from the KDC that is in the same realm as the application service. 6. Protocol differences between PKINIT and PKDA Both PKINIT and PKDA will accomplish the same goal of issuing end service tickets, based on initial public key authentication. A PKINIT- based implementation and a PKDA implementation would be functionally equivalent. The primary differences are that 1)PKDA requires the client to create the symmetric key while PKINIT requires the server to create the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes in four messages. 7. Summary The PKINIT protocol can be used, without modification to facilitate client to server authentication without the use of a central KDC. The approach described in this draft (and originally proposed in PKDA[1]) is essentially a public key authentication protocol that retains the advantages of Kerberos tickets. Given that PKINIT has progressed through the CAT working group of the IETF, with plans for non-commercial distribution (via MIT’s v5 Kerberos) as well as commercial support, it is worthwhile to provide PKDA functionality, under the PKINIT umbrella. 8. Bibliography [1] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using Public Key Cryptography. Symposium On Network and Distributed System Security, 1997 [2] B.C. Neuman, B. Tung, J. Wray, . Trostle. Public Key Cryptography for Initial Authentication in Kerberos. Internet Draft, November 1997. (ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-05.txt) [3] B.C. Neuman, Proxy-Based Authorization and Accounting for Distributed Systems. In Proceedings of the 13th International Conference on Distributed Computing Systems, May 1993 [4] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service for Computer Networks, IEEE Communications, 32(9):33-38. September 1994. Authors' Addresses Ari Medvinsky Matthew Hur Alexander Medvinsky CyberSafe Corporation 1605 NW Sammamish Road Suite 310 Issaquah, WA 98027-5378 Phone: (206) 391-6000 Fax: (206) 391-0508 http:/www.cybersafe.com B. Clifford Neuman USC Information Sciences Institute 4676 Admiralty Way Suite 1001 Marina del Rey CA 90292-6695 Phone: +1 310 822 1511 E-mail: bcn@isi.edu