New Internet-Draft: pk-cross

[[e-mail]]

The following draft has been posted to the Internet Drafts server.
It is a sort of companion draft to pk-init; it specifies emendments
to RFC 1510 providing for public key support for cross-realm
authentication.

This draft was initially labelled improperly as ...-pk-cross-01.txt;
I've asked it to be changed to ...-pk-cross-00.txt but you might want
to look for it under both names.

Brian Tung
[e-mail]

=====

INTERNET-DRAFT                                              Brian Tung
draft-ietf-cat-kerberos-pk-cross-00.txt                 Tatyana Ryutov
Updates: RFC 1510                                      Clifford Neuman
expires May 25, 1997                                               ISI


    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-00.txt, and expires May 25, 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--resistance to
    key attacks, 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 advent of chained 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 Emendments

    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.

    We first address the case in which the local KDC has and trusts
    the remote KDC's public key certificate.  If it does not, then
    the two KDCs must exchange public keys, as described below in
    Section 3.2.

    We will consider the specific channel on which the message
    exchanges take place in Section 5 below.

3.1.  Shared Key Exchange

    The local KDC sends a message to the remote KDC containing the
    shared key to be used to perform cross-realm authentication,
    encrypted with the remote KDC's public key, and signed with
    the local KDC's private key:

        PKX-SHARED-KEY-SEND ::= [APPLICATION 31] SEQUENCE {
            signedKeyPack           [0] SignedKeyPack,
            pubKeyCert              [1] Certificate
        }

        SignedKeyPack ::= SEQUENCE {
            keyPack                 [0] KeyPack,
            sigKeyPack              [1] Signature
                                        -- of keyPack
        }

        KeyPack ::= SEQUENCE {
            encKeyData              [0] EncryptedData,
                                        -- of type KeyData
            timestamp               [1] KerberosTime,
            keyPackNonce            [2] INTEGER
        }

        KeyData ::= SEQUENCE {
            sharedKey               [0] EncryptionKey,
            keyExpiration           [1] KerberosTime OPTIONAL,
        }

        Signature ::= SEQUENCE {
            sigType                 [0] INTEGER,
            kvno                    [1] INTEGER OPTIONAL,
            signedHash              [2] OCTET STRING
        }

    where pubKeyCert contains the public key of the local KDC.  Its
    exact form will depend on the particular public key service used
    by the local KDC.

    Upon receiving of the PKX-SHARED-KEY-SEND, the remote KDC attempts
    to verify the pubKeyCert.  If it cannot verify the public key
    certificate, or if it finds the key unacceptable, the remote KDC
    returns an error message.  Otherwise, it returns a message to the
    local KDC, signed by the remote KDC's private key, acknowledging
    receipt of the shared key:

        PKX-SHARED-KEY-ACK ::= [APPLICATION 32] SEQUENCE {
            ackPack                 [0] AckPack,
            sigAckPack              [1] Signature
                                        -- of ackPack
        }

        AckPack ::= SEQUENCE {
            timestamp               [0] KerberosTime,
            keyPackNonce            [1] INTEGER,
                                        -- from type KeyPack
            ackNonce                [2] INTEGER
                                        -- new nonce
        }

    Since it is presumed that the local KDC has and trusts the remote
    KDC's public key, this key does not need to be included in its
    acknowledgment.

    Upon receipt of this acknowledgment, the local KDC issues a ticket
    to the client, encrypted with the shared key distributed using the
    above exchange.  This shared key can then be used for all subsequent
    cross-realm authentications to that particular remote KDC, for all
    clients, until the key expires.  The transited field of all such
    tickets should indicate, in addition to any realms transited, the
    certification path used to verify the local KDC's public key.

3.2.  Public Key Exchange

    In the event that the local KDC does not have the remote KDC's
    public key certificate, it must perform an exchange to obtain it.
    It begins by sending a message to the remote KDC, signed by the
    local KDC's private key:

        PKX-PUBLIC-KEY-SEND ::= [APPLICATION 33] SEQUENCE {
            signedListPack          [0] SignedListPack,
            pubKeyCert              [1] Certificate
        }

        SignedListPack ::= SEQUENCE {
            listPack                [0] ListPack,
            sigListPack             [1] Signature
                                        -- of listPack
        }

        ListPack ::= SEQUENCE {
            listTrust               [0] SEQUENCE OF OCTET STRING,
            timestamp               [1] KerberosTime,
            listPackNonce           [2] INTEGER
        }

    where listTrust is a list of certifiers trusted by the local KDC.

    Upon receipt of the PKX-PUBLIC-KEY-SEND, the remote KDC checks to
    see if its own public key is certified by one of the trusted
    certifiers.  If not, or if the signature is invalid, then it
    returns an error message.

    Otherwise, there are two cases: either the remote KDC trusts the
    local KDC's public key certificate, or it does not.  If it does
    not, then it sends back an error message with an e-data field of

        PKX-PUBLIC-KEY-ERROR ::= [APPLICATION 35] SEQUENCE {
            signedListPack          [0] SignedListPack,
            pubKeyCert              [1] Certificate
        }

    where the signedListPack contains a list of certifiers trusted
    by the *remote* KDC, and the pubKeyCert is the remote KDC's public
    key certificate, certified by one of the local KDC's trusted
    certifiers.  If the local KDC does not have a certificate signed
    by one of the remote KDC's trusted certifiers, then it returns an
    error message to the client.  Otherwise, it resends the
    PKX-PUBLIC-KEY-SEND, this time with a new public key certificate.

    If the remote KDC does trust the local KDC's public key, then it
    sends back an acknowledgment:

        PKX-PUBLIC-KEY-ACK ::= [APPLICATION 34] SEQUENCE {
            signedPubAck            [0] SignedPubAck,
            pubKeyCert              [1] Certificate
        }

        SignedPubAck ::= SEQUENCE {
            pubAckPack              [0] PubAckPack,
            sigPubAck               [1] Signature
                                        -- of pubAckPack
        }

        PubAckPack ::= SEQUENCE {
            timestamp               [0] KerberosTime,
            listPackNonce           [1] INTEGER,
                                        -- from listPack
            pubAckNonce             [2] INTEGER
                                        -- new nonce
        }

    Upon verification of the PKX-PUBLIC-KEY-ACK, the local KDC then
    proceeds with the basic exchange from Section 3.1.

4.  Finding Realms Supporting PK-CROSS

    If either the local realm or the destination realm does not support
    PK-CROSS, 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.

    PK-CROSS 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 PK-CROSS, then a combination of
    PK-CROSS 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 PK-CROSS.

5.  Message Ports

    We have not specified the port on which KDCs supporting PK-CROSS
    should listen to receive the additional messages described 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 the kadmin port.

6.  Authors' Addresses

    Brian Tung
    USC/Information Sciences Institute
    4676 Admiralty Way Suite 1001
    Marina del Rey, CA 90292-6695

    Phone: [phone]
    E-Mail: [e-mail]

    Tatyana Ryutov
    USC/Information Sciences Institute
    4676 Admiralty Way Suite 1001
    Marina del Rey, CA 90292-6695

    Phone: [phone]
    E-Mail: [e-mail]

    Clifford Neuman
    USC/Information Sciences Institute
    4676 Admiralty Way Suite 1001
    Marina del Rey, CA 90292-6695

    Phone: [phone]
    E-Mail: [e-mail]