1 2 3 4NETWORK WORKING GROUP S. Emery 5Internet-Draft Sun Microsystems 6Updates: 4121 (if approved) November 3, 2008 7Intended status: Standards Track 8Expires: May 7, 2009 9 10 11 Kerberos Version 5 GSS-API Channel Binding Hash Agility 12 draft-ietf-krb-wg-gss-cb-hash-agility-05.txt 13 14Status of this Memo 15 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on May 7, 2009. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55Emery Expires May 7, 2009 [Page 1] 56 57Internet-Draft Channel Binding Hash Agility November 2008 58 59 60Abstract 61 62 Currently, channel bindings are implemented using a MD5 hash in the 63 Kerberos Version 5 Generic Security Services Application Programming 64 Interface (GSS-API) mechanism [RFC4121]. This document updates 65 RFC4121 to allow channel bindings using algorithms negotiated based 66 on Kerberos crypto framework as defined in RFC3961. In addition, 67 because this update makes use of the last extensible field in the 68 Kerberos client-server exchange message, extensions are defined to 69 allow future protocol extensions. 70 71 72Table of Contents 73 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 76 3. Channel binding hash agility . . . . . . . . . . . . . . . . . 5 77 4. Security considerations . . . . . . . . . . . . . . . . . . . 7 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 80 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 Intellectual Property and Copyright Statements . . . . . . . . . . 12 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 111Emery Expires May 7, 2009 [Page 2] 112 113Internet-Draft Channel Binding Hash Agility November 2008 114 115 1161. Introduction 117 118 With the recently discovered weaknesses in the MD5 hash algorithm 119 there is a need to use stronger hash algorithms. Kerberos Version 5 120 Generic Security Services Application Programming Interface (GSS-API) 121 mechanism [RFC4121] uses MD5 to calculate channel binding verifiers. 122 This document specifies an update to the mechanism that allows it to 123 create channel binding information based on negotiated algorithms. 124 This will allow deploying new algorithms incrementally without break 125 interoperability with older implementations, when new attacks arise 126 in the future. 127 128 129 130 131 132 133 134 135 136 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 167Emery Expires May 7, 2009 [Page 3] 168 169Internet-Draft Channel Binding Hash Agility November 2008 170 171 1722. Conventions Used in This Document 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 [RFC2119]. 177 178 The term "little endian order" is used for brevity to refer to the 179 least-significant-octet-first encoding, while the term "big endian 180 order" is for the most-significant-octet-first encoding. 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 223Emery Expires May 7, 2009 [Page 4] 224 225Internet-Draft Channel Binding Hash Agility November 2008 226 227 2283. Channel binding hash agility 229 230 When generating a channel binding verifier, Bnd, a hash is computed 231 from the channel binding fields. Initiators MUST populate the Bnd 232 field in order to maintain interoperability with existing acceptors. 233 In addition, initiators MUST populate the extension field, Exts. All 234 fields before "Exts" do not change from what is described in 235 [RFC4121], they are listed for convenience. The 0x8003 GSS checksum 236 MUST have the following structure: 237 238 Octet Name Description 239 ----------------------------------------------------------------- 240 0..3 Lgth Number of octets in Bnd field; Represented 241 in little-endian order; Currently contains 242 hex value 10 00 00 00 (16). 243 4..19 Bnd Channel binding information, as described in 244 section 4.1.1.2 [RFC4121]. 245 20..23 Flags Four-octet context-establishment flags in 246 little-endian order as described in section 247 4.1.1.1 [RFC4121]. 248 24..25 DlgOpt The delegation option identifier (=1) in 249 little-endian order [optional]. This field 250 and the next two fields are present if and 251 only if GSS_C_DELEG_FLAG is set as described 252 in section 4.1.1.1 [RFC4121]. 253 26..27 Dlgth The length of the Deleg field in 254 little-endian order [optional]. 255 28..(n-1) Deleg KRB_CRED message (n = Dlgth + 28) [optional]. 256 n..last Exts Extensions 257 258 where Exts is the concatenation of zero, one or more individual 259 extensions, each of which consists of, in order: 260 261 type -- big endian order unsigned integer, 32-bits, which 262 contains the type of extension 263 length -- big endian order unsigned integer, 32-bits, which 264 contains the length, in octets, of the extension data 265 encoded as an array of octets immediately following this 266 field 267 data -- octet string of extension information 268 in that order 269 270 If multiple extensions are present then there MUST be at most one 271 instance of a given extension type. 272 273 When channel binding is used the Exts MUST include the following 274 extension: 275 276 277 278 279Emery Expires May 7, 2009 [Page 5] 280 281Internet-Draft Channel Binding Hash Agility November 2008 282 283 284 data-type 0x00000000 285 286 data-value 287 288 The output obtained by applying the Kerberos V get_mic() 289 operation [RFC3961], using the sub-session key from the 290 authenticator and key usage number 43, to the channel binding 291 data as described in [RFC4121], section 4.1.1.2 (using get_mic 292 instead of MD5). 293 294 Initiators that are unwilling to use a MD5 hash of the channel 295 bindings MUST set the Bnd field to sixteen octets of hex value FF. 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335Emery Expires May 7, 2009 [Page 6] 336 337Internet-Draft Channel Binding Hash Agility November 2008 338 339 3404. Security considerations 341 342 Initiators do not know if the acceptor had ignored channel bindings 343 or whether it validated the MD5 hash of the channel bindings 344 [RFC4121]. 345 346 Ultimately, it is up to the application whether to use channel 347 binding or not. This is dependent upon the security policy of these 348 applications. 349 350 351 352 353 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 391Emery Expires May 7, 2009 [Page 7] 392 393Internet-Draft Channel Binding Hash Agility November 2008 394 395 3965. IANA Considerations 397 398 The IANA is hereby requested to create a new registry of "Kerberos V 399 GSS-API mechanism extension types" with four-field entries (type 400 number, type name, description, and normative reference) and, 401 initially, a single registration: 0x00000000, "Channel Binding MIC," 402 "Extension for the verifier of the channel bindings," <this RFC>. 403 404 Using the guidelines for allocation as described in [RFC5226], type 405 number assignments are as follows: 406 407 0x00000000 - 0x000003FF IETF Consensus 408 409 0x00000400 - 0xFFFFF3FF Specification Required 410 411 0xFFFFF400 - 0xFFFFFFFF Private Use 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 447Emery Expires May 7, 2009 [Page 8] 448 449Internet-Draft Channel Binding Hash Agility November 2008 450 451 4526. Acknowledgements 453 454 Larry Zhu helped in the review of this document overall and provided 455 the suggestions of typed-data. 456 457 Nicolas Williams and Sam Hartman suggested that the Bnd and Exts 458 fields be populated simultaneously. 459 460 Nicolas Williams and Jeffrey Hutzelman had also suggested a number 461 changes to this document. 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 503Emery Expires May 7, 2009 [Page 9] 504 505Internet-Draft Channel Binding Hash Agility November 2008 506 507 5087. Normative References 509 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 512 513 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 514 Kerberos 5", RFC 3961, February 2005. 515 516 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 517 Kerberos Network Authentication Service (V5)", RFC 4120, 518 July 2005. 519 520 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 521 Version 5 Generic Security Service Application Program 522 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 523 July 2005. 524 525 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 526 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 527 May 2008. 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 559Emery Expires May 7, 2009 [Page 10] 560 561Internet-Draft Channel Binding Hash Agility November 2008 562 563 564Author's Address 565 566 Shawn Emery 567 Sun Microsystems 568 500 Eldorado Blvd 569 M/S UBRM05-171 570 Broomfield, CO 80021 571 US 572 573 Email: shawn.emery@sun.com 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 615Emery Expires May 7, 2009 [Page 11] 616 617Internet-Draft Channel Binding Hash Agility November 2008 618 619 620Full Copyright Statement 621 622 Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST AND 631 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 632 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 633 THE 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 662 663 664 665 666 667 668 669 670 671Emery Expires May 7, 2009 [Page 12] 672 673 674