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