1 2 3 4Network Working Group S. Josefsson 5Internet-Draft SJD AB 6Intended status: Informational July 31, 2009 7Expires: February 1, 2010 8 9 10 Using Kerberos V5 over the Transport Layer Security (TLS) protocol 11 draft-josefsson-kerberos5-starttls-07 12 13Status of this Memo 14 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 27 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 32 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 37 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 40 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 43 44 This Internet-Draft will expire on February 1, 2010. 45 46Copyright Notice 47 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 50 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 53 54 55Josefsson Expires February 1, 2010 [Page 1] 56 57Internet-Draft Protecting Kerberos V5 with TLS July 2009 58 59 60 Provisions Relating to IETF Documents in effect on the date of 61 publication of this document (http://trustee.ietf.org/license-info). 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. 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 111Josefsson Expires February 1, 2010 [Page 2] 112 113Internet-Draft Protecting Kerberos V5 with TLS July 2009 114 115 116Abstract 117 118 This document specify how the Kerberos V5 protocol can be transported 119 over the Transport Layer Security (TLS) protocol, to provide 120 additional security features. 121 122 123Table of Contents 124 125 1. Introduction and Background . . . . . . . . . . . . . . . . . 4 126 2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 6 127 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 128 4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 8 129 5. Server Certificates . . . . . . . . . . . . . . . . . . . . . 9 130 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 131 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 132 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 133 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 134 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 135 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 136 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 167Josefsson Expires February 1, 2010 [Page 3] 168 169Internet-Draft Protecting Kerberos V5 with TLS July 2009 170 171 1721. Introduction and Background 173 174 This document describe how a Kerberos V5 [RFC4120] implementation may 175 upgrade communication between clients and Key Distribution Centers 176 (KDCs) to use the Transport Layer Security (TLS) [RFC5246] protocol. 177 178 The TLS protocol offer integrity and privacy protected exchanges that 179 can be authentication using X.509 certificates, OpenPGP keys 180 [RFC5081], and user name and passwords via SRP [RFC5054]. 181 182 There are several reasons to use Kerberos V5 over TLS. 183 184 o Prevents downgrade attacks affecting, e.g., encryption types and 185 pre-auth data negotiation. The encryption type field in KDC-REQ, 186 and the METHOD-DATA field with the requested pre-auth types from 187 the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent 188 without integrity or privacy protection in Kerberos 5. This 189 allows an active attacker to replace the encryption type with a 190 compromised encryption type, e.g., 56-bit DES, or request that 191 clients should use a broken pre-auth type. Since clients in 192 general cannot know the encryption types other servers support, or 193 the pre-auth types servers prefer or require, it is difficult for 194 the client to detect if there was a man-in-the-middle or if the 195 remote server simply did not support a stronger encryption type or 196 preferred another pre-auth type. 197 198 o Kerberos exchanges are privacy protected. Part of many Kerberos 199 packets are transferred without privacy protection (i.e., 200 encryption). That part contains information, such as the client 201 principal name, the server principal name, the encryption types 202 supported by the client, the lifetime of tickets, etc. Revealing 203 such information is, in some threat models, considered a problem. 204 205 o Additional authentication against the KDC. In some situations, 206 users are equipped with smart cards with a RSA authentication key. 207 In others, users have a OpenPGP client on their desktop, with a 208 public OpenPGP key known to the server. 209 210 o The TLS protocol has been studied by many parties. In some threat 211 models, the designer prefer to reduce the number of protocols that 212 can hurt the overall system security if they are compromised. 213 214 o Explicit server authentication of the KDC to the client. In 215 traditional Kerberos 5, authentication of the KDC is proved as a 216 side effect that the KDC knows your encryption key (i.e., your 217 password). 218 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 221 222 223Josefsson Expires February 1, 2010 [Page 4] 224 225Internet-Draft Protecting Kerberos V5 with TLS July 2009 226 227 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 279Josefsson Expires February 1, 2010 [Page 5] 280 281Internet-Draft Protecting Kerberos V5 with TLS July 2009 282 283 2842. Kerberos V5 STARTTLS Extension 285 286 The STARTTLS extension uses the Kerberos V5 TCP extension mechanism 287 [RFC5021]. The extension uses bit #TBD in the extension bitmask. 288 289 The protocol is as follows. After the server has sent the 4-octet 290 value 0x00000000 to indicate support of this extension, the stream 291 will be controlled by the TLS protocol and its framing. The TLS 292 protocol is initiated by the client. 293 294 Typically, the client initiate the TLS handshake protocol by sending 295 a client hello, and the server responds, and the handshake continues 296 until it either succeed or fails. 297 298 If for any reason the handshake fails, the STARTTLS protocol will 299 also fail, and the TLS error is used as the error indication. In 300 this case, no further messages can be exchanged over the same TCP 301 session. 302 303 If the handshake succeeds, the Kerberos V5 authentication protocol is 304 performed within the protected TLS channel, like a normal TCP 305 Kerberos V5 exchange. In particular, this means that every Kerberos 306 V5 packet will be prefixed by a 4-octet length field, that indicate 307 the length of the Kerberos V5 packet. 308 309 When no further Kerberos V5 messages needs to be transferred in the 310 TLS session, the TLS session MUST be shut down properly using the 311 close_notify alert. When the TLS session is shut down, the TCP 312 connection cannot be re-used to send any further data and MUST be 313 closed. 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335Josefsson Expires February 1, 2010 [Page 6] 336 337Internet-Draft Protecting Kerberos V5 with TLS July 2009 338 339 3403. Examples 341 342 A complete packet flow for a successful AS-REQ/REP exchange protected 343 by this mechanism will be as follows. The "STARTTLS-bit" is a 344 4-octet value with only the bit allocated for this extension set. 345 346 Client Server 347 348 [ Kerberos V5 TCP extension mechanism negotiation starts ] 349 350 [0x70000000 & STARTTLS-bit] --------> 351 [0x00000000] 352 <-------- 353 354 [ TLS negotiation starts ] 355 356 357 ClientHello --------> 358 ServerHello 359 Certificate* 360 ServerKeyExchange* 361 CertificateRequest* 362 <-------- ServerHelloDone 363 Certificate* 364 ClientKeyExchange 365 CertificateVerify* 366 [ChangeCipherSpec] 367 Finished --------> 368 [ChangeCipherSpec] 369 <-------- Finished 370 371 [ Kerberos V5 negotiation starts ] 372 373 4 octet length field 374 Kerberos V5 AS-REQ --------> 375 4 octet length field 376 Kerberos V5 AS-REP 377 <-------- 378 379 * Indicates optional or situation-dependent messages that are not 380 always sent. 381 382 383 384 385 386 387 388 389 390 391Josefsson Expires February 1, 2010 [Page 7] 392 393Internet-Draft Protecting Kerberos V5 with TLS July 2009 394 395 3964. STARTTLS aware KDC Discovery 397 398 Section 7.2.3 of Kerberos V5 [RFC4120] describe how Domain Name 399 System (DNS) SRV records [RFC2782] can be used to find the address of 400 an KDC. We define a new Proto of "tls" to indicate that the 401 particular KDC is intended to support this STARTTLS extension. The 402 Service, Realm, TTL, Class, SRV, Priority, Weight, Port and Target 403 have the same meaning as in RFC 4120. 404 405 For example: 406 407 _kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 408 _kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 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 February 1, 2010 [Page 8] 448 449Internet-Draft Protecting Kerberos V5 with TLS July 2009 450 451 4525. Server Certificates 453 454 The TLS protocol may be used in a mode that provides server 455 authentication using, for example, X.509 and OpenPGP. 456 457 The Kerberos V5 STARTTLS protocol do not require clients to verify 458 the server certificate. The goal is that support for TLS in Kerberos 459 V5 clients should be as easy to implement and deploy as support for 460 UDP/TCP. Use of TLS, even without server certificate validation, 461 protects against some attacks that Kerberos V5 over UDP/TCP do not. 462 Requiring server certificates to be used at all times would enable 463 attacks in those situations. 464 465 Many client environments do not have secure long-term storage, which 466 is required to validate certificates. This makes it impossible to 467 use server certificate validation on a large number of client 468 systems. 469 470 When clients have the ability, they need to be able to validate the 471 server certificate. For this reason, if a KDC presents a X.509 472 server certificate over TLS, it MUST contain an otherName Subject 473 Alternative Name (SAN) identified using a type-id of id-krb5starttls- 474 san. The intention is to bind the server certificate to the Kerberos 475 realm for the purpose of using Kerberos V5 STARTTLS. The value field 476 of the otherName should contain the realm as the "Realm" ASN.1 type. 477 478 id-krb5starttls-san OBJECT IDENTIFIER ::= 479 { iso(1) identified-organization(3) dod(6) internet(1) 480 private(4) enterprise(1) gnu(11591) 481 shishi(6) krb5starttls-san(1) } 482 483 To validate a server certificate, the client MAY use local 484 configuration (e.g., a list that map realm names to a copy of the 485 server's certificate) and compare that with the authentication 486 information provided from the server via TLS. For illustration, the 487 server certificate could be a X.509 certificate or an OpenPGP key. 488 In this mode, the client need no processing related to id- 489 krb5starttls-san. 490 491 When the server presents a X.509 server certificate, clients MAY use 492 "Certification Path Validation" as described in [RFC5280] to validate 493 the KDC server certificate. In addition, unless the client can 494 otherwise verify that the server certificate is bound to the KDC of 495 the target realm, the client MUST verify that the server certificate 496 contains the id-krb5starttls-san SAN and that the value is identical 497 to the intended Kerberos realm. 498 499 500 501 502 503Josefsson Expires February 1, 2010 [Page 9] 504 505Internet-Draft Protecting Kerberos V5 with TLS July 2009 506 507 5086. IANA Considerations 509 510 The IANA is requested to allocate a bit in the "Kerberos TCP 511 Extensions" registry for the extension described in this document, as 512 per [RFC5021]. 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 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559Josefsson Expires February 1, 2010 [Page 10] 560 561Internet-Draft Protecting Kerberos V5 with TLS July 2009 562 563 5647. Acknowledgements 565 566 Jeffrey Hutzelman and Sam Hartman provided comments that improved the 567 protocol and document. 568 569 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 February 1, 2010 [Page 11] 616 617Internet-Draft Protecting Kerberos V5 with TLS July 2009 618 619 6208. Security Considerations 621 622 The security considerations in Kerberos V5, TLS, and the Kerberos V5 623 TCP extension mechanism are inherited. 624 625 Note that TLS does not protect against Man-In-The-Middle (MITM) 626 attacks unless clients verify the KDC's credentials (X.509 627 certificate, OpenPGP key, etc) correctly. 628 629 If server authentication is used, some information about the server 630 (such as its name) is visible to passive attackers. 631 632 To protect against the inherent downgrade attack in the extension 633 framework, implementations SHOULD offer a policy mode that requires 634 this extension to always be successfully negotiated, for a particular 635 realm, or generally. For interoperability with implementations that 636 do not support this extension, the policy mode SHOULD be disabled by 637 default. 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671Josefsson Expires February 1, 2010 [Page 12] 672 673Internet-Draft Protecting Kerberos V5 with TLS July 2009 674 675 6769. References 677 6789.1. Normative References 679 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, March 1997. 682 683 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 684 specifying the location of services (DNS SRV)", RFC 2782, 685 February 2000. 686 687 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 688 Kerberos Network Authentication Service (V5)", RFC 4120, 689 July 2005. 690 691 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 692 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 693 694 [RFC5021] Josefsson, S., "Extended Kerberos Version 5 Key 695 Distribution Center (KDC) Exchanges over TCP", RFC 5021, 696 August 2007. 697 698 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 699 Housley, R., and W. Polk, "Internet X.509 Public Key 700 Infrastructure Certificate and Certificate Revocation List 701 (CRL) Profile", RFC 5280, May 2008. 702 7039.2. Informative References 704 705 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 706 "Using the Secure Remote Password (SRP) Protocol for TLS 707 Authentication", RFC 5054, November 2007. 708 709 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 710 Layer Security (TLS) Authentication", RFC 5081, 711 November 2007. 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727Josefsson Expires February 1, 2010 [Page 13] 728 729Internet-Draft Protecting Kerberos V5 with TLS July 2009 730 731 732Author's Address 733 734 Simon Josefsson 735 Simon Josefsson Datakonsult AB 736 Hagagatan 24 737 Stockholm 113 47 738 Sweden 739 740 Email: simon@josefsson.org 741 URI: http://josefsson.org/ 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783Josefsson Expires February 1, 2010 [Page 14] 784 785