Update gnulib files.

[shishi.git] / doc / specifications / draft-ietf-cat-kerberos-pk-cross-02.txt

INTERNET-DRAFT                                              Brian Tung
draft-ietf-cat-kerberos-pk-cross-02.txt                 Tatyana Ryutov
Updates: RFC 1510                                      Clifford Neuman
expires January 31, 1998                                   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 January 31,
    1998.  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
        }

    The lifetime included in the ticket should be no longer than the
    current time plus the maximum key lifetime allowed by the remote
    realm (see below).

    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            [2] SEQUENCE OF INTEGER,
                                        -- encryption types usable
                                        -- for encrypting pkEncData
            keyLifetime             [3] INTEGER
                                        -- allowable lifetime for key
                                        -- in seconds
        }

        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.  Transport Mechanism Issues

    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.

    Because the messages involved may get long (due to the
    PKCrossOutput), UDP may break too frequently to be a viable choice
    for transport.  Since the revised Kerberos RFC will explicitly
    mention TCP as a possible mode of transport, we solicit discussion
    on how to incorporate the use of TCP within PKCROSS.

    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 January 31, 1998.


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