remove gcc34
[dragonfly.git] / crypto / heimdal-0.6.3 / 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