| blob | 35cc348b8b6c35ec63fa196d3778f016e3fd0f83 |
5 INTERNET-DRAFT Matthew Hur
6 Transport Layer Security Working Group Joseph Salowey
7 draft-ietf-tls-kerb-01.txt Cisco Systems
8 Obsoletes: RFC 2712 Ari Medvinsky
9 November 8, 2001 (Expires May 8, 2001) Liberate
14 Kerberos Cipher Suites in Transport Layer Security (TLS)
19 0. Status Of this Memo
21 This document is an Internet-Draft and is in full conformance with
22 all provisions of Section 10 of RFC 2026. Internet-Drafts are
23 working documents of the Internet Engineering Task Force (IETF), its
24 areas, and its working groups. Note that other groups may also
25 distribute working documents as Internet-Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet- Drafts as reference
30 material or to cite them other than as ``work in progress.''
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/1id-abstracts.html
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html
41 1. Abstract
43 RFC 2712 [KERBTLS] introduced mechanisms for supporting Kerberos
44 [KERB] authentication within the TLS protocol [TLS]. This document
45 extends RFC 2712 to support delegation of Kerberos credentials. In
46 this way, a TLS server may obtain a Kerberos service ticket on behalf
47 of the TLS client. Thus, a single client identity may be used for
48 authentication within a multi-tier architecture. This draft also
49 proposes a mechanism for a TLS server to indicate Kerberos-specific
50 information to the client within the certificate request message in
51 the initial exchange.
54 2. Introduction
56 Flexibility is one of the main strengths of the TLS protocol. Clients
57 and servers can negotiate cipher suites to meet specific security and
58 administrative policies. RFC 2712 specified how TLS could be
59 extended to support organizations with heterogeneous security
60 deployments that include authentication systems based on symmetric
61 cryptography. Kerberos, originally developed at MIT, is based on an
62 open standard and is the most widely deployed symmetric key
63 authentication system. Just as other documents specify hybrid
64 asymmetric/symmetric key protocols [PKINIT] [PKCROSS] [PKTAPP], this
65 document specifies how TLS may incorporate both symmetric and
66 asymmetric key crypto systems.
68 This document describes the use of Kerberos authentication within
69 the TLS framework. This achieves mutual authentication and the
70 establishment of a master secret using Kerberos credentials.
71 Additionally, this document specifies support for delegation of
72 Kerberos credentials, which enables end to end authentication within
73 an n-tier architecture. The proposed changes are minimal and, in
74 fact, no different from adding a new public key algorithm to the TLS
75 framework.
78 3. Kerberos Authentication Option In TLS
80 This section describes the addition of the Kerberos authentication
81 option to the TLS protocol. Throughout this document, we refer to
82 the basic SSL handshake shown in Figure 1. For a review of the TLS
83 handshake see [TLS].
85 +-------------------------------------------------------------------+
86 | CLIENT SERVER |
87 | ------ ------ |
88 | ClientHello |
89 | ---------------------------> |
90 | ServerHello |
91 | Certificate * |
92 | ServerKeyExchange* |
93 | CertificateRequest* |
94 | ServerHelloDone |
95 | <--------------------------- |
96 | Certificate* |
97 | ClientKeyExchange |
98 | CertificateVerify* |
99 | change cipher spec |
100 | Finished |
101 | | ---------------------------> |
102 | | change cipher spec |
103 | | Finished |
104 | | | |
105 | | | |
106 | Application Data <--------------------------> Application Data |
107 +-------------------------------------------------------------------+
108 FIGURE 1: The TLS protocol. All messages followed by a star are
109 optional. Note: This figure was taken from RFC 2246.
111 The TLS security context is negotiated in the client and server hello
112 messages. For example: TLS_RSA_WITH_RC4_128_MD5 means the initial
113 authentication will be done using the RSA public key algorithm, RC4
114 will be used with a 128 bit session key, and MACs will be based on
115 the MD5 algorithm. Thus, to facilitate the Kerberos authentication
116 option, we must start by defining Kerberos cipher suites including
117 (but not limited to):
119 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x70 };
120 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x71 };
121 CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x72 };
122 CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x73 };
123 CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x74 };
124 CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x75 };
125 CipherSuite TLS_KRB5_WITH_AES_128_CBC_SHA = { 0x00,0x76 };
126 CipherSuite TLS_KRB5_WITH_AES_256_CBC_SHA = { 0x00,0x77 };
127 CipherSuite TLS_KRB5_WITH_NULL_SHA = { 0x00,0x78 };
128 CipherSuite TLS_KRB5_WITH_NULL_MD5 = { 0x00,0x79 };
130 To establish a Kerberos-based security context, one or more of the
131 above cipher suites must be specified in the client hello message. If
132 the TLS server supports the Kerberos authentication option, the
133 server hello message, sent to the client, will confirm the Kerberos
134 cipher suite selected by the server. The server's certificate and
135 the ServerKeyExchange shown in Figure 1 will be omitted since
136 authentication and the establishment of a master secret will be done
137 using the client's Kerberos credentials for the TLS server. Note
138 that these messages are specified as optional in the TLS protocol;
139 therefore, omitting them is permissible.
141 The Kerberos option affects three of the TLS messages: the
142 CertificateRequest, the client Certificate, and the
143 ClientKeyExchange. However, only the client Certificate and the
144 ClientKeyExchange are required.
147 3.1. Usage of the CertificateRequest Message
149 If the server accepts a Kerberos-based ciphersuite, then it MUST send
150 the CertificateRequest message to the client. This message conveys
151 Kerberos-specific characteristics such as realm name or attributes
152 such as forwarded ticket.
154 RFC 2246 defines the CertificateRequest message as follows:
155 +-------------------------------------------------------------------+
156 | |
157 | enum { |
158 | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), |
159 | (255) |
160 | } ClientCertificateType; |
161 | |
162 | opaque DistinguishedName<1..2^16-1>; |
163 | |
164 | struct { ClientCertificateType certificate_types<1..2^8-1>; |
165 | DistinguishedName certificate_authorities<3..2^16-1>; |
166 | } CertificateRequest; |
167 | |
168 +-------------------------------------------------------------------+
169 FIGURE 2: CertificateRequest message from RFC 2246
171 This specification defines a new ClientCertificateType for a Kerberos
172 certificate. This enables a client to respond to the
173 CertificateRequest message when using Kerberos ciphersuites. The
174 Kerberos ClientCertificateType MUST NOT be included in
175 certificate_types for non-Kerberos ciphersuites. Thus the following
176 change for ClientCertificateType is required (Figure 3).
178 +-------------------------------------------------------------------+
179 | |
180 | enum { |
181 | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), |
182 | kerberos(5), (255) |
183 | } ClientCertificateType; |
184 | |
185 +-------------------------------------------------------------------+
186 FIGURE 3: New Kerberos ClientCertificateType
188 In the case of a public key based authentication algorithm, the
189 opaque DistinguishedName field is derived from [X509], and it
190 contains the name of an acceptable certification authority (This is
191 as specified in [TLS]). In the case of a Kerberos
192 ClientCertificateType, the DistinguishedName field is defined to
193 represent Kerberos information (KerbInfo) as shown in Figure 4. The
194 srv_tgt attribute type is used by the server to send a TGT that the
195 client presents to the KDC in the case of user-to-user
196 authentication. The KDC uses the session key from this ticket to
197 encrypt a service ticket for the server. In this case the attr_data
198 must be of non-zero length and contain the server's TGT.
200 +-------------------------------------------------------------------+
201 | |
202 | enum |
203 | { |
204 | srv_tkt(1), fwd_tgt(2), (255) |
205 | } KerbInfoType; |
206 | |
207 | enum |
208 | { |
209 | initial_tkt_required(1), srv_tgt(2), (255) |
210 | } AttrType; /* This may be extended to include attributes */ |
211 | /* such as forwardable or renewable for example */ |
212 | |
213 | struct |
214 | { |
215 | AttrType attr_type; |
216 | opaque attr_data <0..2^16-1>; |
217 | } AttrInfoType |
218 | |
219 | struct |
220 | { |
221 | uint32 length; /* length of this struct */ |
222 | KerbInfoType type; |
223 | opaque sname <0..2^16-1>; |
224 | opaque srealm <0..2^16-1>; |
225 | opaque cname <0..2^16-1>; |
226 | opaque crealm <0..2^16-1>; |
227 | AttrInfoType attr_info <0..2^16-1>; /* sequence of */ |
228 | /* attributes */ |
229 | uint32 etypes <0..2^16-1>; /* list of supported */ |
230 | /* Kerberos etypes */ |
231 | /* for authentication */ |
232 | } TktInfo; |
233 | |
234 | struct |
235 | { |
236 | TktInfo tkt_info <1..2^20-1>; /* MUST have at least */ |
237 | /* 1 TktInfo structs */ |
238 | } KerbInfo |
239 | |
240 +-------------------------------------------------------------------+
241 FIGURE 4: Kerberos Information for CertificateRequest Message
244 3.2. Usage of the Client Certificate Message
246 As specified by [TLS], when the client receives the
247 CertificateRequest message, it MUST respond with the client
248 Certificate message. As stated above, this specification defines a
249 Kerberos certificate type. The format for the Kerberos certificate
250 is specified in figure 5 below. This structure consists of a
251 Kerberos AP-REQ message that is used for authenticating the client to
252 he server. It optionally contains a series of Kerberos KRB-CRED
253 messages to convey delegated credentials.
255 Note that the client may determine the type of credentials to send to
256 the server, based on local policy. Part of the input to a client's
257 decision may come from the Kerberos KDC. For example, The client may
258 convey a delegated ticket based on the ok-as-delegate ticket flag set
259 in the service ticket. Also, the session key used to protect a
260 forwarded credential, MUST be of equal or greater strength than the
261 key used to protect the ticket when originally sent to the client
262 (typically, this key is the client principal key, shared with the
263 Kerberos KDC).
265 +-------------------------------------------------------------------+
266 | |
267 | opaque KrbCred <1..2^16-1>; /* Kerberos-defined KRB-CRED */ |
268 | |
269 | struct |
270 | { |
271 | opaque ap_req <1..2^16-1>; |
272 | KrbCred krb_cred <0..2^20-1>; |
273 | } KerberosCert; |
274 | |
275 +-------------------------------------------------------------------+
276 FIGURE 5: Kerberos Certificate Type
279 3.3. Usage of the ClientKeyExchange Message
282 The Kerberos option must be added to the ClientKeyExchange message as
283 shown in Figure 6.
285 +-------------------------------------------------------------------+
286 | |
287 | struct |
288 | { |
289 | select (KeyExchangeAlgorithm) |
290 | { |
291 | case krb: KerbEncryptedPreMasterSecret; |
292 | case rsa: EncryptedPreMasterSecret; |
293 | case diffie_hellman: ClientDiffieHellmanPublic; |
294 | } Exchange_keys; |
295 | } ClientKeyExchange; |
296 | |
297 | KerbEncryptedPreMasterSecret contains the PreMasterSecret |
298 | encrypted within a Kerberos-defined EncryptedData structure. |
299 | The encryption key is sealed in the ticket sent in the Client |
300 | Certificate message. |
301 | |
302 +-------------------------------------------------------------------+
303 FIGURE 6: The Kerberos option in the ClientKeyExchange.
305 To use the Kerberos authentication option, the TLS client must obtain
306 a service ticket for the TLS server. In TLS, the ClientKeyExchange
307 message is used to pass a random 48-byte pre-master secret to the
308 server.
310 The client and server then use the pre-master secret to independently
311 derive the master secret, which in turn is used for generating
312 session keys and for MAC computations. Thus, if the Kerberos option
313 is selected, the pre-master secret structure is the same as that used
314 in the RSA case; it is encrypted under the Kerberos session key and
315 sent to the TLS server along with the Kerberos credentials (see
316 Figure 2). The ticket and authenticator are encoded per RFC 1510
317 (ASN.1 encoding). Once the ClientKeyExchange message is received,
318 the server's secret key is used to unwrap the credentials and extract
319 the pre-master secret.
321 Lastly, the client and server exchange the finished messages to
322 complete the handshake. At this point we have achieved the
323 following:
325 1) A master secret, used to protect all subsequent communication, is
326 securely established.
328 2) Mutual client-server authentication is achieved, since the TLS
329 server proves knowledge of the master secret in the finished
330 message.
332 Kerberos fits seamlessly into TLS, without adding any new messages.
335 4. Naming Conventions:
337 To obtain an appropriate service ticket, the TLS client must
338 determine the principal name of the TLS server. The Kerberos service
339 naming convention is as follows:
341 host/MachineName@Realm
342 where:
343 - The literal, "host", follows the Kerberos convention when not
344 concerned about the protection domain on a particular machine.
345 - "MachineName" is the particular instance of the service.
346 - The Kerberos "Realm" is the domain name of the machine.
348 As specified above, in the CertificateRequest message, the server may
349 indicate the appropriate principal name and realm.
352 5. Summary
354 The proposed Kerberos authentication option is added in exactly the
355 same manner as a new public key algorithm would be added to TLS.
356 Furthermore, it establishes the master secret in exactly the same
357 manner.
360 6. Security Considerations
362 Kerberos ciphersuites are subject to the same security considerations
363 as the TLS protocol. In addition, just as a public key implementation
364 must take care to protect the private key (for example the PIN for a
365 smartcard), a Kerberos implementation must take care to protect the
366 long lived secret that is shared between the principal and the KDC.
367 In particular, a weak password may be subject to a dictionary attack.
368 In order to strengthen the initial authentication to a KDC, an
369 implementor may choose to utilize secondary authentication via a token
370 card, or one may utilize initial authentication to the KDC based on
371 public key cryptography (commonly known as PKINIT - a product of the
372 Kerberos working group of the IETF).
374 The unauthenticated CertificateRequest message, specified above,
375 enables the server to request a particular client principal name as
376 well as a particular service principal name. In the event that a
377 service principal name is specified, there is a risk that the client
378 may be tricked into requesting a ticket for a rogue server.
379 Furthermore, if delegation is requested, the client may be tricked
380 into forwarding its TGT to a rogue server. In order to assure that a
381 service ticket is obtained for the correct server, the client should
382 rely on a combination of its own local policy, local configuration
383 information, and information supplied by the KDC. The client may
384 choose to use only the naming convention specified in section 4. The
385 client may rely on the KDC performing name cannonicalization (this is
386 a matter that is adressed in revisions to RFC 1510).
388 The client must apply its local policy to determine whether or not to
389 forward its credentials. As previously stated, the client should
390 incorporate information from the KDC, in particular the ok-as-
391 delegate ticket flag, in making such a policy decision.
393 The forwarded credential MUST be protected in a key that is at least
394 the same strength as the principal key that originally protected the
395 TGT.
397 A forwarded TGT presents more vulnerabilities in the event of a rogue
398 server or the compromise of the session key. An attacker would be
399 able to impersonate the client to obtain new service tickets. Such
400 an attack may be mitigated by the use of restrictions, such as those
401 described in [Neuman].
403 It has been shown that 56-bit DES keys are relatively easy to
404 compromise [DESCRACK]; therefore, use of 56-bit DES is discouraged.
407 7. Acknowledgements
409 We would like to thank the following people for their input for this
410 document:
411 Clifford Neuma - ISI
412 John Brezak and David Mowers - Microsoft
416 8. References
418 [KERBTLS] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher
419 Suites to Transport Layer Security (TLS)", RFC 2712,
420 October 1999.
422 [KERB] J. Kohl and C. Neuman, "The Kerberos Network
423 Authentication Service (V5)", RFC 1510, September 1993.
425 [TLS] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0",
426 RFC 2246, January 1999.
428 [PKINIT] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky,
429 J. Wray, J. Trostle. Public Key Cryptography for Initial
430 Authentication in Kerberos.
431 draft-ietf-cat-kerberos-pk-init-14.txt
433 [PKTAPP] A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman.
434 Public Key Utilizing Tickets for Application
435 Servers (PKTAPP). draft-ietf-cat-kerberos-pk-tapp-03.txt
437 [PKCROSS] M. Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik,
438 A. Medvinsky, B. Sommerfeld. Public Key Cryptography for
439 Cross-Realm Authentication in Kerberos.
440 draft-ietf-cat-kerberos-pk-cross-07.txt
442 [X509] ITU-T (formerly CCITT) Information technology - Open
443 Systems Interconnection - The Directory: Authentication
444 Framework Recommendation X.509 ISO/IEC 9594-8
446 [NEUMAN] B.C. Neuman, "Proxy-Based Authorization and Accounting for
447 Distributed Systems". Proceedings of the 13th
448 International Conference on Distributed Computing Systems,
449 May 1993
451 [DESCRACK] Electronic Frontier Foundation, "Cracking DES: Secrets of
452 Encryption Research, Wiretap Politics, and Chip Design".
453 May 1998, Electronic Frontier Foundation.
456 9. Authors' Addresses
458 Matthew Hur
459 Cisco Systems
460 2901 Third Avenue
461 Seattle, WA 98121
462 Phone: +1 206 256 3197
463 EMail: mhur@cisco.com
464 http://www.cisco.com
466 Joseph Salowey
467 Cisco Systems
468 2901 Third Avenue
469 Seattle, WA 98121
470 Phone: +1 206 256 3380
471 EMail: jsalowey@cisco.com
472 http://www.cisco.com
474 Ari Medvinsky
475 Liberate
476 2 Circle Star Way
477 San Carlos, CA 94070-6200
478 Phone: +1 650 701 4000
479 EMail: ari@liberate.com
480 http://www.liberate.com
483 10. Full Copyright Statement
485 Copyright (C) The Internet Society (1999). All Rights Reserved.
487 This document and translations of it may be copied and furnished to
488 others, and derivative works that comment on or otherwise explain it
489 or assist in its implementation may be prepared, copied, published
490 and distributed, in whole or in part, without restriction of any
491 kind, provided that the above copyright notice and this paragraph are
492 included on all such copies and derivative works. However, this
493 document itself may not be modified in any way, such as by removing
494 the copyright notice or references to the Internet Society or other
495 Internet organizations, except as needed for the purpose of
496 developing Internet standards in which case the procedures for
497 copyrights defined in the Internet Standards process must be
498 followed, or as required to translate it into languages other than
499 English.
501 The limited permissions granted above are perpetual and will not be
502 revoked by the Internet Society or its successors or assigns.
504 This document and the information contained herein is provided on an
505 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
506 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
507 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
508 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
509 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
513 11. Appendix
515 Changes from RFC 2712
517 Added new cipher suites with NULL confidentiality:
518 TLS_KRB5_WITH_NULL_SHA
519 TLS_KRB5_WITH_NULL_MD5
521 Added new cipher suites to support AES:
522 TLS_KRB5_WITH_AES_128_CBC_SHA
523 TLS_KRB5_WITH_AES_256_CBC_SHA
525 40 bit ciphers have been removed, and AES ciphers have been added.
527 All of the ciphersuites have been renumbered to avoid conflicts with
528 exisiting implementations of RFC 2712.
530 RFC 2712 utilized only the ClientKeyExchange message for conveying
531 the Kerberos credentials and encrypted premaster-secret. This
532 specification moves the Kerberos credentials to the client
533 certificate message, and it allows the client to pass delegated
534 credentials as well. Additionally, this specification allows the
535 server to specify Kerberos-specific information (realm, delegation
536 required, etc.) in the CertificateRequest message.