1Network Working Group S. Josefsson 2Internet-Draft November 13, 2004 3Expires: May 14, 2005 4 5 6 Using Transport Layer Security (TLS) with Kerberos 5 7 draft-josefsson-kerberos5-starttls-00 8 9Status of this Memo 10 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 16 RFC 3668. 17 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 21 Internet-Drafts. 22 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." 27 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 30 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 33 34 This Internet-Draft will expire on May 14, 2005. 35 36Copyright Notice 37 38 Copyright (C) The Internet Society (2004). 39 40Abstract 41 42 This document specify how the Transport Layer Security (TLS) protocol 43 is used in conjunction with the Kerberos 5 protocol. 44 45 46 47 48 49 50 51 52 53Josefsson Expires May 14, 2005 [Page 1] 54 55Internet-Draft Using TLS with Kerberos 5 November 2004 56 57 58Table of Contents 59 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 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 109Josefsson Expires May 14, 2005 [Page 2] 110 111Internet-Draft Using TLS with Kerberos 5 November 2004 112 113 1141. Introduction and Background 115 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. 119 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]. 123 124 An inconclusive list of the motivation for using TLS with Kerberos 5 125 is given below. 126 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 130 password). 131 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 139 through SRP. 140 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. 147 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 157 difficulties. 158 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. 162 163 164 165Josefsson Expires May 14, 2005 [Page 3] 166 167Internet-Draft Using TLS with Kerberos 5 November 2004 168 169 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]. 173 1742. Extension Mechanism for TCP/IP transport 175 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. 183 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. 190 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 194 stream. 195 196 The following table specify the meaning of the 31 lower bits in the 4 197 octet field, when the high bit is set: 198 199 0 RESERVED. 200 1 STARTTLS requested by client. 201 2 STARTTLS request accepted by server. 202 3...2147483647 AVAILABLE for registration (via bug-shishi@josefsson.org) 203. 204 2147483648 RESERVED. 205 206 2073. Kerberos 5 STARTTLS Extension 208 2093.1 STARTTLS requested by client (extension 1) 210 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 219 220 221 222Josefsson Expires May 14, 2005 [Page 4] 223 224Internet-Draft Using TLS with Kerberos 5 November 2004 225 226 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. 233 2343.2 STARTTLS request accepted by server (extension 2) 235 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. 240 2413.3 Proceeding after successful TLS negotiation 242 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 249 length. 250 2513.4 Proceeding after failed TLS negotiation 252 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. 258 2593.5 STARTTLS aware KDC Discovery 260 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. 264 For example: 265 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. 268 269 2703.6 Initial Authentication via TLS 271 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 275 276 277 278Josefsson Expires May 14, 2005 [Page 5] 279 280Internet-Draft Using TLS with Kerberos 5 November 2004 281 282 283 error to require or use pre-authentication as well. 284 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. 290 2914. Security Considerations 292 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. 299 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 305 could be insecure. 306 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. 312 3135. References 314 3155.1 Normative References 316 317 [1] Neuman, C., "The Kerberos Network Authentication Service (V5)", 318 draft-ietf-krb-wg-kerberos-clarifications-07 (work in progress), 319 September 2004. 320 321 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 322 2246, January 1999. 323 324 [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 325 specifying the location of services (DNS SRV)", RFC 2782, 326 February 2000. 327 3285.2 Informative References 329 330 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 331 332 333 334Josefsson Expires May 14, 2005 [Page 6] 335 336Internet-Draft Using TLS with Kerberos 5 November 2004 337 338 339 Levels", BCP 14, RFC 2119, March 1997. 340 341 [5] Taylor, D., "Using SRP for TLS Authentication", 342 draft-ietf-tls-srp-08 (work in progress), August 2004. 343 344 [6] Mavroyanopoulos, N., "Using OpenPGP keys for TLS 345 authentication", draft-ietf-tls-openpgp-keys-05 (work in 346 progress), April 2004. 347 348 349Author's Address 350 351 Simon Josefsson 352 353 EMail: simon@josefsson.org 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 390Josefsson Expires May 14, 2005 [Page 7] 391 392Internet-Draft Using TLS with Kerberos 5 November 2004 393 394 395Intellectual Property Statement 396 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. 405 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. 412 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 417 ietf-ipr@ietf.org. 418 419 420Disclaimer of Validity 421 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. 429 430 431Copyright Statement 432 433 Copyright (C) The Internet Society (2004). This document is subject 434 to the rights, licenses and restrictions contained in BCP 78, and 435 except as set for 436th therein, the authors retain all their rights. 437 438 439Acknowledgment 440 441 Funding for the RFC Editor function is currently provided by the 442 Internet Society. 443 444 445 446 447Josefsson Expires May 14, 2005 [Page 8]