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-00.txt < prev    next >
Text File  |  1996-11-27  |  13KB  |  305 lines
  1.  
  2. INTERNET-DRAFT                                              Brian Tung
  3. draft-ietf-cat-kerberos-pk-cross-00.txt                 Tatyana Ryutov
  4. Updates: RFC 1510                                      Clifford Neuman
  5. expires May 25, 1997                                               ISI
  6.  
  7.  
  8.     Public Key Cryptography for Cross-Realm Authentication in Kerberos
  9.  
  10.  
  11. 0.  Status Of this Memo
  12.  
  13.     This document is an Internet-Draft.  Internet-Drafts are working
  14.     documents of the Internet Engineering Task Force (IETF), its
  15.     areas, and its working groups.  Note that other groups may also
  16.     distribute working documents as Internet-Drafts.
  17.  
  18.     Internet-Drafts are draft documents valid for a maximum of six
  19.     months and may be updated, replaced, or obsoleted by other
  20.     documents at any time.  It is inappropriate to use Internet-Drafts
  21.     as reference material or to cite them other than as ``work in
  22.     progress.''
  23.  
  24.     To learn the current status of any Internet-Draft, please check
  25.     the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
  26.     Shadow Directories on ds.internic.net (US East Coast),
  27.     nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
  28.     munnari.oz.au (Pacific Rim).
  29.  
  30.     The distribution of this memo is unlimited.  It is filed as
  31.     draft-ietf-cat-kerberos-pk-cross-00.txt, and expires May 25, 1997.
  32.     Please send comments to the authors.
  33.  
  34. 1.  Abstract
  35.  
  36.     This document defines extensions to the Kerberos protocol
  37.     specification (RFC 1510, "The Kerberos Network Authentication
  38.     Service (V5)", September 1993) to provide a method for using
  39.     public key cryptography during cross-realm authentication.  The
  40.     methods defined here specify the way in which message exchanges
  41.     are to be used to transport cross-realm secret keys protected by
  42.     encryption under public keys certified as belonging to KDCs.
  43.  
  44. 2.  Motivation
  45.  
  46.     The advantages provided by public key cryptography--resistance to
  47.     key attacks, ease of recoverability in the event of a compromise,
  48.     the possibility of an autonomous authentication infrastructure, to
  49.     name a few--have produced a demand for use by Kerberos
  50.     authentication protocol.  A draft describing the use of public key
  51.     cryptography in the initial authentication exchange in Kerberos
  52.     has already been submitted.  This draft describes its use in
  53.     cross-realm authentication.
  54.  
  55.     The principal advantage provided by public key cryptography in
  56.     cross-realm authentication lies in the ability to leverage the
  57.     existing public key infrastructure.  It frees the Kerberos realm
  58.     administrator from having to maintain separate keys for each other
  59.     realm with which it wishes to exchange authentication information,
  60.     or to utilize a hierarchical arrangement, which may pose problems
  61.     of trust.
  62.  
  63.     Even with the advent of chained cross-realm authentication, there
  64.     must be some way to locate the path by which separate realms are
  65.     to be transited.  The current method, which makes use of the
  66.     DNS-like realm names typical to Kerberos, requires trust of the
  67.     intermediate KDCs.
  68.  
  69.     The methods described in this draft allow a realm to specify, at
  70.     the time of authentication, which certification paths it will
  71.     trust.  A shared key for cross-realm authentication can be
  72.     established, for a period of time.  Furthermore, these methods are
  73.     transparent to the client, so that only the KDC's need to be
  74.     modified to use them.
  75.  
  76.     It is not necessary to implement the changes described in the
  77.     "Public Key Cryptography for Initial Authentication" draft to make
  78.     use of the changes in this draft.  We solicit comments about the
  79.     interaction between the two protocol changes, but as of this
  80.     writing, the authors do not perceive any obstacles to using both.
  81.  
  82. 3.  Protocol Emendments
  83.  
  84.     We assume that the user has already obtained a TGT.  To perform
  85.     cross-realm authentication, the user sends a request to the local
  86.     KDC as per RFC 1510.  If the two realms share a secret key, then
  87.     cross-realm authentication proceeds as usual.  Otherwise, the
  88.     local KDC may attempt to establish a shared key with the remote
  89.     KDC using public key cryptography.
  90.  
  91.     We first address the case in which the local KDC has and trusts
  92.     the remote KDC's public key certificate.  If it does not, then
  93.     the two KDCs must exchange public keys, as described below in
  94.     Section 3.2.
  95.  
  96.     We will consider the specific channel on which the message
  97.     exchanges take place in Section 5 below.
  98.  
  99. 3.1.  Shared Key Exchange
  100.  
  101.     The local KDC sends a message to the remote KDC containing the
  102.     shared key to be used to perform cross-realm authentication,
  103.     encrypted with the remote KDC's public key, and signed with
  104.     the local KDC's private key:
  105.  
  106.         PKX-SHARED-KEY-SEND ::= [APPLICATION 31] SEQUENCE {
  107.             signedKeyPack           [0] SignedKeyPack,
  108.             pubKeyCert              [1] Certificate
  109.         }
  110.  
  111.         SignedKeyPack ::= SEQUENCE {
  112.             keyPack                 [0] KeyPack,
  113.             sigKeyPack              [1] Signature
  114.                                         -- of keyPack
  115.         }
  116.  
  117.         KeyPack ::= SEQUENCE {
  118.             encKeyData              [0] EncryptedData,
  119.                                         -- of type KeyData
  120.             timestamp               [1] KerberosTime,
  121.             keyPackNonce            [2] INTEGER
  122.         }
  123.  
  124.         KeyData ::= SEQUENCE {
  125.             sharedKey               [0] EncryptionKey,
  126.             keyExpiration           [1] KerberosTime OPTIONAL,
  127.         }
  128.  
  129.         Signature ::= SEQUENCE {
  130.             sigType                 [0] INTEGER,
  131.             kvno                    [1] INTEGER OPTIONAL,
  132.             signedHash              [2] OCTET STRING
  133.         }
  134.  
  135.     where pubKeyCert contains the public key of the local KDC.  Its
  136.     exact form will depend on the particular public key service used
  137.     by the local KDC.
  138.  
  139.     Upon receiving of the PKX-SHARED-KEY-SEND, the remote KDC attempts
  140.     to verify the pubKeyCert.  If it cannot verify the public key
  141.     certificate, or if it finds the key unacceptable, the remote KDC
  142.     returns an error message.  Otherwise, it returns a message to the
  143.     local KDC, signed by the remote KDC's private key, acknowledging
  144.     receipt of the shared key:
  145.  
  146.         PKX-SHARED-KEY-ACK ::= [APPLICATION 32] SEQUENCE {
  147.             ackPack                 [0] AckPack,
  148.             sigAckPack              [1] Signature
  149.                                         -- of ackPack
  150.         }
  151.  
  152.         AckPack ::= SEQUENCE {
  153.             timestamp               [0] KerberosTime,
  154.             keyPackNonce            [1] INTEGER,
  155.                                         -- from type KeyPack
  156.             ackNonce                [2] INTEGER
  157.                                         -- new nonce
  158.         }
  159.  
  160.     Since it is presumed that the local KDC has and trusts the remote
  161.     KDC's public key, this key does not need to be included in its
  162.     acknowledgment.
  163.  
  164.     Upon receipt of this acknowledgment, the local KDC issues a ticket
  165.     to the client, encrypted with the shared key distributed using the
  166.     above exchange.  This shared key can then be used for all subsequent
  167.     cross-realm authentications to that particular remote KDC, for all
  168.     clients, until the key expires.  The transited field of all such
  169.     tickets should indicate, in addition to any realms transited, the
  170.     certification path used to verify the local KDC's public key.
  171.  
  172. 3.2.  Public Key Exchange
  173.  
  174.     In the event that the local KDC does not have the remote KDC's
  175.     public key certificate, it must perform an exchange to obtain it.
  176.     It begins by sending a message to the remote KDC, signed by the
  177.     local KDC's private key:
  178.  
  179.         PKX-PUBLIC-KEY-SEND ::= [APPLICATION 33] SEQUENCE {
  180.             signedListPack          [0] SignedListPack,
  181.             pubKeyCert              [1] Certificate
  182.         }
  183.  
  184.         SignedListPack ::= SEQUENCE {
  185.             listPack                [0] ListPack,
  186.             sigListPack             [1] Signature
  187.                                         -- of listPack
  188.         }
  189.  
  190.         ListPack ::= SEQUENCE {
  191.             listTrust               [0] SEQUENCE OF OCTET STRING,
  192.             timestamp               [1] KerberosTime,
  193.             listPackNonce           [2] INTEGER
  194.         }
  195.  
  196.     where listTrust is a list of certifiers trusted by the local KDC.
  197.  
  198.     Upon receipt of the PKX-PUBLIC-KEY-SEND, the remote KDC checks to
  199.     see if its own public key is certified by one of the trusted
  200.     certifiers.  If not, or if the signature is invalid, then it
  201.     returns an error message.
  202.  
  203.     Otherwise, there are two cases: either the remote KDC trusts the
  204.     local KDC's public key certificate, or it does not.  If it does
  205.     not, then it sends back an error message with an e-data field of
  206.  
  207.         PKX-PUBLIC-KEY-ERROR ::= [APPLICATION 35] SEQUENCE {
  208.             signedListPack          [0] SignedListPack,
  209.             pubKeyCert              [1] Certificate
  210.         }
  211.  
  212.     where the signedListPack contains a list of certifiers trusted
  213.     by the *remote* KDC, and the pubKeyCert is the remote KDC's public
  214.     key certificate, certified by one of the local KDC's trusted
  215.     certifiers.  If the local KDC does not have a certificate signed
  216.     by one of the remote KDC's trusted certifiers, then it returns an
  217.     error message to the client.  Otherwise, it resends the
  218.     PKX-PUBLIC-KEY-SEND, this time with a new public key certificate.
  219.  
  220.     If the remote KDC does trust the local KDC's public key, then it
  221.     sends back an acknowledgment:
  222.  
  223.         PKX-PUBLIC-KEY-ACK ::= [APPLICATION 34] SEQUENCE {
  224.             signedPubAck            [0] SignedPubAck,
  225.             pubKeyCert              [1] Certificate
  226.         }
  227.  
  228.         SignedPubAck ::= SEQUENCE {
  229.             pubAckPack              [0] PubAckPack,
  230.             sigPubAck               [1] Signature
  231.                                         -- of pubAckPack
  232.         }
  233.  
  234.         PubAckPack ::= SEQUENCE {
  235.             timestamp               [0] KerberosTime,
  236.             listPackNonce           [1] INTEGER,
  237.                                         -- from listPack
  238.             pubAckNonce             [2] INTEGER
  239.                                         -- new nonce
  240.         }
  241.  
  242.     Upon verification of the PKX-PUBLIC-KEY-ACK, the local KDC then
  243.     proceeds with the basic exchange from Section 3.1.
  244.  
  245. 4.  Finding Realms Supporting PK-CROSS
  246.  
  247.     If either the local realm or the destination realm does not support
  248.     PK-CROSS, or both do not, the mechanism specified in Section 3 can
  249.     still be used in obtaining the desired remote TGT.
  250.  
  251.     In the reference Kerberos implementations, the default behavior is
  252.     to traverse a path up and down the realm name hierarchy, if the
  253.     two realms do not share a key.  There is, however, the possibility
  254.     of using cross links--i.e., keys shared between two realms that
  255.     are non-contiguous in the realm name hierarchy--to shorten the
  256.     path, both to minimize delay and the number of intermediate realms
  257.     that need to be trusted.
  258.  
  259.     PK-CROSS can be used as a way to provide cross-links even in the
  260.     absence of shared keys.  If the client is aware that one or two
  261.     intermediate realms support PK-CROSS, then a combination of
  262.     PK-CROSS and conventional cross-realm authentication can be used
  263.     to reach the final destination realm.
  264.  
  265.     We solicit discussion on the best methods for clients and KDCs to
  266.     determine or advertise support for PK-CROSS.
  267.  
  268. 5.  Message Ports
  269.  
  270.     We have not specified the port on which KDCs supporting PK-CROSS
  271.     should listen to receive the additional messages described above.
  272.     We solicit discussion on which port should be used.  We propose to
  273.     use the standard Kerberos ports (well-known 88 or 750), but another
  274.     possibility is to use the kadmin port.
  275.  
  276. 6.  Expiration Date
  277.  
  278.     This Internet-Draft will expire on or about May 25, 1997.
  279.  
  280. 7.  Authors' Addresses
  281.  
  282.     Brian Tung
  283.     USC/Information Sciences Institute
  284.     4676 Admiralty Way Suite 1001
  285.     Marina del Rey, CA 90292-6695
  286.  
  287.     Phone: 310-822-1511
  288.     E-Mail: brian@isi.edu
  289.  
  290.     Tatyana Ryutov
  291.     USC/Information Sciences Institute
  292.     4676 Admiralty Way Suite 1001
  293.     Marina del Rey, CA 90292-6695
  294.  
  295.     Phone: 310-822-1511
  296.     E-Mail: tryutov@isi.edu
  297.  
  298.     Clifford Neuman
  299.     USC/Information Sciences Institute
  300.     4676 Admiralty Way Suite 1001
  301.     Marina del Rey, CA 90292-6695
  302.  
  303.     Phone: 310-822-1511
  304.     E-Mail: bcn@isi.edu
  305.