+++ /dev/null
-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
git.samba.org / samba.git / blobdiff