4
Network Working Group S. Josefsson
6
Intended status: Standards Track October 21, 2006
7
Expires: April 24, 2007
10
Using Kerberos V5 over the Transport Layer Security (TLS) protocol
11
draft-josefsson-kerberos5-starttls-02
15
By submitting this Internet-Draft, each author represents that any
16
applicable patent or other IPR claims of which he or she is aware
17
have been or will be disclosed, and any of which he or she becomes
18
aware will be disclosed, in accordance with Section 6 of BCP 79.
20
Internet-Drafts are working documents of the Internet Engineering
21
Task Force (IETF), its areas, and its working groups. Note that
22
other groups may also distribute working documents as Internet-
25
Internet-Drafts are draft documents valid for a maximum of six months
26
and may be updated, replaced, or obsoleted by other documents at any
27
time. It is inappropriate to use Internet-Drafts as reference
28
material or to cite them other than as "work in progress."
30
The list of current Internet-Drafts can be accessed at
31
http://www.ietf.org/ietf/1id-abstracts.txt.
33
The list of Internet-Draft Shadow Directories can be accessed at
34
http://www.ietf.org/shadow.html.
36
This Internet-Draft will expire on April 24, 2007.
40
Copyright (C) The Internet Society (2006).
55
Josefsson Expires April 24, 2007 [Page 1]
57
Internet-Draft Protecting Kerberos V5 with TLS October 2006
62
This document specify how the Kerberos V5 protocol can be transported
63
over the Transport Layer Security (TLS) protocol, to provide
64
additional security features.
69
1. Introduction and Background . . . . . . . . . . . . . . . . . 3
70
2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 5
71
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
72
4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 7
73
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
74
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
75
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
76
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
77
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
78
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
79
Intellectual Property and Copyright Statements . . . . . . . . . . 12
111
Josefsson Expires April 24, 2007 [Page 2]
113
Internet-Draft Protecting Kerberos V5 with TLS October 2006
116
1. Introduction and Background
118
This document describe how a Kerberos V5 [2] implementation may
119
upgrade communication between clients and Key Distribution Centers
120
(KDCs) to use the Transport Layer Security (TLS) [4] protocol.
122
The TLS protocol offer integrity and privacy protected exchanges that
123
can be authentication using X.509 certificates, OpenPGP keys [7], and
124
user name and passwords via SRP [6].
126
There are several reasons to use Kerberos V5 over TLS.
128
o Prevents downgrade attacks affecting, e.g., encryption types and
129
pre-auth data negotiation. The encryption type field in KDC-REQ,
130
and the METHOD-DATA field with the requested pre-auth types from
131
the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent
132
without integrity or privacy protection in Kerberos 5. This
133
allows an attacker to replace the encryption type with a
134
compromised encryption type, e.g., 56-bit DES, or request that
135
clients should use a broken pre-auth type. Since clients in
136
general cannot know the encryption types other servers support, or
137
the pre-auth types servers prefer or require, it is difficult for
138
the client to detect if there was a man-in-the-middle or if the
139
remote server simply did not support a stronger encryption type or
140
preferred another pre-auth type.
143
o Kerberos exchanges are privacy protected. Part of many Kerberos
144
packets are transfered without privacy protection (i.e.,
145
encryption). That part contains information, such as the client
146
principal name, the server principal name, the encryption types
147
supported by the client, the lifetime of tickets, etc. Revealing
148
such information is, in some threat models, considered a problem.
151
o Additional authentication against the KDC. In some situations,
152
users are equipped with smart cards with a RSA authentication key.
153
In others, users have a OpenPGP client on their desktop, with a
154
public OpenPGP key known to the server.
156
o The TLS protocol has been studied by many parties. In some threat
157
models, the designer prefer to reduce the number of protocols that
158
can hurt the overall system security if they are compromised.
161
o Explicit server authentication of the KDC to the client. In
162
traditional Kerberos 5, authentication of the KDC is proved as a
163
side effect that the KDC knows your encryption key (i.e., your
167
Josefsson Expires April 24, 2007 [Page 3]
169
Internet-Draft Protecting Kerberos V5 with TLS October 2006
174
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
175
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
176
document are to be interpreted as described in RFC 2119 [1].
223
Josefsson Expires April 24, 2007 [Page 4]
225
Internet-Draft Protecting Kerberos V5 with TLS October 2006
228
2. Kerberos V5 STARTTLS Extension
230
The STARTTLS extension uses the Kerberos V5 TCP extension mechanism
231
[3]. The extension uses bit #TBD in the extension bitmask.
233
The protocol is as follows. After the server has sent the 4-octet
234
value 0x00000000 to indicate support of this extension, the stream
235
will be controlled by the TLS protocol and its framing. The TLS
236
protocol is initiated by the client.
238
Typically, the client initiate the TLS handshake protocol by sending
239
a client hello, and the server responds, and the handshake continues
240
until it either succeed or fails.
242
If for any reason the handshake fails, the STARTTLS protocol will
243
also fail, and the TLS error is used as the error indication.
245
If the handshake succeeds, the Kerberos V5 authentication protocol is
246
performed within the protected TLS channel, like a normal TCP
247
Kerberos V5 exchange. In particular, this means that every Kerberos
248
V5 packet will be prefixed by a 4-octet length field, that indicate
249
the length of the Kerberos V5 packet.
279
Josefsson Expires April 24, 2007 [Page 5]
281
Internet-Draft Protecting Kerberos V5 with TLS October 2006
286
A complete packet flow for a successful AS-REQ/REP exchange protected
287
by this mechanism will be as follows. The "STARTTLS-bit" is a
288
4-octet value with only the bit allocated for this extension set.
292
[ Kerberos V5 TCP extension mechanism negotiation starts ]
294
[0x70000000 & STARTTLS-bit] -------->
298
[ TLS negotiation starts ]
301
ClientHello -------->
306
<-------- ServerHelloDone
315
[ Kerberos V5 negotiation starts ]
318
Kerberos V5 AS-REQ -------->
323
* Indicates optional or situation-dependent messages that are not
335
Josefsson Expires April 24, 2007 [Page 6]
337
Internet-Draft Protecting Kerberos V5 with TLS October 2006
340
4. STARTTLS aware KDC Discovery
342
Section 7.2.3 of Kerberos V5 [2] describe how Domain Name System
343
(DNS) SRV records [5] can be used to find the address of an KDC.
344
Using the terminology of Section 7.2.3 of RFC 4120, we define a new
345
Proto of "tls" to indicate that the particular KDC is intended to
346
support this STARTTLS extension. The Service, Realm, TTL, Class,
347
SRV, Priority, Weight, Port and Target have the same meaning as in
352
_kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
353
_kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
391
Josefsson Expires April 24, 2007 [Page 7]
393
Internet-Draft Protecting Kerberos V5 with TLS October 2006
396
5. IANA Considerations
398
The IANA is requested to allocate a bit in the "Kerberos TCP
399
Extensions" registry for the extension described in this document, as
447
Josefsson Expires April 24, 2007 [Page 8]
449
Internet-Draft Protecting Kerberos V5 with TLS October 2006
452
6. Security Considerations
454
The security considerations in Kerberos V5, TLS, and the extension
455
mechanism framework are inherited.
457
To protect against the inherent downgrade attack in the extension
458
framework, it is suggested that implementations offer a policy to
459
require that this extension is successfully negotiated. For
460
interoperability with implementations that do not support this
461
extension, it is suggested that the policy is disabled by default.
503
Josefsson Expires April 24, 2007 [Page 9]
505
Internet-Draft Protecting Kerberos V5 with TLS October 2006
510
7.1. Normative References
512
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
513
Levels", BCP 14, RFC 2119, March 1997.
515
[2] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
516
Network Authentication Service (V5)", RFC 4120, July 2005.
518
[3] Josefsson, S., "Extended Kerberos Version 5 Key Distribution
519
Center (KDC) Exchanges Over TCP",
520
draft-ietf-krb-wg-tcp-expansion-01 (work in progress),
523
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
524
Protocol Version 1.1", RFC 4346, April 2006.
526
[5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
527
specifying the location of services (DNS SRV)", RFC 2782,
530
7.2. Informative References
532
[6] Taylor, D., "Using SRP for TLS Authentication",
533
draft-ietf-tls-srp-12 (work in progress), June 2006.
535
[7] Mavroyanopoulos, N., "Using OpenPGP keys for TLS
536
authentication", draft-ietf-tls-openpgp-keys-10 (work in
537
progress), June 2006.
559
Josefsson Expires April 24, 2007 [Page 10]
561
Internet-Draft Protecting Kerberos V5 with TLS October 2006
569
Email: simon@josefsson.org
615
Josefsson Expires April 24, 2007 [Page 11]
617
Internet-Draft Protecting Kerberos V5 with TLS October 2006
620
Full Copyright Statement
622
Copyright (C) The Internet Society (2006).
624
This document is subject to the rights, licenses and restrictions
625
contained in BCP 78, and except as set forth therein, the authors
626
retain all their rights.
628
This document and the information contained herein are provided on an
629
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
630
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
631
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
632
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
633
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
634
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
637
Intellectual Property
639
The IETF takes no position regarding the validity or scope of any
640
Intellectual Property Rights or other rights that might be claimed to
641
pertain to the implementation or use of the technology described in
642
this document or the extent to which any license under such rights
643
might or might not be available; nor does it represent that it has
644
made any independent effort to identify any such rights. Information
645
on the procedures with respect to rights in RFC documents can be
646
found in BCP 78 and BCP 79.
648
Copies of IPR disclosures made to the IETF Secretariat and any
649
assurances of licenses to be made available, or the result of an
650
attempt made to obtain a general license or permission for the use of
651
such proprietary rights by implementers or users of this
652
specification can be obtained from the IETF on-line IPR repository at
653
http://www.ietf.org/ipr.
655
The IETF invites any interested party to bring to its attention any
656
copyrights, patents or patent applications, or other proprietary
657
rights that may cover technology that may be required to implement
658
this standard. Please address the information to the IETF at
664
Funding for the RFC Editor function is provided by the IETF
665
Administrative Support Activity (IASA).
671
Josefsson Expires April 24, 2007 [Page 12]
added
removed
doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt
