diff options
Diffstat (limited to 'source4/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt')
| -rw-r--r-- | source4/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt | 282 |
1 files changed, 282 insertions, 0 deletions
diff --git a/source4/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt b/source4/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt new file mode 100644 index 00000000000..4b193c57390 --- /dev/null +++ b/source4/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt @@ -0,0 +1,282 @@ +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 |