diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt | 378 |
1 files changed, 378 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt new file mode 100644 index 00000000000..6581dd5810a --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt @@ -0,0 +1,378 @@ +INTERNET-DRAFT Ari Medvinsky +draft-ietf-cat-kerberos-pk-tapp-03.txt Keen.com, Inc. +Expires January 14, 2001 Matthew Hur +Informational CyberSafe Corporation + Sasha Medvinsky + Motorola + Clifford Neuman + USC/ISI + +Public Key Utilizing Tickets for Application Servers (PKTAPP) + + +0. Status Of this Memo + +This document is an Internet-Draft and is in full conformance with +all provisions of Section 10 of RFC 2026. 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. + +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.ietf.org (US East Coast), +nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or +munnari.oz.au (Pacific Rim). + +The distribution of this memo is unlimited. It is filed as +draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30, +2000. Please send comments to the authors. + +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). + +It is critical, however, that both read and write access to this ticket +policy is restricted with strong authentication and encryption to only +the correct application server. An unauthorized party should not have +the authority to modify the ticket policy. Disclosing the ticket policy +to a 3rd party may aid an adversary in determining the best way to +compromise the network. + +It is just as critical for the application server to authenticate the +directory service. Otherwise an adversary could use a man-in-the-middle +attack to substitute a false ticket policy with a false directory +service. + +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 both encrypted with a password- +derived symmetric key and also secured by an operating system. This +symmetric key may be stashed somewhere on the machine for convenience, +although such practice potentially weakens the overall system security +and is strongly discouraged. + +For added security, it is recommended that the LTGS private keys are +stored inside a temper-resistant hardware module that requires a pin +code for access. + + +5.1.2.4. 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. Security Considerations + +PKTAPP is based on the PKINIT protocol and all security considerations +already listed in [2] apply here. + +When the LTGS is implemented as part of each application server, the +secure storage of its public key credentials and of its ticket policy +are both a concern. The respective security considerations are already +covered in sections 5.1.2.3 and 5.1.2.2 of this document. + + +9. Bibliography + +[1] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using +Public Key Cryptography. Symposium On Network and Distributed System +Security, 1997. + +[2] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, +J. Trostle. Public Key Cryptography for Initial Authentication in +Kerberos. Internet Draft, October 1999. +(ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-10.txt) + +[3] C. Neuman, Proxy-Based Authorization and Accounting for +Distributed Systems. In Proceedings of the 13th International +Conference on Distributed Computing Systems, May 1993. + +[4] J. Kohl, C. Neuman. The Kerberos Network Authentication Service +(V5). Request for Comments 1510. + +10. Expiration Date + +This draft expires April 24, 2000. + +11. Authors + +Ari Medvinsky +Keen.com, Inc. +150 Independence Dr. +Menlo Park, CA 94025 +Phone +1 650 289 3134 +E-mail: ari@keen.com + +Matthew Hur +CyberSafe Corporation +1605 NW Sammamish Road +Issaquah, WA 98027-5378 +Phone: +1 425 391 6000 +E-mail: matt.hur@cybersafe.com + +Alexander Medvinsky +Motorola +6450 Sequence Dr. +San Diego, CA 92121 +Phone: +1 858 404 2367 +E-mail: smedvinsky@gi.com + +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 |