| blob | 1cea8d45929ee409c76ab749cfc7aaa83a370422 |
2 INTERNET-DRAFT Brian Tung
3 draft-ietf-cat-kerberos-pk-cross-03.txt Tatyana Ryutov
4 Updates: RFC 1510 Clifford Neuman
5 expires May 26, 1998 Gene Tsudik
6 ISI
7 Bill Sommerfeld
8 Hewlett-Packard
9 Ari Medvinsky
10 Matthew Hur
11 CyberSafe Corporation
14 Public Key Cryptography for Cross-Realm Authentication in Kerberos
17 0. Status Of this Memo
19 This document is an Internet-Draft. Internet-Drafts are working
20 documents of the Internet Engineering Task Force (IETF), its
21 areas, and its working groups. Note that other groups may also
22 distribute working documents as Internet-Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six
25 months and may be updated, replaced, or obsoleted by other
26 documents at any time. It is inappropriate to use Internet-Drafts
27 as reference material or to cite them other than as ``work in
28 progress.''
30 To learn the current status of any Internet-Draft, please check
31 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
32 Shadow Directories on ds.internic.net (US East Coast),
33 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
34 munnari.oz.au (Pacific Rim).
36 The distribution of this memo is unlimited. It is filed as
37 draft-ietf-cat-kerberos-pk-cross-03.txt, and expires May 26, 1998.
38 Please send comments to the authors.
41 1. Abstract
43 This document defines extensions to the Kerberos protocol
44 specification (RFC 1510, ''The Kerberos Network Authentication
45 Service (V5)'', September 1993) to provide a method for using
46 public key cryptography during cross-realm authentication. The
47 methods defined here specify the way in which message exchanges
48 are to be used to transport cross-realm secret keys protected by
49 encryption under public keys certified as belonging to KDCs.
52 2. Introduction
54 The advantages provided by public key cryptography have
55 produced a demand for use by the Kerberos authentication protocol.
56 A draft describing the use of public key cryptography in the
57 initial authentication exchange in Kerberos has already been
58 submitted. This draft describes its use in cross-realm
59 authentication.
61 The principal advantage provided by public key cryptography in
62 cross-realm authentication lies in the ability to leverage the
63 existing public key infrastructure. It frees the Kerberos realm
64 administrator from having to maintain separate keys for each other
65 realm with which it wishes to exchange authentication information,
66 or from having to utilize a hierarchical arrangement, which may
67 pose problems of trust.
69 Even with the multi-hop cross-realm authentication, there must be
70 some way to locate the path by which separate realms are to be
71 transited. The current method, which makes use of the DNS-like
72 realm names typical to Kerberos, requires trust of the intermediate
73 KDCs.
75 The methods described in this draft allow a realm to specify, at
76 the time of authentication, which certification paths it will
77 trust. A shared key for cross-realm authentication can be
78 established for a set period of time. Furthermore, these methods
79 are transparent to the client; therefore, only the KDCs need to be
80 modified to use them.
82 It is not necessary to implement the changes described in the
83 "Public Key Cryptography for Initial Authentication" draft to make
84 use of the changes in this draft. We solicit comments about the
85 interaction between the two protocol changes, but as of this
86 writing, the authors do not perceive any obstacles to using both.
89 3. Protocol Specification
91 We assume that the client has already obtained a TGT. To perform
92 cross-realm authentication, the client does exactly what it does
93 with ordinary (i.e., non-public-key-enabled) Kerberos; the only
94 changes are in the KDC; although the ticket which the client
95 forwards to the remote realm may be changed. This is acceptable
96 since the client treats the ticket as opaque.
98 The revised PKCROSS protocol makes use of a proposed field in the
99 Kerberos response, namely a TicketExtension. This field is not
100 part of the encrypted part of the ticket (although it may have
101 been encrypted earlier), but it accompanies the ticket and should
102 be passed along by unaware clients with the rest of the ticket in
103 an opaque fashion. Using this field allows us to achieve the
104 following objectives:
106 * Avoid modification of clients and application servers.
108 * Allow remote KDC to control its policy on cross-realm
109 keys shared between KDCs, and on cross-realm tickets
110 presented by clients.
112 * Remove any need for KDCs to maintain state about keys
113 shared with other KDCs.
115 * Leverage work already done for PKINIT.
118 3.1. Overview of Protocol Changes
120 The basic operation of the revised PKCROSS protocol is as follows:
122 1. The client submits a request to the local KDC for
123 credentials for the remote realm.
125 2. The local KDC submits a PKINIT request to the remote
126 KDC. This request has a flag set to indicate that
127 the request is a special cross-realm key request.
129 3. The remote KDC responds as per PKINIT, except that
130 the ticket contains a TicketExtension which indicates
131 that this is a cross-realm key response. The
132 TicketExtension may also contain policy information,
133 which the local KDC must reflect in the credentials
134 it forwards to the client. Call this ticket TGT_{L,R}.
136 4. The local KDC passes a ticket, TGT_{C,R}, to the client.
137 This ticket contains in its TicketExtension field the
138 cross-realm key ticket, TGT_{L,R}. This ticket is
139 encrypted using the key sealed in TGT_{L,R}. (The
140 TicketExtension field is not encrypted.) The local KDC
141 may optionally include another TicketExtension type that
142 indicates the hostname and/or IP address for the remote KDC.
144 5. The client submits the request directly to the remote
145 KDC, as before.
147 Sections 3.2 through 3.4 describe in detail steps 2 through 4
148 above. Section 3.5 describes the conditions under which steps
149 2 and 3 may be skipped.
152 3.2. Local KDC's PKINIT Request to Remote KDC
154 When the local KDC receives a request for cross-realm
155 authentication, it sends a request to the remote KDC for a
156 ticket, denoted by TGT_{L,R}. This request is in fact a PKINIT
157 request as described in Section 3.2 of the PKINIT draft; i.e.,
158 it consists of an AS-REQ, with a PA-PK-AS-REQ included as a
159 preauthentication field.
161 In addition, the local KDC indicates that this request is for
162 a PKCROSS cross-realm key, by setting bit 9 in the kdc-options
163 field of the AS-REQ. We propose to call this bit the PKCROSSKEY
164 flag. Otherwise, this exchange exactly follows the description
165 given by Section 3.2 of the PKINIT draft.
168 3.3. Remote KDC's PKINIT Response to Local KDC
170 When the remote KDC receives the PKINIT/CROSS request from the
171 local KDC, it sends back a PKINIT response as described in
172 Section 3.2 of the PKINIT draft, with the following changes:
173 The remote KDC does not encrypt the encryptedTktPart with a
174 random key, as described in the PKINIT draft, but instead encrypts
175 it with a special symmetric key it uses for validating PKCROSS
176 requests. This key, instead of a random key, is then placed in an
177 envelope as described in the PKINIT draft.
179 In addition, a TicketExtension field of type 2 (TE-TYPE-PKCROSS) is
180 included with the ticket (as a non-encrypted part):
182 TicketExtension ::= SEQUENCE OF SEQUENCE {
183 te-type[0] INTEGER,
184 te-data[1] OCTET STRING
185 } -- per the revised Kerberos specification
187 where
188 te-type equals 2 for TE-TYPE-PKCROSS-KDC
189 and
190 te-data is ASN.1 encoding of CrossRealmTktData.
193 CrossRealmTktData ::= SEQUENCE OF SEQUENCE {
194 type [0] INTEGER,
195 data [1] OCTET STRING
196 }
198 where types and the corresponding data are to be interpreted as
199 follows:
201 type interpretation data is ASN.1 encoding of
202 ---- -------------- -------------------------
203 1 lifetime (in seconds) INTEGER
205 Further types may be added to this table.
208 3.4. Local KDC's Response to Client
210 Upon receipt of the PKINIT/CROSS response from the remote KDC,
211 the local KDC formulates a response to the client. This reply
212 is constructed exactly as in the Kerberos specification, except
213 for the following:
214 * The local KDC places TGT_{L,R} in the TicketExtension field of
215 the client's ticket for the remote realm (denoted here by
216 TGT_{C,R}).
217 * The local KDC adds the name of its CA to the transited field of
218 TGT_(C,R).
220 TicketExtension ::= SEQUENCE OF SEQUENCE {
221 te-type[0] INTEGER,
222 te-data[1] OCTET STRING
223 } -- per the revised Kerberos specification
225 where
226 te-type equals 3 for TE-TYPE-PKCROSS-CLIENT
227 and
228 te-data is ASN.1 encoding of TGT_(L,R).
230 Optionally, the local KDC may add another TicketExtention where
231 te-type equals 5 for TE-TYPE-DEST-HOST
232 and
233 te-data is ASN.1 encoding of DestHost.
234 A client could then rely on the local KDC to provide a referral to
235 the remote KDC, thus removing the need for the client to maintain
236 local host/realm mapping information.
238 DestHost ::= SEQUENCE {
239 DNSHostname [0] OCTET STRING,
240 -- authoritative DNS hostname
241 HostAddr [1] HostAddress OPTIONAL
242 -- as defined by RFC 1510
243 }
246 3.5. Short-Circuiting the KDC-to-KDC Exchange
248 Under certain circumstances, the KDC-to-KDC exchange described
249 in Sections 3.2 and 3.3 may be skipped. The local KDC has a
250 known lifetime for TGT_{C,R} (which may in part be determined by
251 the policy sent along with TGT_{L,R}). If the local KDC already
252 has a ticket TGT_{L,R}, and the start time plus the lifetime for
253 TGT_{C,R} does not exceed the expiration time for TGT_{L,R}, then
254 the local KDC may skip the exchange with the remote KDC, and
255 issue a cross-realm ticket to the client as described in Section
256 3.4.
258 Since the remote KDC may change the special cross-realm symmetric
259 key (referred to in Section 3.2) while there are cross-realm key
260 tickets (the TGT_{L,R}) still active, it is obligated to cache
261 those tickets until they expire.
264 4. Transport Issues
266 Because the messages between the KDCs involve PKINIT exchanges,
267 and PKINIT recommends TCP as a transport mechanism (due to the
268 length of the messages and the likelihood that they will fragment),
269 the same recommendation for TCP applies to PKCROSS as well.
272 5. Expiration Date
274 This Internet-Draft will expire on May 26, 1998.
277 6. Authors' Addresses
279 Brian Tung
280 Tatyana Ryutov
281 Clifford Neuman
282 Gene Tsudik
283 USC/Information Sciences Institute
284 4676 Admiralty Way Suite 1001
285 Marina del Rey, CA 90292-6695
286 Phone: +1 310 822 1511
287 E-Mail: {brian, tryutov, bcn, gts}@isi.edu
289 Bill Sommerfeld
290 Hewlett Packard
291 300 Apollo Drive
292 Chelmsford MA 01824
293 Phone: +1 508 436 4352
294 E-Mail: sommerfeld@apollo.hp.com
296 Ari Medvinsky
297 Matthew Hur
298 CyberSafe Corporation
299 1605 NW Sammamish Road Suite 310
300 Issaquah WA 98027-5378
301 Phone: +1 206 391 6000
302 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com