INTERNET-DRAFT                                               Matthew Hur
draft-ietf-cat-kerberos-pk-cross-08.txt                    Cisco Systems
Updates: RFC 1510                                             Brian Tung
November 8, 2001 (Expires May 8, 2001)                    Tatyana Ryutov
                                                         Clifford Neuman
                                                           Ari Medvinsky
                                                             Gene Tsudik
                                                               UC Irvine
                                                         Bill Sommerfeld
                                                        Sun Microsystems

    Public Key Cryptography for Cross-Realm Authentication in Kerberos

0.  Status Of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC 2026.  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

    To learn the current status of any Internet-Draft, please check
    the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
    Shadow Directories on (US East Coast), (Europe), (US West Coast), or (Pacific Rim).

     The list of current Internet-Drafts can be accessed at

     The list of Internet-Draft Shadow Directories can be accessed at

    The distribution of this memo is unlimited.  It is filed as
    draft-ietf-cat-kerberos-pk-cross-07.txt, and expires May 15, 2001.
    Please send comments to the authors.

1.  Abstract

    This document defines extensions to the Kerberos protocol
    specification [KERB] to provide a method for using public key
    cryptography to enable 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.  Introduction

    Symmetric and asymmetric key systems may co-exist within hybrid
    architectures in order to leverage the advantages and mitigiate
    issues within the respective systems.  An example of a hybrid
    solution that may employ both symmetric and asymmetric technologies
    is Kerberos ciphersuires in TLS [KERBTLS] which utilizes the
    Kerberos protocol [KERB] [KERB94] in conjunction with TLS [TLS]
    which has commonly been thought of as a public key protocol.

    The Kerberos can leverage the advantages provided by public key
    cryptography.  PKINIT [PKINIT] describes the use of public key
    cryptography in the initial authentication exchange in Kerberos.
    PKTAPP [PKTAPP] describes how an application service can essentially
    issue a kerberos ticket to itself after utilizing public key
    cryptography for authentication.  This specification describes the
    use of public key crpytography in cross-realm authentication.

    Without the use of public key cryptography, administrators must
    maintain separate keys for every realm which wishes to exchange
    authentication information with another realm (which implies n(n-1)
    keys), or they must utilize a hierachichal arrangement of realms,
    which may increase network traffic and complicate the trust model by
    requiring evaluation of transited realms.

    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

    PKCROSS utilizes a public key infrastructure (PKI) [X509] to
    simplify the administrative burden of maintaining cross-realm keys.
    Such usage leverages a PKI for a non-centrally-administratable
    environment (namely, inter-realm).  Thus, a shared key for cross-
    realm authentication can be established for a set period of time,
    and a remote realm is able to issue policy information that is
    returned to itself when a client requests cross-realm
    authentication. Such policy information may be in the form of
    restrictions [NEUMAN].  Furthermore, these methods are transparent
    to the client; therefore, only the KDCs need to be modified to use
    them.  In this way, we take advantage of the the distributed trust
    management capabilities of public key crypography while maintaining
    the advantages of localized trust management provided by Kerberos.

    Although this specification utilizes the protocol specfied in the
    PKINIT specification, it is not necessary to implement client
    changes in order to make use of the changes in this document.

3.  Objectives

    The objectives of this specification are as follows:

      1.  Simplify the administration required to establish Kerberos
          cross-realm keys.

      2.  Avoid modification of clients and application servers.

      3.  Allow remote KDC to control its policy on cross-realm
          keys shared between KDCs, and on cross-realm tickets
          presented by clients.

      4.  Remove any need for KDCs to maintain state about keys
          shared with other KDCs.

      5.  Leverage the work done for PKINIT to provide the public key
          protocol for establishing symmetric cross realm keys.

4.  Definitions

    The following notation is used throughout this specification:
    KDC_l ........... local KDC
    KDC_r ........... remote KDC
    XTKT_(l,r) ...... PKCROSS ticket that the remote KDC issues to the
                      local KDC
    TGT_(c,r) ....... cross-realm TGT that the local KDC issues to the
                      client for presentation to the remote KDC

    This specification defines the following new types to be added to
    the Kerberos specification:
      PKCROSS kdc-options field in the AS_REQ is bit 9
      TE-TYPE-PKCROSS-KDC       2

    This specification defines the following ASN.1 type for conveying
    policy information:
    CrossRealmTktData ::= SEQUENCE OF TypedData

    This specification defines the following types for policy
    information conveyed in CrossRealmTktData:
      PLC_LIFETIME              1
      PLC_SET_TKT_FLAGS         2
      PLC_NOSET_TKT_FLAGS       3

    TicketExtensions are defined per the Kerberos specification
    TicketExtensions ::= SEQUENCE OF TypedData
        TypedData ::=   SEQUENCE {
            data-type[0]   INTEGER,
            data-value[1]  OCTET STRING OPTIONAL

5.  Protocol Specification

    We assume that the client has already obtained a TGT.  To perform
    cross-realm authentication, the client does exactly what it does
    with ordinary (i.e. non-public-key-enabled) Kerberos; the only
    changes are in the KDC; although the ticket which the client
    forwards to the remote realm may be changed.  This is acceptable
    since the client treats the ticket as opaque.

5.1.  Overview of Protocol

    The basic operation of the PKCROSS protocol is as follows:

        1.  The client submits a request to the local KDC for
            credentials for the remote realm.  This is just a typical
            cross realm request that may occur with or without PKCROSS.

        2.  The local KDC submits a PKINIT request to the remote KDC to
            obtain a "special" PKCROSS ticket.  This is a standard
            PKINIT request, except that PKCROSS flag (bit 9) is set in
            the kdc-options field in the AS_REQ.  Note that the service
            name in the request is for pkcross/realm@REALM instead of

        3.  The remote KDC responds as per PKINIT, except that
            the ticket contains a TicketExtension, which contains
            policy information such as lifetime of cross realm tickets
            issued by KDC_l to a client.  The local KDC must reflect
            this policy information in the credentials it forwards to
            the client.  Call this ticket XTKT_(l,r) to indicate that
            this ticket is used to authenticate the local KDC to the
            remote KDC.

        4.  The local KDC passes a ticket, TGT_(c,r) (the cross realm
            TGT between the client and remote KDC), to the client.
            This ticket contains in its TicketExtension field the
            ticket, XTKT_(l,r), which contains the cross-realm key.
            The TGT_(c,r) ticket is encrypted using the key sealed in
            XTKT_(l,r).  (The TicketExtension field is not encrypted.)
            The local KDC may optionally include another TicketExtension
            type that indicates the hostname and/or IP address for the
            remote KDC.

        5.  The client submits the request directly to the remote
            KDC, as before.

        6.  The remote KDC extracts XTKT_(l,r) from the TicketExtension
            in order to decrypt the encrypted part of TGT_(c,r).


    Client                Local KDC (KDC_l)           Remote KDC (KDC_r)
    ------                -----------------           ------------------
    Normal Kerberos
    request for
    ticket for KDC_r

                          PKINIT request for
                          XTKT(l,r) - PKCROSS flag
                          set in the AS-REQ
                          * ------------------------->

                                                      PKINIT reply with
                                                      XTKT_(l,r) and
                                                      policy info in
                                                      ticket extension
                                           <-------------------------- *

                          Normal Kerberos reply
                          with TGT_(c,r) and
                          XTKT(l,r) in ticket

    Normal Kerberos
    cross-realm TGS-REQ
    for remote
    service with
    TGT_(c,r) and
    XTKT(l,r) in ticket

                                                      Normal Kerberos

    * Note that the KDC to KDC messages occur only periodically, since
      the local KDC caches the XTKT_(l,r).

    Sections 5.2 through 5.4 describe in detail steps 2 through 4
    above.  Section 5.6 describes the conditions under which steps
    2 and 3 may be skipped.

    Note that the mechanism presented above requires infrequent KDC to
    KDC communication (as dictated by policy - this is discussed
    later).  Without such an exchange, there are the following issues:
    1) KDC_l would have to issue a ticket with the expectation that
       KDC_r will accept it.
    2) In the message that the client sends to KDC_r, KDC_l would have
       to authenticate KDC_r with credentials that KDC_r trusts.
    3) There is no way for KDC_r to convey policy information to KDC_l.
    4) If, based on local policy, KDC_r does not accept a ticket from
       KDC_l, then the client gets stuck in the middle.  To address such
       an issue would require modifications to standard client
       processing behavior.
    Therefore, the infreqeunt use of KDC to KDC communication assures
    that inter-realm KDC keys may be established in accordance with local
    policies and that clients may continue to operate without

5.2.  Local KDC's Request to Remote KDC

    When the local KDC receives a request for cross-realm
    authentication, it first checks its ticket cache to see if it has a
    valid PKCROSS ticket, XTKT_(l,r).  If it has a valid XTKT_(l,r),
    then it does not need to send a request to the remote KDC (see
    section 5.5).

    If the local KDC does not have a valid XTKT_(l,r), it sends a
    request to the remote KDC (for pkcross/realm@REALM) in order to
    establish a cross realm key and obtain the XTKT_(l,r).  This request
    is in fact a PKINIT request as described in the PKINIT specification;
    i.e., it consists of an AS-REQ with a PA-PK-AS-REQ included as a
    preauthentication field.  Note, that the AS-REQ MUST have the PKCROSS
    flag (bit 9) set in the kdc_options field of the AS-REQ.  Otherwise,
    this exchange exactly follows the description given in the PKINIT

5.3.  Remote KDC's Response to Local KDC

    When the remote KDC receives the PKINIT/PKCROSS request from the
    local KDC, it sends back a PKINIT response as described in
    the PKINIT specification with the following exception: the encrypted
    part of the Kerberos ticket is not encrypted with the krbtgt key;
    instead, it is encrypted with the ticket granting server's PKCROSS
    key.  This key, rather than the krbtgt key, is used because it
    encrypts a ticket used for verifying a cross realm request rather
    than for issuing an application service ticket.  This is the reason
    that the name pkcross/realm@REALM is used instead of
    krbtgt/realm@REALM.  Note that, as a matter of policy, the session
    key for the XTKT_(l,r) MAY be of greater strength than that of a
    session key for a normal PKINIT reply, since the XTKT_(l,r) SHOULD
    be much longer lived than a normal application service ticket.

    In addition, the remote KDC SHOULD include policy information in the
    XTKT_(l,r).  This policy information would then be reflected in the
    cross-realm TGT, TGT_(c,r).  Otherwise, the policy for TGT_(c,r)
    would be dictated by KDC_l rather than by KDC_r.  The local KDC MAY
    enforce a more restrictive local policy when creating a cross-realm
    ticket, TGT_(c,r).  For example, KDC_r  may dictate a lifetime
    policy of eight hours, but KDC_l may create TKT_(c,r) with a
    lifetime of four hours, as dictated by local policy.  Also, the
    remote KDC MAY include other information about itself along with the
    PKCROSS ticket.  These items are further discussed in section 6

5.4.  Local KDC's Response to Client

    Upon receipt of the PKINIT/CROSS response from the remote KDC,
    the local KDC formulates a response to the client.  This reply
    is constructed exactly as in the Kerberos specification, except
    for the following:

    A) The local KDC places XTKT_(l,r) in the TicketExtension field of
       the client's cross-realm, ticket, TGT_(c,r), for the remote
          data-type   equals 3 for TE-TYPE-PKCROSS-CLIENT
          data-value  is ASN.1 encoding of XTKT_(l,r)

    B) The local KDC adds the name of its CA to the transited field of

5.5   Remote KDC's Processing of Client Request

    When the remote KDC, KDC_r, receives a cross-realm ticket,
    TGT_(c,r), and it detects that the ticket contains a ticket
    extension of type TE-TYPE-PKCROSS-CLIENT, KDC_r must first decrypt
    the ticket, XTKT_(l,r), that is encoded in the ticket extension.
    KDC_r uses its PKCROSS key in order to decrypt XTKT_(l,r).  KDC_r
    then uses the key obtained from XTKT_(l,r) in order to decrypt the
    cross-realm ticket, TGT_(c,r).

    KDC_r MUST verify that the cross-realm ticket, TGT_(c,r) is in
    compliance with any policy information contained in XTKT_(l,r) (see
    section 6).  If the TGT_(c,r) is not in compliance with policy, then
    the KDC_r responds to the client with a KRB-ERROR message of type

5.6.  Short-Circuiting the KDC-to-KDC Exchange

    As we described earlier, the KDC to KDC exchange is required only
    for establishing a symmetric, inter-realm key.  Once this key is
    established (via the PKINIT exchange), no KDC to KDC communication
    is required until that key needs to be renewed.  This section
    describes the circumstances under which the KDC to KDC exchange
    described in Sections 5.2 and 5.3 may be skipped.

    The local KDC has a known lifetime for TGT_(c,r).  This lifetime may
    be determined by policy information included in XTKT_(l,r), and/or
    it may be determined by local KDC policy.  If the local KDC already
    has a ticket XTKT(l,r), and the start time plus the lifetime for
    TGT_(c,r) does not exceed the expiration time for XTGT_(l,r), then
    the local KDC may skip the exchange with the remote KDC, and issue a
    cross-realm ticket to the client as described in Section 5.4.

    Since the remote KDC may change its PKCROSS key (referred to in
    Section 5.2) while there are PKCROSS tickets still active, it SHOULD
    cache the old PKCROSS keys until the last issued PKCROSS ticket
    expires.  Otherwise, the remote KDC will respond to a client with a
    KRB-ERROR message of type KDC_ERR_TGT_REVOKED.

6.  Extensions for the PKCROSS Ticket

    As stated in section 5.3, the remote KDC SHOULD include policy
    information in XTKT_(l,r).  This policy information is contained in
    a TicketExtension, as defined by the Kerberos specification, and the
    authorization data of the ticket will contain an authorization
    record of type AD-IN-Ticket-Extensions.  The TicketExtension defined
    for use by PKCROSS is TE-TYPE-PKCROSS-KDC.
        data-type   equals 2 for TE-TYPE-PKCROSS-KDC
        data-value  is ASN.1 encoding of CrossRealmTktData

      CrossRealmTktData ::= SEQUENCE OF TypedData

      CrossRealmTktData types and the corresponding data are interpreted
      as follows:

                                                            ASN.1 data
      type                value   interpretation            encoding
      ----------------    -----   --------------            ----------
      PLC_LIFETIME          1     lifetime (in seconds)     INTEGER
                                  for TGT_(c,r)
                                  - cross-realm tickets
                                    issued for clients by

      PLC_SET_TKT_FLAGS     2     TicketFlags that must     BITSTRING
                                  be set
                                  - format defined by
                                    Kerberos specification

      PLC_NOSET_TKT_FLAGS   3     TicketFlags that must     BITSTRING
                                  not be set
                                  - format defined by
                                    Kerberos specification

      Further types may be added to this table.

7.  Usage of Certificates

    In the cases of PKINIT and PKCROSS, the trust in a certification
    authority is equivalent to Kerberos cross realm trust.  For this
    reason, an implementation MAY choose to use the same KDC certificate
    when the KDC is acting in any of the following three roles:
      1) KDC is authenticating clients via PKINIT
      2) KDC is authenticating another KDC for PKCROSS
      3) KDC is the client in a PKCROSS exchange with another KDC

    Note that per PKINIT, the KDC X.509 certificate (the server in a
    PKINIT exchange) MUST contain the principal name of the KDC in the
    subjectAltName field.

8.  Transport Issues

    Because the messages between the KDCs involve PKINIT exchanges, and
    PKINIT recommends TCP as a transport mechanism (due to the length of
    the messages and the likelihood that they will fragment), the same
    recommendation for TCP applies to PKCROSS as well.

9. Security Considerations

   Since PKCROSS utilizes PKINIT, it is subject to the same security
   considerations as PKINIT.  Administrators should assure adherence
   to security policy - for example, this affects the PKCROSS policies
   for cross realm key lifetime and for policy propogation from the
   PKCROSS ticket, issued from a remote KDC to a local KDC, to
   cross realm tickets that are issued by a local KDC to a client.

10. Bibliography

  [KERBTLS]  A. Medvinsky and M. Hur, "Addition of Kerberos Cipher
             Suites to Transport Layer Security (TLS)", RFC 2712,
             October 1999.

  [KERB]     J. Kohl and C. Neuman, "The Kerberos Network
             Authentication Service (V5)", RFC 1510, September 1993.

  [TLS]      T. Dierks and C. Allen, "The TLS Protocol, Version 1.0",
             RFC 2246, January 1999.

  [PKINIT]   B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky,
             J. Wray, J. Trostle.  Public Key Cryptography for Initial
             Authentication in Kerberos.

  [PKTAPP]   A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman.
             Public Key Utilizing Tickets for Application
             Servers (PKTAPP).  draft-ietf-cat-kerberos-pk-tapp-03.txt

  [X509]     ITU-T (formerly CCITT) Information technology - Open
             Systems Interconnection - The Directory: Authentication
             Framework Recommendation X.509 ISO/IEC 9594-8

  [NEUMAN]   B.C. Neuman, "Proxy-Based Authorization and Accounting for
             Distributed Systems".  Proceedings of the 13th
             International Conference on Distributed Computing Systems,
             May 1993

  [KERB94]   B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication
             Service for Computer Networks, IEEE Communications,
             32(9):33-38.  September 1994.

  [KERB-REV] C.Neuman, J. Kohl, T. Ts'o.  The Kerberos Network
             Authentication Service (V5).

11. Authors' Addresses

    Matthew Hur
    Cisco Systems
    2901 Third Avenue
    Seattle, WA 98121
    Phone: +1 206 256 3197

    Brian Tung
    Tatyana Ryutov
    Clifford Neuman
    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}

    Ari Medvinsky
    2 Circle Star Way
    San Carlos, CA 94070-6200
    Phone: +1 650 701 4000

    Gene Tsudik
    ICS Dept, 458 CS Building
    Irvine CA 92697-3425
    Phone: +1 310 448 9329

    Bill Sommerfeld
    Sun Microsystems