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