third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt

   1
   2 INTERNET-DRAFT                                               Matthew Hur
   3 draft-ietf-cat-kerberos-pk-cross-06.txt            CyberSafe Corporation
   4 Updates: RFC 1510                                             Brian Tung
   5 expires October 10, 2000                                  Tatyana Ryutov
   6                                                          Clifford Neuman
   7                                                              Gene Tsudik
   8                                                                      ISI
   9                                                            Ari Medvinsky
  10                                                                 Keen.com
  11                                                          Bill Sommerfeld
  12                                                          Hewlett-Packard
  13
  14
  15     Public Key Cryptography for Cross-Realm Authentication in Kerberos
  16
  17
  18 0.  Status Of this Memo
  19
  20     This document is an Internet-Draft and is in full conformance with
  21     all provisions of Section 10 of RFC 2026.  Internet-Drafts are
  22     working documents of the Internet Engineering Task Force (IETF),
  23     its areas, and its working groups.  Note that other groups may
  24     also distribute working documents as Internet-Drafts.
  25
  26     Internet-Drafts are draft documents valid for a maximum of six
  27     months and may be updated, replaced, or obsoleted by other
  28     documents at any time.  It is inappropriate to use Internet-Drafts
  29     as reference material or to cite them other than as ``work in
  30     progress.''
  31
  32      The list of current Internet-Drafts can be accessed at
  33      http://www.ietf.org/ietf/1id-abstracts.txt
  34
  35      The list of Internet-Draft Shadow Directories can be accessed at
  36      http://www.ietf.org/shadow.html.
  37
  38
  39
  40     To learn the current status of any Internet-Draft, please check
  41     the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
  42     Shadow Directories on ftp.ietf.org (US East Coast),
  43     nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
  44     munnari.oz.au (Pacific Rim).
  45
  46     The distribution of this memo is unlimited.  It is filed as
  47     draft-ietf-cat-kerberos-pk-cross-06.txt, and expires May 15, 1999.
  48     Please send comments to the authors.
  49
  50
  51 1.  Abstract
  52
  53     This document defines extensions to the Kerberos protocol
  54     specification [1] to provide a method for using public key
  55     cryptography to enable cross-realm authentication.  The methods
  56     defined here specify the way in which message exchanges are to be
  57     used to transport cross-realm secret keys protected by encryption
  58     under public keys certified as belonging to KDCs.
  59
  60
  61 2.  Introduction
  62
  63     The Kerberos authentication protocol [2]  can leverage the
  64     advantages provided by public key cryptography.  PKINIT [3]
  65     describes the use of public key cryptography in the initial
  66     authentication exchange in Kerberos.  PKTAPP [4] describes how an
  67     application service can essentially issue a kerberos ticket to
  68     itself after utilizing public key cryptography for authentication.
  69     Another informational document species the use of public key
  70     crypography for anonymous authentication in Kerberos [5].  This
  71     specification describes the use of public key crpytography in cross-
  72     realm authentication.
  73
  74     Without the use of public key cryptography, administrators must
  75     maintain separate keys for every realm which wishes to exchange
  76     authentication information with another realm (which implies n(n-1)
  77     keys), or they must utilize a hierachichal arrangement of realms,
  78     which may complicate the trust model by requiring evaluation of
  79     transited realms.
  80
  81     Even with the multi-hop cross-realm authentication, there must be
  82     some way to locate the path by which separate realms are to be
  83     transited.  The current method, which makes use of the DNS-like
  84     realm names typical to Kerberos, requires trust of the intermediate
  85     KDCs.
  86
  87     PKCROSS utilizes a public key infrastructure (PKI) [6] to simplify
  88     the administrative burden of maintaining cross-realm keys.  Such
  89     usage leverages a PKI for a non-centrally-administratable environment
  90     (namely, inter-realm).  Thus, a shared key for cross-realm
  91     authentication can be established for a set period of time, and a
  92     remote realm is able to issue policy information that is returned to
  93     itself when a client requests cross-realm authentication. Such policy
  94     information may be in the form of restrictions [7].  Furthermore,
  95     these methods are transparent to the client; therefore, only the KDCs
  96     need to be modified to use them.  In this way, we take advantage of
  97     the the distributed trust management capabilities of public key
  98     crypography while maintaining the advantages of localized trust
  99     management provided by Kerberos.
 100
 101
 102     Although this specification utilizes the protocol specfied in the
 103     PKINIT specification, it is not necessary to implement client
 104     changes in order to make use of the changes in this document.
 105
 106
 107 3.  Objectives
 108
 109     The objectives of this specification are as follows:
 110
 111       1.  Simplify the administration required to establish Kerberos
 112           cross-realm keys.
 113
 114       2.  Avoid modification of clients and application servers.
 115
 116       3.  Allow remote KDC to control its policy on cross-realm
 117           keys shared between KDCs, and on cross-realm tickets
 118           presented by clients.
 119
 120       4.  Remove any need for KDCs to maintain state about keys
 121           shared with other KDCs.
 122
 123       5.  Leverage the work done for PKINIT to provide the public key
 124           protocol for establishing symmetric cross realm keys.
 125
 126
 127 4.  Definitions
 128
 129     The following notation is used throughout this specification:
 130     KDC_l ........... local KDC
 131     KDC_r ........... remote KDC
 132     XTKT_(l,r) ...... PKCROSS ticket that the remote KDC issues to the
 133                       local KDC
 134     TGT_(c,r) ....... cross-realm TGT that the local KDC issues to the
 135                       client for presentation to the remote KDC
 136
 137     This specification defines the following new types to be added to the
 138     Kerberos specification:
 139       PKCROSS kdc-options field in the AS_REQ is bit 9
 140       TE-TYPE-PKCROSS-KDC       2
 141       TE-TYPE-PKCROSS-CLIENT    3
 142
 143     This specification defines the following ASN.1 type for conveying
 144     policy information:
 145     CrossRealmTktData ::= SEQUENCE OF TypedData
 146
 147     This specification defines the following types for policy information
 148     conveyed in CrossRealmTktData:
 149       PLC_LIFETIME              1
 150       PLC_SET_TKT_FLAGS         2
 151       PLC_NOSET_TKT_FLAGS       3
 152
 153     TicketExtensions are defined per the Kerberos specification [8]:
 154     TicketExtensions ::= SEQUENCE OF TypedData
 155       Where
 156         TypedData ::=   SEQUENCE {
 157             data-type[0]   INTEGER,
 158             data-value[1]  OCTET STRING OPTIONAL
 159         }
 160
 161
 162 5.  Protocol Specification
 163
 164     We assume that the client has already obtained a TGT.  To perform
 165     cross-realm authentication, the client does exactly what it does
 166     with ordinary (i.e. non-public-key-enabled) Kerberos; the only
 167     changes are in the KDC; although the ticket which the client
 168     forwards to the remote realm may be changed.  This is acceptable
 169     since the client treats the ticket as opaque.
 170
 171
 172 5.1.  Overview of Protocol
 173
 174     The basic operation of the PKCROSS protocol is as follows:
 175
 176         1.  The client submits a request to the local KDC for
 177             credentials for the remote realm.  This is just a typical
 178             cross realm request that may occur with or without PKCROSS.
 179
 180         2.  The local KDC submits a PKINIT request to the remote KDC to
 181             obtain a "special" PKCROSS ticket.  This is a standard
 182             PKINIT request, except that PKCROSS flag (bit 9) is set in
 183             the kdc-options field in the AS_REQ.
 184
 185         3.  The remote KDC responds as per PKINIT, except that
 186             the ticket contains a TicketExtension, which contains
 187             policy information such as lifetime of cross realm tickets
 188             issued by KDC_l to a client.  The local KDC must reflect
 189             this policy information in the credentials it forwards to
 190             the client.  Call this ticket XTKT_(l,r) to indicate that
 191             this ticket is used to authenticate the local KDC to the
 192             remote KDC.
 193
 194         4.  The local KDC passes a ticket, TGT_(c,r) (the cross realm
 195             TGT between the client and remote KDC), to the client.
 196             This ticket contains in its TicketExtension field the
 197             ticket, XTKT_(l,r), which contains the cross-realm key.
 198             The TGT_(c,r) ticket is encrypted using the key sealed in
 199             XTKT_(l,r).  (The TicketExtension field is not encrypted.)
 200             The local KDC may optionally include another TicketExtension
 201             type that indicates the hostname and/or IP address for the
 202             remote KDC.
 203
 204         5.  The client submits the request directly to the remote
 205             KDC, as before.
 206
 207         6.  The remote KDC extracts XTKT_(l,r) from the TicketExtension
 208             in order to decrypt the encrypted part of TGT_(c,r).
 209
 210     --------------------------------------------------------------------
 211
 212     Client                Local KDC (KDC_l)           Remote KDC (KDC_r)
 213     ------                -----------------           ------------------
 214     Normal Kerberos
 215     request for
 216     cross-realm
 217     ticket for KDC_r
 218     ---------------------->
 219
 220                           PKINIT request for
 221                           XTKT(l,r) - PKCROSS flag
 222                           set in the AS-REQ
 223                           * ------------------------->
 224
 225                                                       PKINIT reply with
 226                                                       XTKT_(l,r) and
 227                                                       policy info in
 228                                                       ticket extension
 229                                            <-------------------------- *
 230
 231                           Normal Kerberos reply
 232                           with TGT_(c,r) and
 233                           XTKT(l,r) in ticket
 234                           extension
 235          <---------------------------------
 236
 237     Normal Kerberos
 238     cross-realm TGS-REQ
 239     for remote
 240     application
 241     service with
 242     TGT_(c,r) and
 243     XTKT(l,r) in ticket
 244     extension
 245     ------------------------------------------------->
 246
 247                                                       Normal Kerberos
 248                                                       cross-realm
 249                                                       TGS-REP
 250         <---------------------------------------------------------------
 251
 252     * Note that the KDC to KDC messages occur only periodically, since
 253       the local KDC caches the XTKT_(l,r).
 254     --------------------------------------------------------------------
 255
 256
 257     Sections 5.2 through 5.4 describe in detail steps 2 through 4
 258     above.  Section 5.6 describes the conditions under which steps
 259     2 and 3 may be skipped.
 260
 261     Note that the mechanism presented above requires infrequent KDC to
 262     KDC communication (as dictated by policy - this is discussed
 263     later).  Without such an exchange, there are the following issues:
 264     1) KDC_l would have to issue a ticket with the expectation that
 265        KDC_r will accept it.
 266     2) In the message that the client sends to KDC_r, KDC_l would have
 267        to authenticate KDC_r with credentials that KDC_r trusts.
 268     3) There is no way for KDC_r to convey policy information to KDC_l.
 269     4) If, based on local policy, KDC_r does not accept a ticket from
 270        KDC_l, then the client gets stuck in the middle.  To address such
 271        an issue would require modifications to standard client
 272        processing behavior.
 273     Therefore, the infreqeunt use of KDC to KDC communication assures
 274     that inter-realm KDC keys may be established in accordance with local
 275     policies and that clients may continue to operate without
 276     modification.
 277
 278
 279 5.2.  Local KDC's Request to Remote KDC
 280
 281     When the local KDC receives a request for cross-realm authentication,
 282     it first checks its ticket cache to see if it has a valid PKCROSS
 283     ticket, XTKT_(l,r).  If it has a valid XTKT_(l,r), then it does not
 284     need to send a request to the remote KDC (see section 5.5).
 285
 286     If the local KDC does not have a valid XTKT_(l,r), it sends a
 287     request to the remote KDC in order to establish a cross realm key and
 288     obtain the XTKT_(l,r).  This request is in fact a PKINIT request as
 289     described in the PKINIT specification; i.e., it consists of an AS-REQ
 290     with a PA-PK-AS-REQ included as a preauthentication field.  Note,
 291     that the AS-REQ MUST have the PKCROSS flag (bit 9) set in the
 292     kdc_options field of the AS-REQ.  Otherwise, this exchange exactly
 293     follows the description given in the PKINIT specification.  In
 294     addition, the naming
 295
 296
 297 5.3.  Remote KDC's Response to Local KDC
 298
 299     When the remote KDC receives the PKINIT/PKCROSS request from the
 300     local KDC, it sends back a PKINIT response as described in
 301     the PKINIT specification with the following exception: the encrypted
 302     part of the Kerberos ticket is not encrypted with the krbtgt key;
 303     instead, it is encrypted with the ticket granting server's PKCROSS
 304     key.  This key, rather than the krbtgt key, is used because it
 305     encrypts a ticket used for verifying a cross realm request rather
 306     than for issuing an application service ticket.  Note that, as a
 307     matter of policy, the session key for the XTKT_(l,r) MAY be of
 308     greater strength than that of a session key for a normal PKINIT
 309     reply, since the XTKT_(l,r) SHOULD be much longer lived than a
 310     normal application service ticket.
 311
 312     In addition, the remote KDC SHOULD include policy information in the
 313     XTKT_(l,r).  This policy information would then be reflected in the
 314     cross-realm TGT, TGT_(c,r).  Otherwise, the policy for TGT_(c,r)
 315     would be dictated by KDC_l rather than by KDC_r.  The local KDC MAY
 316     enforce a more restrictive local policy when creating a cross-realm
 317     ticket, TGT_(c,r).  For example, KDC_r  may dictate a lifetime
 318     policy of eight hours, but KDC_l may create TKT_(c,r) with a
 319     lifetime of four hours, as dictated by local policy.  Also, the
 320     remote KDC MAY include other information about itself along with the
 321     PKCROSS ticket.  These items are further discussed in section 6
 322     below.
 323
 324
 325 5.4.  Local KDC's Response to Client
 326
 327     Upon receipt of the PKINIT/CROSS response from the remote KDC,
 328     the local KDC formulates a response to the client.  This reply
 329     is constructed exactly as in the Kerberos specification, except
 330     for the following:
 331
 332     A) The local KDC places XTKT_(l,r) in the TicketExtension field of
 333        the client's cross-realm, ticket, TGT_(c,r), for the remote realm.
 334        Where
 335           data-type   equals 3 for TE-TYPE-PKCROSS-CLIENT
 336           data-value  is ASN.1 encoding of XTKT_(l,r)
 337
 338     B) The local KDC adds the name of its CA to the transited field of
 339        TGT_(c,r).
 340
 341
 342 5.5   Remote KDC's Processing of Client Request
 343
 344     When the remote KDC, KDC_r, receives a cross-realm ticket,
 345     TGT_(c,r), and it detects that the ticket contains a ticket
 346     extension of type TE-TYPE-PKCROSS-CLIENT, KDC_r must first decrypt
 347     the ticket, XTKT_(l,r), that is encoded in the ticket extension.
 348     KDC_r uses its PKCROSS key in order to decrypt XTKT_(l,r).  KDC_r
 349     then uses the key obtained from XTKT_(l,r) in order to decrypt the
 350     cross-realm ticket, TGT_(c,r).
 351
 352     KDC_r MUST verify that the cross-realm ticket, TGT_(c,r) is in
 353     compliance with any policy information contained in XTKT_(l,r) (see
 354     section 6).  If the TGT_(c,r) is not in compliance with policy, then
 355     the KDC_r responds to the client with a KRB-ERROR message of type
 356     KDC_ERR_POLICY.
 357
 358
 359 5.6.  Short-Circuiting the KDC-to-KDC Exchange
 360
 361     As we described earlier, the KDC to KDC exchange is required only
 362     for establishing a symmetric, inter-realm key.  Once this key is
 363     established (via the PKINIT exchange), no KDC to KDC communication
 364     is required until that key needs to be renewed.  This section
 365     describes the circumstances under which the KDC to KDC exchange
 366     described in Sections 5.2 and 5.3 may be skipped.
 367
 368     The local KDC has a known lifetime for TGT_(c,r).  This lifetime may
 369     be determined by policy information included in XTKT_(l,r), and/or
 370     it may be determined by local KDC policy.  If the local KDC already
 371     has a ticket XTKT(l,r), and the start time plus the lifetime for
 372     TGT_(c,r) does not exceed the expiration time for XTGT_(l,r), then
 373     the local KDC may skip the exchange with the remote KDC, and issue a
 374     cross-realm ticket to the client as described in Section 5.4.
 375
 376     Since the remote KDC may change its PKCROSS key (referred to in
 377     Section 5.2) while there are PKCROSS tickets still active, it SHOULD
 378     cache the old PKCROSS keys until the last issued PKCROSS ticket
 379     expires.  Otherwise, the remote KDC will respond to a client with a
 380     KRB-ERROR message of type KDC_ERR_TGT_REVOKED.
 381
 382
 383 6.  Extensions for the PKCROSS Ticket
 384
 385     As stated in section 5.3, the remote KDC SHOULD include policy
 386     information in XTKT_(l,r).  This policy information is contained in
 387     a TicketExtension, as defined by the Kerberos specification, and the
 388     authorization data of the ticket will contain an authorization
 389     record of type AD-IN-Ticket-Extensions.  The TicketExtension defined
 390     for use by PKCROSS is TE-TYPE-PKCROSS-KDC.
 391       Where
 392         data-type   equals 2 for TE-TYPE-PKCROSS-KDC
 393         data-value  is ASN.1 encoding of CrossRealmTktData
 394
 395       CrossRealmTktData ::= SEQUENCE OF TypedData
 396
 397
 398       ------------------------------------------------------------------
 399       CrossRealmTktData types and the corresponding data are interpreted
 400       as follows:
 401
 402                                                             ASN.1 data
 403       type                value   interpretation            encoding
 404       ----------------    -----   --------------            ----------
 405       PLC_LIFETIME          1     lifetime (in seconds)     INTEGER
 406                                   for TGT_(c,r)
 407                                   - cross-realm tickets
 408                                     issued for clients by
 409                                     TGT_l
 410
 411       PLC_SET_TKT_FLAGS     2     TicketFlags that must     BITSTRING
 412                                   be set
 413                                   - format defined by
 414                                     Kerberos specification
 415
 416       PLC_NOSET_TKT_FLAGS   3     TicketFlags that must     BITSTRING
 417                                   not be set
 418                                   - format defined by
 419                                     Kerberos specification
 420
 421       Further types may be added to this table.
 422       ------------------------------------------------------------------
 423
 424
 425 7.  Usage of Certificates
 426
 427     In the cases of PKINIT and PKCROSS, the trust in a certification
 428     authority is equivalent to Kerberos cross realm trust.  For this
 429     reason, an implementation MAY choose to use the same KDC certificate
 430     when the KDC is acting in any of the following three roles:
 431       1) KDC is authenticating clients via PKINIT
 432       2) KDC is authenticating another KDC for PKCROSS
 433       3) KDC is the client in a PKCROSS exchange with another KDC
 434
 435     Note that per PKINIT, the KDC X.509 certificate (the server in a
 436     PKINIT exchange) MUST contain the principal name of the KDC in the
 437     subjectAltName field.
 438
 439
 440 8.  Transport Issues
 441
 442     Because the messages between the KDCs involve PKINIT exchanges, and
 443     PKINIT recommends TCP as a transport mechanism (due to the length of
 444     the messages and the likelihood that they will fragment), the same
 445     recommendation for TCP applies to PKCROSS as well.
 446
 447
 448 9. Security Considerations
 449
 450    Since PKCROSS utilizes PKINIT, it is subject to the same security
 451    considerations as PKINIT.  Administrators should assure adherence
 452    to security policy - for example, this affects the PKCROSS policies
 453    for cross realm key lifetime and for policy propogation from the
 454    PKCROSS ticket, issued from a remote KDC to a local KDC, to
 455    cross realm tickets that are issued by a local KDC to a client.
 456
 457
 458 10. Bibliography
 459
 460   [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
 461   (V5).  Request for Comments 1510.
 462
 463   [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
 464   for Computer Networks, IEEE Communications, 32(9):33-38.  September
 465   1994.
 466
 467   [3] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray
 468   J. Trostle.  Public Key Cryptography for Initial Authentication
 469   in Kerberos.
 470   draft-ietf-cat-kerberos-pk-init-11.txt
 471
 472   [4] A. Medvinsky, M. Hur, S. Medvinsky, B. Clifford Neuman.  Public
 473   Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf-
 474   cat-pktapp-02.txt
 475
 476   [5] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
 477   Kerberos. draft-ietf-cat-kerberos-anoncred-01.txt
 478
 479   [6] ITU-T (formerly CCITT) Information technology - Open Systems
 480   Interconnection - The Directory: Authentication Framework
 481   Recommendation X.509 ISO/IEC 9594-8
 482
 483   [7] B.C. Neuman, Proxy-Based Authorization and Accounting for
 484   Distributed Systems.  In Proceedings of the 13th International
 485   Conference on Distributed Computing Systems, May 1993.
 486
 487   [8] C.Neuman, J. Kohl, T. Ts'o.  The Kerberos Network Authentication
 488   Service (V5). draft-ietf-cat-kerberos-revisions-05.txt
 489
 490
 491 11. Authors' Addresses
 492
 493     Matthew Hur
 494     CyberSafe Corporation
 495     1605 NW Sammamish Road
 496     Issaquah WA 98027-5378
 497     Phone: +1 425 391 6000
 498     E-mail: matt.hur@cybersafe.com
 499
 500     Brian Tung
 501     Tatyana Ryutov
 502     Clifford Neuman
 503     Gene Tsudik
 504     USC/Information Sciences Institute
 505     4676 Admiralty Way Suite 1001
 506     Marina del Rey, CA 90292-6695
 507     Phone: +1 310 822 1511
 508     E-Mail: {brian, tryutov, bcn, gts}@isi.edu
 509
 510     Ari Medvinsky
 511     Keen.com
 512     2480 Sand Hill Road, Suite 200
 513     Menlo Park, CA 94025
 514     Phone +1 650 289 3134
 515     E-mail: ari@keen.com
 516
 517     Bill Sommerfeld
 518     Hewlett Packard
 519     300 Apollo Drive
 520     Chelmsford MA 01824
 521     Phone: +1 508 436 4352
 522     E-Mail: sommerfeld@apollo.hp.com
 523