1 2 3 4Network Working Group S. Josefsson 5Internet-Draft SJD 6Intended status: Standards Track October 21, 2006 7Expires: April 24, 2007 8 9 10 Using Kerberos V5 over the Transport Layer Security (TLS) protocol 11 draft-josefsson-kerberos5-starttls-02 12 13Status of this Memo 14 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. 19 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- 23 Drafts. 24 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." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 36 This Internet-Draft will expire on April 24, 2007. 37 38Copyright Notice 39 40 Copyright (C) The Internet Society (2006). 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55Josefsson Expires April 24, 2007 [Page 1] 56 57Internet-Draft Protecting Kerberos V5 with TLS October 2006 58 59 60Abstract 61 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. 65 66 67Table of Contents 68 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 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 111Josefsson Expires April 24, 2007 [Page 2] 112 113Internet-Draft Protecting Kerberos V5 with TLS October 2006 114 115 1161. Introduction and Background 117 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. 121 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]. 125 126 There are several reasons to use Kerberos V5 over TLS. 127 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. 141 142 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. 149 150 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. 155 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. 159 160 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 164 165 166 167Josefsson Expires April 24, 2007 [Page 3] 168 169Internet-Draft Protecting Kerberos V5 with TLS October 2006 170 171 172 password). 173 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]. 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 223Josefsson Expires April 24, 2007 [Page 4] 224 225Internet-Draft Protecting Kerberos V5 with TLS October 2006 226 227 2282. Kerberos V5 STARTTLS Extension 229 230 The STARTTLS extension uses the Kerberos V5 TCP extension mechanism 231 [3]. The extension uses bit #TBD in the extension bitmask. 232 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. 237 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. 241 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. 244 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. 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 279Josefsson Expires April 24, 2007 [Page 5] 280 281Internet-Draft Protecting Kerberos V5 with TLS October 2006 282 283 2843. Examples 285 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. 289 290 Client Server 291 292 [ Kerberos V5 TCP extension mechanism negotiation starts ] 293 294 [0x70000000 & STARTTLS-bit] --------> 295 [0x00000000] 296 <-------- 297 298 [ TLS negotiation starts ] 299 300 301 ClientHello --------> 302 ServerHello 303 Certificate* 304 ServerKeyExchange* 305 CertificateRequest* 306 <-------- ServerHelloDone 307 Certificate* 308 ClientKeyExchange 309 CertificateVerify* 310 [ChangeCipherSpec] 311 Finished --------> 312 [ChangeCipherSpec] 313 <-------- Finished 314 315 [ Kerberos V5 negotiation starts ] 316 317 4 octet length field 318 Kerberos V5 AS-REQ --------> 319 4 octet length field 320 Kerberos V5 AS-REP 321 <-------- 322 323 * Indicates optional or situation-dependent messages that are not 324 always sent. 325 326 327 328 329 330 331 332 333 334 335Josefsson Expires April 24, 2007 [Page 6] 336 337Internet-Draft Protecting Kerberos V5 with TLS October 2006 338 339 3404. STARTTLS aware KDC Discovery 341 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 348 RFC 4120. 349 350 For example: 351 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. 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 391Josefsson Expires April 24, 2007 [Page 7] 392 393Internet-Draft Protecting Kerberos V5 with TLS October 2006 394 395 3965. IANA Considerations 397 398 The IANA is requested to allocate a bit in the "Kerberos TCP 399 Extensions" registry for the extension described in this document, as 400 per [3]. 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 447Josefsson Expires April 24, 2007 [Page 8] 448 449Internet-Draft Protecting Kerberos V5 with TLS October 2006 450 451 4526. Security Considerations 453 454 The security considerations in Kerberos V5, TLS, and the extension 455 mechanism framework are inherited. 456 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. 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 503Josefsson Expires April 24, 2007 [Page 9] 504 505Internet-Draft Protecting Kerberos V5 with TLS October 2006 506 507 5087. References 509 5107.1. Normative References 511 512 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 513 Levels", BCP 14, RFC 2119, March 1997. 514 515 [2] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos 516 Network Authentication Service (V5)", RFC 4120, July 2005. 517 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), 521 September 2006. 522 523 [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 524 Protocol Version 1.1", RFC 4346, April 2006. 525 526 [5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 527 specifying the location of services (DNS SRV)", RFC 2782, 528 February 2000. 529 5307.2. Informative References 531 532 [6] Taylor, D., "Using SRP for TLS Authentication", 533 draft-ietf-tls-srp-12 (work in progress), June 2006. 534 535 [7] Mavroyanopoulos, N., "Using OpenPGP keys for TLS 536 authentication", draft-ietf-tls-openpgp-keys-10 (work in 537 progress), June 2006. 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559Josefsson Expires April 24, 2007 [Page 10] 560 561Internet-Draft Protecting Kerberos V5 with TLS October 2006 562 563 564Author's Address 565 566 Simon Josefsson 567 SJD 568 569 Email: simon@josefsson.org 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615Josefsson Expires April 24, 2007 [Page 11] 616 617Internet-Draft Protecting Kerberos V5 with TLS October 2006 618 619 620Full Copyright Statement 621 622 Copyright (C) The Internet Society (2006). 623 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. 627 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. 635 636 637Intellectual Property 638 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. 647 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. 654 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 659 ietf-ipr@ietf.org. 660 661 662Acknowledgment 663 664 Funding for the RFC Editor function is provided by the IETF 665 Administrative Support Activity (IASA). 666 667 668 669 670 671Josefsson Expires April 24, 2007 [Page 12] 672 673