INTERNET-DRAFT Brian Tung draft-ietf-cat-kerberos-pk-cross-01.txt Tatyana Ryutov Updates: RFC 1510 Clifford Neuman expires September 30, 1997 Gene Tsudik ISI Bill Sommerfeld Hewlett-Packard Ari Medvinsky Matthew Hur CyberSafe Corporation Public Key Cryptography for Cross-Realm Authentication in Kerberos 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 ds.internic.net (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-cross-01.txt, and expires September 30, 1997. Please send comments to the authors. 1. Abstract This document defines extensions to the Kerberos protocol specification (RFC 1510, "The Kerberos Network Authentication Service (V5)", September 1993) to provide a method for using public key cryptography during cross-realm authentication. The methods defined here specify the way in which message exchanges are to be used to transport cross-realm secret keys protected by encryption under public keys certified as belonging to KDCs. 2. Motivation The advantages provided by public key cryptography--ease of recoverability in the event of a compromise, the possibility of an autonomous authentication infrastructure, to name a few--have produced a demand for use by Kerberos authentication protocol. A draft describing the use of public key cryptography in the initial authentication exchange in Kerberos has already been submitted. This draft describes its use in cross-realm authentication. The principal advantage provided by public key cryptography in cross-realm authentication lies in the ability to leverage the existing public key infrastructure. It frees the Kerberos realm administrator from having to maintain separate keys for each other realm with which it wishes to exchange authentication information, or to utilize a hierarchical arrangement, which may pose problems of trust. Even with the multi-hop cross-realm authentication, there must be some way to locate the path by which separate realms are to be transited. The current method, which makes use of the DNS-like realm names typical to Kerberos, requires trust of the intermediate KDCs. The methods described in this draft allow a realm to specify, at the time of authentication, which certification paths it will trust. A shared key for cross-realm authentication can be established, for a period of time. Furthermore, these methods are transparent to the client, so that only the KDC's need to be modified to use them. It is not necessary to implement the changes described in the "Public Key Cryptography for Initial Authentication" draft to make use of the changes in this draft. We solicit comments about the interaction between the two protocol changes, but as of this writing, the authors do not perceive any obstacles to using both. 3. Protocol Amendments We assume that the user has already obtained a TGT. To perform cross-realm authentication, the user sends a request to the local KDC as per RFC 1510. If the two realms share a secret key, then cross-realm authentication proceeds as usual. Otherwise, the local KDC may attempt to establish a shared key with the remote KDC using public key cryptography, and exchange this key through the cross-realm ticket granting ticket. We will consider the specific channel on which the message exchanges take place in Section 5 below. 3.1. Changes to the Cross-Realm Ticket Granting Ticket In order to avoid the need for changes to the "installed base" of Kerberos application clients and servers, the only protocol change is to the way in which cross-realm ticket granting tickets (TGTs) are encrypted; as these tickets are opaque to clients and servers, the only change visible to them will be the increased size of the tickets. Cross-realm TGTs are granted by a local KDC to authenticate a user to a remote KDC's ticket granting service. In standard Kerberos, they are encrypted using a shared secret key manually configured into each KDC. In order to incorporate public key cryptography, we define a new encryption type, "ENCTYPE_PK_CROSS". Operationally, this encryption type transforms an OCTET STRING of plaintext (normally an EncTktPart) into the following SEQUENCE: PKCrossOutput ::= SEQUENCE { certificate [0] OCTET STRING OPTIONAL, -- public key certificate -- of local KDC encSharedKey [1] EncryptedData, -- of type EncryptionKey -- containing random symmetric key -- encrypted using public key -- of remote KDC sigSharedKey [2] Signature, -- of encSharedKey -- using signature key -- of local KDC pkEncData [3] EncryptedData, -- (normally) of type EncTktPart -- encrypted using encryption key -- found in encSharedKey } PKCROSS operates as follows: when a client submits a request for cross-realm authentication, the local KDC checks to see if it has a long-term shared key established for that realm. If so, it uses this key as per RFC 1510. If not, it sends a request for information to the remote KDC. The content of this message is immaterial, as it does not need to be processed by the remote KDC; for the sake of consistency, we define it as follows: RemoteRequest ::= [APPLICATION 41] SEQUENCE { nonce [0] INTEGER } The remote KDC replies with a list of all trusted certifiers and all its (the remote KDC's) certificates. We note that this response is universal and does not depend on which KDC makes the request: RemoteReply ::= [APPLICATION 42] SEQUENCE { trustedCertifiers [0] SEQUENCE OF PrincipalName, certificates[1] SEQUENCE OF Certificate, encTypeToUse [1] SEQUENCE OF INTEGER -- encryption types usable -- for encrypting pkEncData } Certificate ::= SEQUENCE { CertType [0] INTEGER, -- type of certificate -- 1 = X.509v3 (DER encoding) -- 2 = PGP (per PGP draft) CertData [1] OCTET STRING -- actual certificate -- type determined by CertType } -- from pk-init draft Upon receiving this reply, the local KDC determines whether it has a certificate the remote KDC trusts, and whether the remote KDC has a certificate the local KDC trusts. If so, it issues a ticket encrypted using the ENCTYPE_PK_CROSS encryption type defined above. 3.2. Profile Caches We observe that using PKCROSS as specified above requires two private key operations: a signature generation by the local KDC and a decryption by the remote KDC. This cost can be reduced in the long term by judicious caching of the encSharedKey and the sigSharedKey. Let us define a "profile" as the encSharedKey and sigSharedKey, in conjunction with the associated remote realm name and decrypted shared key (the key encrypted in the encSharedKey). To optimize these interactions, each KDC maintains two caches, one for outbound profiles and one for inbound profiles. When generating an outbound TGT for another realm, the local KDC first checks to see if the corresponding entry exists in the outbound profile cache; if so, it uses its contents to form the first three fields of the PKCrossOutput; the shared key is used to encrypt the data for the fourth field. If not, the components are generated fresh and stored in the outbound profile cache. Upon receipt of the TGT, the remote realm checks its inbound profile cache for the corresponding entry. If it exists, then it uses the contents of the entry to decrypt the data encrypted in the pkEncData. If not, then it goes through the full process of verifying and extracting the shared key; if this is successful, then a new entry is created in the inbound profile cache. The inbound profile cache should support multiple entries per realm, in the event that the initiating realm is replicated. 4. Finding Realms Supporting PKCROSS If either the local realm or the destination realm does not support PKCROSS, or both do not, the mechanism specified in Section 3 can still be used in obtaining the desired remote TGT. In the reference Kerberos implementations, the default behavior is to traverse a path up and down the realm name hierarchy, if the two realms do not share a key. There is, however, the possibility of using cross links--i.e., keys shared between two realms that are non-contiguous in the realm name hierarchy--to shorten the path, both to minimize delay and the number of intermediate realms that need to be trusted. PKCROSS can be used as a way to provide cross-links even in the absence of shared keys. If the client is aware that one or two intermediate realms support PKCROSS, then a combination of PKCROSS and conventional cross-realm authentication can be used to reach the final destination realm. We solicit discussion on the best methods for clients and KDCs to determine or advertise support for PKCROSS. 5. Message Ports We have not specified the port on which KDCs supporting PKCROSS should listen to receive the request for information messages noted above. We solicit discussion on which port should be used. We propose to use the standard Kerberos ports (well-known 88 or 750), but another possibility is to use a completely different port. We also solicit discussion on what other approaches can be taken to obtain the information in the RemoteReply (e.g., secure DNS or some other repository). 6. Expiration Date This Internet-Draft will expire on September 30, 1997. 7. Authors' Addresses Brian Tung Tatyana Ryutov Clifford Neuman Gene Tsudik USC/Information Sciences Institute 4676 Admiralty Way Suite 1001 Marina del Rey, CA 90292-6695 Phone: +1 310 822 1511 E-Mail: {brian, tryutov, bcn, gts}@isi.edu Bill Sommerfeld Hewlett Packard 300 Apollo Drive Chelmsford MA 01824 Phone: +1 508 436 4352 E-Mail: sommerfeld@apollo.hp.com Ari Medvinsky Matthew Hur CyberSafe Corporation 1605 NW Sammamish Road Suite 310 Issaquah WA 98027-5378 Phone: +1 206 391 6000 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com