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-02.txt < prev    next >
Text File  |  1997-08-01  |  13KB  |  297 lines
  1.  
  2. INTERNET-DRAFT                                              Brian Tung
  3. draft-ietf-cat-kerberos-pk-cross-02.txt                 Tatyana Ryutov
  4. Updates: RFC 1510                                      Clifford Neuman
  5. expires January 31, 1998                                   Gene Tsudik
  6.                                                                    ISI
  7.                                                        Bill Sommerfeld
  8.                                                        Hewlett-Packard
  9.                                                          Ari Medvinsky
  10.                                                            Matthew Hur
  11.                                                  CyberSafe Corporation
  12.  
  13.  
  14.     Public Key Cryptography for Cross-Realm Authentication in Kerberos
  15.  
  16.  
  17. 0.  Status Of this Memo
  18.  
  19.     This document is an Internet-Draft.  Internet-Drafts are working
  20.     documents of the Internet Engineering Task Force (IETF), its
  21.     areas, and its working groups.  Note that other groups may also
  22.     distribute working documents as Internet-Drafts.
  23.  
  24.     Internet-Drafts are draft documents valid for a maximum of six
  25.     months and may be updated, replaced, or obsoleted by other
  26.     documents at any time.  It is inappropriate to use Internet-Drafts
  27.     as reference material or to cite them other than as ``work in
  28.     progress.''
  29.  
  30.     To learn the current status of any Internet-Draft, please check
  31.     the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
  32.     Shadow Directories on ds.internic.net (US East Coast),
  33.     nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
  34.     munnari.oz.au (Pacific Rim).
  35.  
  36.     The distribution of this memo is unlimited.  It is filed as
  37.     draft-ietf-cat-kerberos-pk-cross-01.txt, and expires January 31,
  38.     1998.  Please send comments to the authors.
  39.  
  40.  
  41. 1.  Abstract
  42.  
  43.     This document defines extensions to the Kerberos protocol
  44.     specification (RFC 1510, 'The Kerberos Network Authentication
  45.     Service (V5)', September 1993) to provide a method for using
  46.     public key cryptography during cross-realm authentication.  The
  47.     methods defined here specify the way in which message exchanges
  48.     are to be used to transport cross-realm secret keys protected by
  49.     encryption under public keys certified as belonging to KDCs.
  50.  
  51.  
  52. 2.  Motivation
  53.  
  54.     The advantages provided by public key cryptography--ease of
  55.     recoverability in the event of a compromise, the possibility of
  56.     an autonomous authentication infrastructure, to name a few--have
  57.     produced a demand for use by Kerberos authentication protocol.  A
  58.     draft describing the use of public key cryptography in the initial
  59.     authentication exchange in Kerberos has already been submitted.
  60.     This draft describes its use in cross-realm authentication.
  61.  
  62.     The principal advantage provided by public key cryptography in
  63.     cross-realm authentication lies in the ability to leverage the
  64.     existing public key infrastructure.  It frees the Kerberos realm
  65.     administrator from having to maintain separate keys for each other
  66.     realm with which it wishes to exchange authentication information,
  67.     or to utilize a hierarchical arrangement, which may pose problems
  68.     of trust.
  69.  
  70.     Even with the multi-hop cross-realm authentication, there must be
  71.     some way to locate the path by which separate realms are to be
  72.     transited.  The current method, which makes use of the DNS-like
  73.     realm names typical to Kerberos, requires trust of the intermediate
  74.     KDCs.
  75.  
  76.     The methods described in this draft allow a realm to specify, at
  77.     the time of authentication, which certification paths it will
  78.     trust.  A shared key for cross-realm authentication can be
  79.     established, for a period of time.  Furthermore, these methods are
  80.     transparent to the client, so that only the KDC's need to be
  81.     modified to use them.
  82.  
  83.     It is not necessary to implement the changes described in the
  84.     "Public Key Cryptography for Initial Authentication" draft to make
  85.     use of the changes in this draft.  We solicit comments about the
  86.     interaction between the two protocol changes, but as of this
  87.     writing, the authors do not perceive any obstacles to using both.
  88.  
  89.  
  90. 3.  Protocol Amendments
  91.  
  92.     We assume that the user has already obtained a TGT.  To perform
  93.     cross-realm authentication, the user sends a request to the local
  94.     KDC as per RFC 1510.  If the two realms share a secret key, then
  95.     cross-realm authentication proceeds as usual.  Otherwise, the
  96.     local KDC may attempt to establish a shared key with the remote
  97.     KDC using public key cryptography, and exchange this key through
  98.     the cross-realm ticket granting ticket.
  99.  
  100.     We will consider the specific channel on which the message
  101.     exchanges take place in Section 5 below.
  102.  
  103.  
  104. 3.1.  Changes to the Cross-Realm Ticket Granting Ticket
  105.  
  106.     In order to avoid the need for changes to the "installed base" of
  107.     Kerberos application clients and servers, the only protocol change
  108.     is to the way in which cross-realm ticket granting tickets (TGTs)
  109.     are encrypted; as these tickets are opaque to clients and servers,
  110.     the only change visible to them will be the increased size of the
  111.     tickets.
  112.  
  113.     Cross-realm TGTs are granted by a local KDC to authenticate a user
  114.     to a remote KDC's ticket granting service.  In standard Kerberos,
  115.     they are encrypted using a shared secret key manually configured
  116.     into each KDC.
  117.  
  118.     In order to incorporate public key cryptography, we define a new
  119.     encryption type, "ENCTYPE_PK_CROSS".  Operationally, this encryption
  120.     type transforms an OCTET STRING of plaintext (normally an EncTktPart)
  121.     into the following SEQUENCE:
  122.  
  123.         PKCrossOutput ::= SEQUENCE {
  124.             certificate [0]     OCTET STRING OPTIONAL,
  125.                                     -- public key certificate
  126.                                     -- of local KDC
  127.             encSharedKey [1]    EncryptedData,
  128.                                     -- of type EncryptionKey
  129.                                     -- containing random symmetric key
  130.                                     -- encrypted using public key
  131.                                     -- of remote KDC
  132.             sigSharedKey [2]    Signature,
  133.                                     -- of encSharedKey
  134.                                     -- using signature key
  135.                                     -- of local KDC
  136.             pkEncData [3]       EncryptedData,
  137.                                     -- (normally) of type EncTktPart
  138.                                     -- encrypted using encryption key
  139.                                     -- found in encSharedKey
  140.         }
  141.  
  142.     The lifetime included in the ticket should be no longer than the
  143.     current time plus the maximum key lifetime allowed by the remote
  144.     realm (see below).
  145.  
  146.     PKCROSS operates as follows: when a client submits a request for
  147.     cross-realm authentication, the local KDC checks to see if it has
  148.     a long-term shared key established for that realm.  If so, it uses
  149.     this key as per RFC 1510.
  150.  
  151.     If not, it sends a request for information to the remote KDC.  The
  152.     content of this message is immaterial, as it does not need to be
  153.     processed by the remote KDC; for the sake of consistency, we define
  154.     it as follows:
  155.  
  156.         RemoteRequest ::= [APPLICATION 41] SEQUENCE {
  157.             nonce [0]                   INTEGER
  158.         }
  159.  
  160.     The remote KDC replies with a list of all trusted certifiers and
  161.     all its (the remote KDC's) certificates.  We note that this response
  162.     is universal and does not depend on which KDC makes the request:
  163.  
  164.         RemoteReply ::= [APPLICATION 42] SEQUENCE {
  165.             trustedCertifiers       [0] SEQUENCE OF PrincipalName,
  166.             certificates            [1] SEQUENCE OF Certificate,
  167.             encTypeToUse            [2] SEQUENCE OF INTEGER,
  168.                                         -- encryption types usable
  169.                                         -- for encrypting pkEncData
  170.             keyLifetime             [3] INTEGER
  171.                                         -- allowable lifetime for key
  172.                                         -- in seconds
  173.         }
  174.  
  175.         Certificate ::= SEQUENCE {
  176.             CertType                [0] INTEGER,
  177.                                         -- type of certificate
  178.                                         -- 1 = X.509v3 (DER encoding)
  179.                                         -- 2 = PGP (per PGP draft)
  180.             CertData                [1] OCTET STRING
  181.                                         -- actual certificate
  182.                                         -- type determined by CertType
  183.         } -- from pk-init draft
  184.  
  185.     Upon receiving this reply, the local KDC determines whether it has
  186.     a certificate the remote KDC trusts, and whether the remote KDC has
  187.     a certificate the local KDC trusts.  If so, it issues a ticket
  188.     encrypted using the ENCTYPE_PK_CROSS encryption type defined above.
  189.  
  190.  
  191. 3.2.  Profile Caches
  192.  
  193.     We observe that using PKCROSS as specified above requires two
  194.     private key operations: a signature generation by the local KDC and
  195.     a decryption by the remote KDC.  This cost can be reduced in the
  196.     long term by judicious caching of the encSharedKey and the
  197.     sigSharedKey.
  198.  
  199.     Let us define a "profile" as the encSharedKey and sigSharedKey, in
  200.     conjunction with the associated remote realm name and decrypted
  201.     shared key (the key encrypted in the encSharedKey).
  202.  
  203.     To optimize these interactions, each KDC maintains two caches, one
  204.     for outbound profiles and one for inbound profiles.  When generating
  205.     an outbound TGT for another realm, the local KDC first checks to see
  206.     if the corresponding entry exists in the outbound profile cache; if
  207.     so, it uses its contents to form the first three fields of the
  208.     PKCrossOutput; the shared key is used to encrypt the data for the
  209.     fourth field.  If not, the components are generated fresh and stored
  210.     in the outbound profile cache.
  211.  
  212.     Upon receipt of the TGT, the remote realm checks its inbound profile
  213.     cache for the corresponding entry.  If it exists, then it uses the
  214.     contents of the entry to decrypt the data encrypted in the pkEncData.
  215.     If not, then it goes through the full process of verifying and
  216.     extracting the shared key; if this is successful, then a new entry
  217.     is created in the inbound profile cache.
  218.  
  219.     The inbound profile cache should support multiple entries per realm,
  220.     in the event that the initiating realm is replicated.
  221.  
  222.  
  223. 4.  Finding Realms Supporting PKCROSS
  224.  
  225.     If either the local realm or the destination realm does not support
  226.     PKCROSS, or both do not, the mechanism specified in Section 3 can
  227.     still be used in obtaining the desired remote TGT.
  228.  
  229.     In the reference Kerberos implementations, the default behavior is
  230.     to traverse a path up and down the realm name hierarchy, if the
  231.     two realms do not share a key.  There is, however, the possibility
  232.     of using cross links--i.e., keys shared between two realms that
  233.     are non-contiguous in the realm name hierarchy--to shorten the
  234.     path, both to minimize delay and the number of intermediate realms
  235.     that need to be trusted.
  236.  
  237.     PKCROSS can be used as a way to provide cross-links even in the
  238.     absence of shared keys.  If the client is aware that one or two
  239.     intermediate realms support PKCROSS, then a combination of
  240.     PKCROSS and conventional cross-realm authentication can be used
  241.     to reach the final destination realm.
  242.  
  243.     We solicit discussion on the best methods for clients and KDCs to
  244.     determine or advertise support for PKCROSS.
  245.  
  246.  
  247. 5.  Transport Mechanism Issues
  248.  
  249.     We have not specified the port on which KDCs supporting PKCROSS
  250.     should listen to receive the request for information messages noted
  251.     above.  We solicit discussion on which port should be used.  We
  252.     propose to use the standard Kerberos ports (well-known 88 or 750),
  253.     but another possibility is to use a completely different port.
  254.  
  255.     Because the messages involved may get long (due to the
  256.     PKCrossOutput), UDP may break too frequently to be a viable choice
  257.     for transport.  Since the revised Kerberos RFC will explicitly
  258.     mention TCP as a possible mode of transport, we solicit discussion
  259.     on how to incorporate the use of TCP within PKCROSS.
  260.  
  261.     We also solicit discussion on what other approaches can be taken to
  262.     obtain the information in the RemoteReply (e.g., secure DNS or some
  263.     other repository).
  264.  
  265.  
  266. 6.  Expiration Date
  267.  
  268.     This Internet-Draft will expire on January 31, 1998.
  269.  
  270.  
  271. 7.  Authors' Addresses
  272.  
  273.     Brian Tung
  274.     Tatyana Ryutov
  275.     Clifford Neuman
  276.     Gene Tsudik
  277.     USC/Information Sciences Institute
  278.     4676 Admiralty Way Suite 1001
  279.     Marina del Rey, CA 90292-6695
  280.     Phone: +1 310 822 1511
  281.     E-Mail: {brian, tryutov, bcn, gts}@isi.edu
  282.  
  283.     Bill Sommerfeld
  284.     Hewlett Packard
  285.     300 Apollo Drive
  286.     Chelmsford MA 01824
  287.     Phone: +1 508 436 4352
  288.     E-Mail: sommerfeld@apollo.hp.com
  289.  
  290.     Ari Medvinsky
  291.     Matthew Hur
  292.     CyberSafe Corporation
  293.     1605 NW Sammamish Road Suite 310
  294.     Issaquah WA 98027-5378
  295.     Phone: +1 206 391 6000
  296.     E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
  297.