| blob | 41b8e8e5f45a1d180f2e2d6031603901c871bf9d |
1 INTERNET-DRAFT Matthew Hur
2 draft-ietf-cat-kerberos-pk-cross-08.txt Cisco Systems
3 Updates: RFC 1510 Brian Tung
4 November 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
15 Public Key Cryptography for Cross-Realm Authentication in Kerberos
18 0. Status Of this Memo
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.
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.''
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).
38 The list of current Internet-Drafts can be accessed at
39 http://www.ietf.org/1id-abstracts.html
41 The list of Internet-Draft Shadow Directories can be accessed at
42 http://www.ietf.org/shadow.html
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.
51 1. Abstract
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.
61 2. Introduction
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.
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.
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.
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.
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.
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.
112 3. Objectives
114 The objectives of this specification are as follows:
116 1. Simplify the administration required to establish Kerberos
117 cross-realm keys.
119 2. Avoid modification of clients and application servers.
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.
125 4. Remove any need for KDCs to maintain state about keys
126 shared with other KDCs.
128 5. Leverage the work done for PKINIT to provide the public key
129 protocol for establishing symmetric cross realm keys.
132 4. Definitions
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
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
148 This specification defines the following ASN.1 type for conveying
149 policy information:
150 CrossRealmTktData ::= SEQUENCE OF TypedData
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
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 }
168 5. Protocol Specification
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.
178 5.1. Overview of Protocol
180 The basic operation of the PKCROSS protocol is as follows:
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.
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.
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.
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.
212 5. The client submits the request directly to the remote
213 KDC, as before.
215 6. The remote KDC extracts XTKT_(l,r) from the TicketExtension
216 in order to decrypt the encrypted part of TGT_(c,r).
218 --------------------------------------------------------------------
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 ---------------------->
228 PKINIT request for
229 XTKT(l,r) - PKCROSS flag
230 set in the AS-REQ
231 * ------------------------->
233 PKINIT reply with
234 XTKT_(l,r) and
235 policy info in
236 ticket extension
237 <-------------------------- *
239 Normal Kerberos reply
240 with TGT_(c,r) and
241 XTKT(l,r) in ticket
242 extension
243 <---------------------------------
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 ------------------------------------------------->
255 Normal Kerberos
256 cross-realm
257 TGS-REP
258 <---------------------------------------------------------------
260 * Note that the KDC to KDC messages occur only periodically, since
261 the local KDC caches the XTKT_(l,r).
262 --------------------------------------------------------------------
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.
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.
287 5.2. Local KDC's Request to Remote KDC
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).
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.
306 5.3. Remote KDC's Response to Local KDC
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.
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.
335 5.4. Local KDC's Response to Client
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:
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)
349 B) The local KDC adds the name of its CA to the transited field of
350 TGT_(c,r).
353 5.5 Remote KDC's Processing of Client Request
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).
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.
370 5.6. Short-Circuiting the KDC-to-KDC Exchange
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.
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.
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.
394 6. Extensions for the PKCROSS Ticket
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
406 CrossRealmTktData ::= SEQUENCE OF TypedData
409 ------------------------------------------------------------------
410 CrossRealmTktData types and the corresponding data are interpreted
411 as follows:
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
422 PLC_SET_TKT_FLAGS 2 TicketFlags that must BITSTRING
423 be set
424 - format defined by
425 Kerberos specification
427 PLC_NOSET_TKT_FLAGS 3 TicketFlags that must BITSTRING
428 not be set
429 - format defined by
430 Kerberos specification
432 Further types may be added to this table.
433 ------------------------------------------------------------------
436 7. Usage of Certificates
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
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.
451 8. Transport Issues
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.
459 9. Security Considerations
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.
469 10. Bibliography
471 [KERBTLS] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher
472 Suites to Transport Layer Security (TLS)", RFC 2712,
473 October 1999.
475 [KERB] J. Kohl and C. Neuman, "The Kerberos Network
476 Authentication Service (V5)", RFC 1510, September 1993.
478 [TLS] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0",
479 RFC 2246, January 1999.
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
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
490 [X509] ITU-T (formerly CCITT) Information technology - Open
491 Systems Interconnection - The Directory: Authentication
492 Framework Recommendation X.509 ISO/IEC 9594-8
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
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.
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
508 11. Authors' Addresses
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
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
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
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
539 Bill Sommerfeld
540 Sun Microsystems
541 E-Mail: sommerfeld@east.sun.com