1 2INTERNET-DRAFT Matthew Hur 3draft-ietf-cat-kerberos-pk-cross-06.txt CyberSafe Corporation 4Updates: RFC 1510 Brian Tung 5expires 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 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 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 511. 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 612. 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 1073. 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 1274. 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 1625. 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 1725.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 2795.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 2975.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 3255.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 3425.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 3595.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 3836. 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 4257. 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 4408. 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 4489. 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 45810. 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 49111. 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 524