]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group A. Medvinsky | |
8 | Request for Comments: 2712 Excite | |
9 | Category: Standards Track M. Hur | |
10 | CyberSafe Corporation | |
11 | October 1999 | |
12 | ||
13 | ||
14 | Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) | |
15 | ||
16 | Status of this Memo | |
17 | ||
18 | This document specifies an Internet standards track protocol for the | |
19 | Internet community, and requests discussion and suggestions for | |
20 | improvements. Please refer to the current edition of the "Internet | |
21 | Official Protocol Standards" (STD 1) for the standardization state | |
22 | and status of this protocol. Distribution of this memo is unlimited. | |
23 | ||
24 | Copyright Notice | |
25 | ||
26 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
27 | ||
28 | IESG Note: | |
29 | ||
30 | The 40-bit ciphersuites defined in this memo are included only for | |
31 | the purpose of documenting the fact that those ciphersuite codes have | |
32 | already been assigned. 40-bit ciphersuites were designed to comply | |
33 | with US-centric, and now obsolete, export restrictions. They were | |
34 | never secure, and nowadays are inadequate even for casual | |
35 | applications. Implementation and use of the 40-bit ciphersuites | |
36 | defined in this document, and elsewhere, is strongly discouraged. | |
37 | ||
38 | 1. Abstract | |
39 | ||
40 | This document proposes the addition of new cipher suites to the TLS | |
41 | protocol [1] to support Kerberos-based authentication. Kerberos | |
42 | credentials are used to achieve mutual authentication and to | |
43 | establish a master secret which is subsequently used to secure | |
44 | client-server communication. | |
45 | ||
46 | 2. Introduction | |
47 | ||
48 | Flexibility is one of the main strengths of the TLS protocol. | |
49 | Clients and servers can negotiate cipher suites to meet specific | |
50 | security and administrative policies. However, to date, | |
51 | authentication in TLS is limited only to public key solutions. As a | |
52 | result, TLS does not fully support organizations with heterogeneous | |
53 | security deployments that include authentication systems based on | |
54 | symmetric cryptography. Kerberos, originally developed at MIT, is | |
55 | ||
56 | ||
57 | ||
58 | Medvinsky & Hur Standards Track [Page 1] | |
59 | \f | |
60 | RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999 | |
61 | ||
62 | ||
63 | based on an open standard [2] and is the most widely deployed | |
64 | symmetric key authentication system. This document proposes a new | |
65 | option for negotiating Kerberos authentication within the TLS | |
66 | framework. This achieves mutual authentication and the establishment | |
67 | of a master secret using Kerberos credentials. The proposed changes | |
68 | are minimal and, in fact, no different from adding a new public key | |
69 | algorithm to the TLS framework. | |
70 | ||
71 | 3. Kerberos Authentication Option In TLS | |
72 | ||
73 | This section describes the addition of the Kerberos authentication | |
74 | option to the TLS protocol. Throughout this document, we refer to | |
75 | the basic SSL handshake shown in Figure 1. For a review of the TLS | |
76 | handshake see [1]. | |
77 | ||
78 | CLIENT SERVER | |
79 | ------ ------ | |
80 | ClientHello | |
81 | --------------------------------> | |
82 | ServerHello | |
83 | Certificate * | |
84 | ServerKeyExchange* | |
85 | CertificateRequest* | |
86 | ServerHelloDone | |
87 | <------------------------------- | |
88 | Certificate* | |
89 | ClientKeyExchange | |
90 | CertificateVerify* | |
91 | change cipher spec | |
92 | Finished | |
93 | | --------------------------------> | |
94 | | change cipher spec | |
95 | | Finished | |
96 | | | | |
97 | | | | |
98 | Application Data <------------------------------->Application Data | |
99 | ||
100 | FIGURE 1: The TLS protocol. All messages followed by a star are | |
101 | optional. Note: This figure was taken from an IETF document | |
102 | [1]. | |
103 | ||
104 | The TLS security context is negotiated in the client and server hello | |
105 | messages. For example: TLS_RSA_WITH_RC4_MD5 means the initial | |
106 | authentication will be done using the RSA public key algorithm, RC4 | |
107 | will be used for the session key, and MACs will be based on the MD5 | |
108 | algorithm. Thus, to facilitate the Kerberos authentication option, | |
109 | we must start by defining new cipher suites including (but not | |
110 | limited to): | |
111 | ||
112 | ||
113 | ||
114 | Medvinsky & Hur Standards Track [Page 2] | |
115 | \f | |
116 | RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999 | |
117 | ||
118 | ||
119 | CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }; | |
120 | CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F }; | |
121 | CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 }; | |
122 | CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 }; | |
123 | CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 }; | |
124 | CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 }; | |
125 | CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 }; | |
126 | CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 }; | |
127 | ||
128 | CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 }; | |
129 | CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 }; | |
130 | CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 }; | |
131 | CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 }; | |
132 | CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A }; | |
133 | CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B }; | |
134 | ||
135 | To establish a Kerberos-based security context, one or more of the | |
136 | above cipher suites must be specified in the client hello message. | |
137 | If the TLS server supports the Kerberos authentication option, the | |
138 | server hello message, sent to the client, will confirm the Kerberos | |
139 | cipher suite selected by the server. The server's certificate, the | |
140 | client | |
141 | ||
142 | CertificateRequest, and the ServerKeyExchange shown in Figure 1 will | |
143 | be omitted since authentication and the establishment of a master | |
144 | secret will be done using the client's Kerberos credentials for the | |
145 | TLS server. The client's certificate will be omitted for the same | |
146 | reason. Note that these messages are specified as optional in the | |
147 | TLS protocol; therefore, omitting them is permissible. | |
148 | ||
149 | The Kerberos option must be added to the ClientKeyExchange message as | |
150 | shown in Figure 2. | |
151 | ||
152 | ||
153 | ||
154 | ||
155 | ||
156 | ||
157 | ||
158 | ||
159 | ||
160 | ||
161 | ||
162 | ||
163 | ||
164 | ||
165 | ||
166 | ||
167 | ||
168 | ||
169 | ||
170 | Medvinsky & Hur Standards Track [Page 3] | |
171 | \f | |
172 | RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999 | |
173 | ||
174 | ||
175 | struct | |
176 | { | |
177 | select (KeyExchangeAlgorithm) | |
178 | { | |
179 | case krb5: KerberosWrapper; /* new addition */ | |
180 | case rsa: EncryptedPreMasterSecret; | |
181 | case diffie_hellman: ClientDiffieHellmanPublic; | |
182 | } Exchange_keys; | |
183 | ||
184 | } ClientKeyExchange; | |
185 | ||
186 | struct | |
187 | { | |
188 | opaque Ticket; | |
189 | opaque authenticator; /* optional */ | |
190 | opaque EncryptedPreMasterSecret; /* encrypted with the session key | |
191 | which is sealed in the ticket */ | |
192 | } KerberosWrapper; /* new addition */ | |
193 | ||
194 | FIGURE 2: The Kerberos option in the ClientKeyExchange. | |
195 | ||
196 | To use the Kerberos authentication option, the TLS client must obtain | |
197 | a service ticket for the TLS server. In TLS, the ClientKeyExchange | |
198 | message is used to pass a random 48-byte pre-master secret to the | |
199 | server. | |
200 | ||
201 | The client and server then use the pre-master secret to independently | |
202 | derive the master secret, which in turn is used for generating | |
203 | session keys and for MAC computations. Thus, if the Kerberos option | |
204 | is selected, the pre-master secret structure is the same as that used | |
205 | in the RSA case; it is encrypted under the Kerberos session key and | |
206 | sent to the TLS server along with the Kerberos credentials (see | |
207 | Figure 2). The ticket and authenticator are encoded per RFC 1510 | |
208 | (ASN.1 encoding). Once the ClientKeyExchange message is received, | |
209 | the server's secret key is used to unwrap the credentials and extract | |
210 | the pre-master secret. | |
211 | ||
212 | Note that a Kerberos authenticator is not required, since the master | |
213 | secret derived by the client and server is seeded with a random value | |
214 | passed in the server hello message, thus foiling replay attacks. | |
215 | However, the authenticator may still prove useful for passing | |
216 | authorization information and is thus allotted an optional field (see | |
217 | Figure 2). | |
218 | ||
219 | Lastly, the client and server exchange the finished messages to | |
220 | complete the handshake. At this point we have achieved the | |
221 | following: | |
222 | ||
223 | ||
224 | ||
225 | ||
226 | Medvinsky & Hur Standards Track [Page 4] | |
227 | \f | |
228 | RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999 | |
229 | ||
230 | ||
231 | 1) A master secret, used to protect all subsequent communication, is | |
232 | securely established. | |
233 | ||
234 | 2) Mutual client-server authentication is achieved, since the TLS | |
235 | server proves knowledge of the master secret in the finished | |
236 | message. | |
237 | ||
238 | Note that the Kerberos option fits in seamlessly, without adding any | |
239 | new messages. | |
240 | ||
241 | 4. Naming Conventions: | |
242 | ||
243 | To obtain an appropriate service ticket, the TLS client must | |
244 | determine the principal name of the TLS server. The Kerberos service | |
245 | naming convention is used for this purpose, as follows: | |
246 | ||
247 | host/MachineName@Realm | |
248 | where: | |
249 | - The literal, "host", follows the Kerberos convention when not | |
250 | concerned about the protection domain on a particular machine. | |
251 | - "MachineName" is the particular instance of the service. | |
252 | - The Kerberos "Realm" is the domain name of the machine. | |
253 | ||
254 | 5. Summary | |
255 | ||
256 | The proposed Kerberos authentication option is added in exactly the | |
257 | same manner as a new public key algorithm would be added to TLS. | |
258 | Furthermore, it establishes the master secret in exactly the same | |
259 | manner. | |
260 | ||
261 | 6. Security Considerations | |
262 | ||
263 | Kerberos ciphersuites are subject to the same security considerations | |
264 | as the TLS protocol. In addition, just as a public key | |
265 | implementation must take care to protect the private key (for example | |
266 | the PIN for a smartcard), a Kerberos implementation must take care to | |
267 | protect the long lived secret that is shared between the principal | |
268 | and the KDC. In particular, a weak password may be subject to a | |
269 | dictionary attack. In order to strengthen the initial authentication | |
270 | to a KDC, an implementor may choose to utilize secondary | |
271 | authentication via a token card, or one may utilize initial | |
272 | authentication to the KDC based on public key cryptography (commonly | |
273 | known as PKINIT - a product of the Common Authentication Technology | |
274 | working group of the IETF). | |
275 | ||
276 | ||
277 | ||
278 | ||
279 | ||
280 | ||
281 | ||
282 | Medvinsky & Hur Standards Track [Page 5] | |
283 | \f | |
284 | RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999 | |
285 | ||
286 | ||
287 | 7. Acknowledgements | |
288 | ||
289 | We would like to thank Clifford Neuman for his invaluable comments on | |
290 | earlier versions of this document. | |
291 | ||
292 | 8. References | |
293 | ||
294 | [1] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC | |
295 | 2246, January 1999. | |
296 | ||
297 | [2] Kohl J. and C. Neuman, "The Kerberos Network Authentication | |
298 | Service (V5)", RFC 1510, September 1993. | |
299 | ||
300 | 9. Authors' Addresses | |
301 | ||
302 | Ari Medvinsky | |
303 | Excite | |
304 | 555 Broadway | |
305 | Redwood City, CA 94063 | |
306 | ||
307 | Phone: +1 650 569 2119 | |
308 | EMail: amedvins@excitecorp.com | |
309 | http://www.excite.com | |
310 | ||
311 | ||
312 | Matthew Hur | |
313 | CyberSafe Corporation | |
314 | 1605 NW Sammamish Road | |
315 | Issaquah WA 98027-5378 | |
316 | ||
317 | Phone: +1 425 391 6000 | |
318 | EMail: matt.hur@cybersafe.com | |
319 | http://www.cybersafe.com | |
320 | ||
321 | ||
322 | ||
323 | ||
324 | ||
325 | ||
326 | ||
327 | ||
328 | ||
329 | ||
330 | ||
331 | ||
332 | ||
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | Medvinsky & Hur Standards Track [Page 6] | |
339 | \f | |
340 | RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999 | |
341 | ||
342 | ||
343 | 10. Full Copyright Statement | |
344 | ||
345 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
346 | ||
347 | This document and translations of it may be copied and furnished to | |
348 | others, and derivative works that comment on or otherwise explain it | |
349 | or assist in its implementation may be prepared, copied, published | |
350 | and distributed, in whole or in part, without restriction of any | |
351 | kind, provided that the above copyright notice and this paragraph are | |
352 | included on all such copies and derivative works. However, this | |
353 | document itself may not be modified in any way, such as by removing | |
354 | the copyright notice or references to the Internet Society or other | |
355 | Internet organizations, except as needed for the purpose of | |
356 | developing Internet standards in which case the procedures for | |
357 | copyrights defined in the Internet Standards process must be | |
358 | followed, or as required to translate it into languages other than | |
359 | English. | |
360 | ||
361 | The limited permissions granted above are perpetual and will not be | |
362 | revoked by the Internet Society or its successors or assigns. | |
363 | ||
364 | This document and the information contained herein is provided on an | |
365 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
366 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
367 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
368 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
369 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
370 | ||
371 | Acknowledgement | |
372 | ||
373 | Funding for the RFC Editor function is currently provided by the | |
374 | Internet Society. | |
375 | ||
376 | ||
377 | ||
378 | ||
379 | ||
380 | ||
381 | ||
382 | ||
383 | ||
384 | ||
385 | ||
386 | ||
387 | ||
388 | ||
389 | ||
390 | ||
391 | ||
392 | ||
393 | ||
394 | Medvinsky & Hur Standards Track [Page 7] | |
395 | \f |