home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_a_c
/
draft-ietf-cat-kerberos-pk-cross-01.txt
< prev
next >
Wrap
Text File
|
1997-03-27
|
13KB
|
283 lines
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