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