1 Network Working Group S. Josefsson
2 Internet-Draft November 13, 2004
6 Using Transport Layer Security (TLS) with Kerberos 5
7 draft-josefsson-kerberos5-starttls-00
11 This document is an Internet-Draft and is subject to all provisions
12 of section 3 of RFC 3667. By submitting this Internet-Draft, each
13 author represents that any applicable patent or other IPR claims of
14 which he or she is aware have been or will be disclosed, and any of
15 which he or she become aware will be disclosed, in accordance with
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on May 14, 2005.
38 Copyright (C) The Internet Society (2004).
42 This document specify how the Transport Layer Security (TLS) protocol
43 is used in conjunction with the Kerberos 5 protocol.
53 Josefsson Expires May 14, 2005 [Page 1]
55 Internet-Draft Using TLS with Kerberos 5 November 2004
60 1. Introduction and Background . . . . . . . . . . . . . . . . . 3
61 2. Extension Mechanism for TCP/IP transport . . . . . . . . . . . 4
62 3. Kerberos 5 STARTTLS Extension . . . . . . . . . . . . . . . . 4
63 3.1 STARTTLS requested by client (extension 1) . . . . . . . . 4
64 3.2 STARTTLS request accepted by server (extension 2) . . . . 5
65 3.3 Proceeding after successful TLS negotiation . . . . . . . 5
66 3.4 Proceeding after failed TLS negotiation . . . . . . . . . 5
67 3.5 STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . 5
68 3.6 Initial Authentication via TLS . . . . . . . . . . . . . . 5
69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
70 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
71 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 6
72 5.2 Informative References . . . . . . . . . . . . . . . . . . . 6
73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
74 Intellectual Property and Copyright Statements . . . . . . . . 8
109 Josefsson Expires May 14, 2005 [Page 2]
111 Internet-Draft Using TLS with Kerberos 5 November 2004
114 1. Introduction and Background
116 This document describe how Shishi, a Kerberos 5 [1] implementation,
117 upgrade communication between clients and Key Distribution Centers
118 (KDCs) to use the Transport Layer Security (TLS) [2] protocol.
120 The TLS protocol offer integrity and privacy protected exchanges that
121 can be authentication using X.509 certificates, OpenPGP keys [6], and
122 user name and passwords via SRP [5].
124 An inconclusive list of the motivation for using TLS with Kerberos 5
127 o Explicit server authentication of the KDC to the client. In
128 traditional Kerberos 5, authentication of the KDC is proved as a
129 side effect that the KDC knows your encryption key (i.e., your
132 o Flexible authentication against KDC. Kerberos 5 assume the user
133 knows a key (usually in the form of a password). Sometimes
134 external factors make this hard to fulfill. In some situations,
135 users are equipped with smart cards with a RSA authentication key.
136 In others, users have a OpenPGP client on their desktop, with a
137 public OpenPGP key known to the server. In some situations, the
138 policy may be that password authentication may only be done
141 o Kerberos exchanges are privacy protected. Part of many Kerberos
142 packets are transfered without privacy protection (i.e.,
143 encryption). That part contains information, such as the client
144 principal name, the server principal name, the encryption types
145 supported by the client, the lifetime of tickets, etc. Revealing
146 such information is, in some threat models, considered a problem.
148 o Prevents downgrade attacks affecting encryption types. The
149 encryption type of the ticket in KDC-REQ are sent in the clear in
150 Kerberos 5. This allows an attacker to replace the encryption
151 type with a compromised mechanisms, e.g. 56-bit DES. Since
152 clients in general cannot know the encryption types other servers
153 support, it is difficult for the client to detect if there was a
154 man-in-the-middle or if the remote server simply did not support a
155 stronger mechanism. Clients could chose to refuse 56-bit DES
156 altogether, but in some environments this leads to operational
159 o The TLS protocol has been studied by many parties. In some threat
160 models, the designer prefer to reduce the number of protocols that
161 can hurt the overall system security if they are compromised.
165 Josefsson Expires May 14, 2005 [Page 3]
167 Internet-Draft Using TLS with Kerberos 5 November 2004
170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
172 document are to be interpreted as described in RFC 2119 [4].
174 2. Extension Mechanism for TCP/IP transport
176 Kerberos 5 require Key Distribution Centers (KDCs) to accept requests
177 over TCP. Each request and response is prefixed by 4 octets,
178 encoding an integer in network byte order, that indicate the length
179 of the packet. The high bit of the 4 octet length field was reserved
180 for future expansion. Servers that do not understand how to
181 interpret a set high bit are required to return a KRB-ERROR with the
182 KRB_ERR_FIELD_TOOLONG error code, and to close the TCP stream.
184 We will use the reserved bit to provide an extension mechanism. When
185 the reserved high bit is set, the remaining 31 bits of the 4 octets
186 are treated as an extensible typed hole, and thus form a 31 bit
187 integer enumerating various extensions. Each of the values indicate
188 a specific extended operation mode, two of which are used and defined
189 here, and the rest are left for others to use.
191 If the KDC do not understand a requested extension, it MUST return a
192 KRB-ERROR with a KRB_ERR_FIELD_TOOLONG value (prefixed by the 4 octet
193 length integer, with the high bit clear, as usual) and close the TCP
196 The following table specify the meaning of the 31 lower bits in the 4
197 octet field, when the high bit is set:
200 1 STARTTLS requested by client.
201 2 STARTTLS request accepted by server.
202 3...2147483647 AVAILABLE for registration (via bug-shishi@josefsson.org)
207 3. Kerberos 5 STARTTLS Extension
209 3.1 STARTTLS requested by client (extension 1)
211 When this message is sent by the client, the client is requesting the
212 server to start TLS negotiation on the TCP stream. The client MUST
213 NOT start TLS negotiation immediately. Instead, the client wait for
214 either a KRB-ERROR (sent normally, prefixed by a 4 octet length
215 integer) indicating the server do not understand the set high bit, or
216 4 octets which is to be interpreted as an integer in network byte
217 order, where the high bit is set and the remaining 31 bit are
218 interpreted as an integer specifying ``STARTTLS request accepted by
222 Josefsson Expires May 14, 2005 [Page 4]
224 Internet-Draft Using TLS with Kerberos 5 November 2004
227 server'' (extension 2). In the first case, the client infer that the
228 server do not understand (or wish to support) STARTTLS, and can
229 re-try using normal TCP, if unprotected Kerberos 5 exchanges are
230 acceptable to the client policy. In the latter case, it should
231 invoke TLS negotiation on the stream. If any other data is received,
232 the client MUST close the TCP stream.
234 3.2 STARTTLS request accepted by server (extension 2)
236 This message should be sent by the server when it has received the
237 extension 1 message. The message is an acknowledgment of the
238 client's request to initiate STARTTLS on the channel. The server
239 MUST then invoke a TLS negotiation.
241 3.3 Proceeding after successful TLS negotiation
243 If the TLS negotiation ended successfully, possibly also considering
244 client or server policies, the exchange within the TLS protected
245 stream is performed like normal UDP Kerberos 5 exchanges, i.e., there
246 is no TCP 4 octet length field before each packet. Instead each
247 Kerberos packet MUST be sent within one TLS record, so the
248 application can use the TLS record length as the Kerberos 5 packet
251 3.4 Proceeding after failed TLS negotiation
253 If the TLS negotiation fails, possibly due to client or server policy
254 (e.g., inadequate support of encryption types in TLS, or lack of
255 client or server authentication) the entity that detect the failure
256 MUST disconnected the connection. It is expected that any error
257 messages that explain the error condition is transfered by TLS.
259 3.5 STARTTLS aware KDC Discovery
261 Section 7.2.3 of Kerberos 5 [1] describe how Domain Name System (DNS)
262 SRV records [3] can be used to find the address of an KDC. To locate
263 a KDC that support the STARTTLS extension, we use the "_tls" domain.
266 _kerberos._tls._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
267 _kerberos._tls._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
270 3.6 Initial Authentication via TLS
272 The server MAY consider the authentication performed by the TLS
273 exchange as sufficient to issue Kerberos 5 tickets to the client,
274 without requiring, e.g., pre-authentication. However, it is not an
278 Josefsson Expires May 14, 2005 [Page 5]
280 Internet-Draft Using TLS with Kerberos 5 November 2004
283 error to require or use pre-authentication as well.
285 The client may also indicate that it wishes to use TLS both for
286 authentication and data protection by using the NULL encryption type
287 in its request. The server can decide from its local policy whether
288 or not issuing tickets based solely on TLS authentication, and
289 whether NULL encryption within TLS, is acceptable or not.
291 4. Security Considerations
293 Because the initial token is not protected, it is possible for an
294 active attacker to make it appear to the client that the server do
295 not support this extension. It is up to client configuration to
296 disallow non-TLS connections, if that vulnerability is deemed
297 unacceptable. For interoperability, we suggest the default behaviour
298 should be to allow automatic fall back to TCP or UDP.
300 The security considerations of both TLS and Kerberos 5 are inherited.
301 Using TLS for authentication and/or data protection together with
302 Kerberos alter the authentication logic fundamentally. Thus, it may
303 be that even if the TLS and Kerberos 5 protocols and implementations
304 were secure, the combination of TLS and Kerberos 5 described here
307 No channel bindings are provided in the Kerberos messages. It is an
308 open question whether, and how, this could be solved. One idea for
309 solving this may be to specify a new encryption algorithm in Kerberos
310 5 that is similar to the NULL encryption algorithm, but also include
311 the TLS session identifier.
315 5.1 Normative References
317 [1] Neuman, C., "The Kerberos Network Authentication Service (V5)",
318 draft-ietf-krb-wg-kerberos-clarifications-07 (work in progress),
321 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
324 [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
325 specifying the location of services (DNS SRV)", RFC 2782,
328 5.2 Informative References
330 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
334 Josefsson Expires May 14, 2005 [Page 6]
336 Internet-Draft Using TLS with Kerberos 5 November 2004
339 Levels", BCP 14, RFC 2119, March 1997.
341 [5] Taylor, D., "Using SRP for TLS Authentication",
342 draft-ietf-tls-srp-08 (work in progress), August 2004.
344 [6] Mavroyanopoulos, N., "Using OpenPGP keys for TLS
345 authentication", draft-ietf-tls-openpgp-keys-05 (work in
346 progress), April 2004.
353 EMail: simon@josefsson.org
390 Josefsson Expires May 14, 2005 [Page 7]
392 Internet-Draft Using TLS with Kerberos 5 November 2004
395 Intellectual Property Statement
397 The IETF takes no position regarding the validity or scope of any
398 Intellectual Property Rights or other rights that might be claimed to
399 pertain to the implementation or use of the technology described in
400 this document or the extent to which any license under such rights
401 might or might not be available; nor does it represent that it has
402 made any independent effort to identify any such rights. Information
403 on the procedures with respect to rights in RFC documents can be
404 found in BCP 78 and BCP 79.
406 Copies of IPR disclosures made to the IETF Secretariat and any
407 assurances of licenses to be made available, or the result of an
408 attempt made to obtain a general license or permission for the use of
409 such proprietary rights by implementers or users of this
410 specification can be obtained from the IETF on-line IPR repository at
411 http://www.ietf.org/ipr.
413 The IETF invites any interested party to bring to its attention any
414 copyrights, patents or patent applications, or other proprietary
415 rights that may cover technology that may be required to implement
416 this standard. Please address the information to the IETF at
420 Disclaimer of Validity
422 This document and the information contained herein are provided on an
423 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
424 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
425 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
426 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
427 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
428 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
433 Copyright (C) The Internet Society (2004). This document is subject
434 to the rights, licenses and restrictions contained in BCP 78, and
436 th therein, the authors retain all their rights.
441 Funding for the RFC Editor function is currently provided by the
447 Josefsson Expires May 14, 2005 [Page 8]