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