crypto/heimdal-0.6.3/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt

   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