283 lines
12 KiB
Plaintext
283 lines
12 KiB
Plaintext
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
|