1 2 3 4NETWORK WORKING GROUP S. Emery 5Internet-Draft Sun Microsystems 6Updates: 4121 (if approved) November 9, 2007 7Intended status: Standards Track 8Expires: May 12, 2008 9 10 11 Kerberos Version 5 GSS-API Channel Binding Hash Agility 12 draft-ietf-krb-wg-gss-cb-hash-agility-03.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 12, 2008. 38 39Copyright Notice 40 41 Copyright (C) The IETF Trust (2007). 42 43 44 45 46 47 48 49 50 51 52 53 54 55Emery Expires May 12, 2008 [Page 1] 56 57Internet-Draft Channel Binding Hash Agility November 2007 58 59 60Abstract 61 62 Currently, the Kerberos Version 5 Generic Security Services 63 Application Programming Interface (GSS-API) mechanism [RFC4121] does 64 not have the ability to utilize better hash algorithms used to 65 generate channel binding identities. The current mechanism for doing 66 this is hard coded to use MD5 only. The purpose of this document is 67 to outline changes required to update the protocol so that more 68 secure algorithms can be used to create channel binding identities. 69 The extensibility of this solution also provides an eventual 70 replacement of identities based solely on hash algorithms. 71 72 73Table of Contents 74 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 77 3. Channel binding hash agility . . . . . . . . . . . . . . . . . 5 78 4. Security considerations . . . . . . . . . . . . . . . . . . . 7 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 81 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 Intellectual Property and Copyright Statements . . . . . . . . . . 12 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 12, 2008 [Page 2] 112 113Internet-Draft Channel Binding Hash Agility November 2007 114 115 1161. Introduction 117 118 With the recently discovered weaknesses in the MD5 hash algorithm 119 there is a need to move stronger hash alogrithms. Kerberos Version 5 120 Generic Security Services Application Programming Interface (GSS-API) 121 mechanism [RFC4121] uses MD5 to calculate channel binding identities 122 that are required to be unique. This document specifies an update to 123 the mechanism that allows it to create channel binding identities 124 based on negotiating algorithms securely. This will prevent lengthy 125 standardizations in the future when new attacks arise and will allow 126 an incremental update to the protocol so that this will interoperate 127 with older implementations. 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 12, 2008 [Page 3] 168 169Internet-Draft Channel Binding Hash Agility November 2007 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 12, 2008 [Page 4] 224 225Internet-Draft Channel Binding Hash Agility November 2007 226 227 2283. Channel binding hash agility 229 230 When generating a channel binding identifier, Bnd, a hash is computed 231 from the channel binding information. Initiators MUST populate the 232 Bnd field in order to maintain interoperability with existing 233 acceptors. In addition, initiators MUST populate the extension 234 field, Exts, with TYPED-DATA as defined in [RFC4120]. The 0x8003 GSS 235 checksum MUST have the following structure: 236 237 Octet Name Description 238 ----------------------------------------------------------------- 239 0..3 Lgth Number of octets in Bnd field; Represented 240 in little-endian order; Currently contains 241 hex value 10 00 00 00 (16). 242 4..19 Bnd Channel binding information, as described in 243 section 4.1.1.2 [RFC4121]. 244 20..23 Flags Four-octet context-establishment flags in 245 little-endian order as described in section 246 4.1.1.1 [RFC4121]. 247 24..25 DlgOpt The delegation option identifier (=1) in 248 little-endian order [optional]. This field 249 and the next two fields are present if and 250 only if GSS_C_DELEG_FLAG is set as described 251 in section 4.1.1.1 [RFC4121]. 252 26..27 Dlgth The length of the Deleg field in 253 little-endian order [optional]. 254 28..(n-1) Deleg KRB_CRED message (n = Dlgth + 28) [optional]. 255 n..last Exts Extensions 256 257 where Exts is the concatenation of zero, one or more individual 258 extensions, each of which consists of: 259 type -- big endian order unsigned integer, 32-bits 260 length -- big endian order unsigned integer, 32-bits 261 data -- octet string of length octets 262 in that order 263 264 When channel binding is used the Exts MUST include the following 265 extension: 266 267 data-type 0x00000000 268 269 data-value 270 271 The output obtained by applying the Kerberos V get_mic() 272 operation [RFC3961], using the sub-session key from the 273 authenticator and key usage number TBD, to the channel binding 274 data as described in [RFC4121], section 4.1.1.2 (using get_mic 275 instead of MD5). 276 277 278 279Emery Expires May 12, 2008 [Page 5] 280 281Internet-Draft Channel Binding Hash Agility November 2007 282 283 284 Initiators that are unwilling to use a MD5 hash of the channel 285 bindings should set the Bnd field to all ones (1). 286 287 288 289 290 291 292 293 294 295 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 12, 2008 [Page 6] 336 337Internet-Draft Channel Binding Hash Agility November 2007 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 12, 2008 [Page 7] 392 393Internet-Draft Channel Binding Hash Agility November 2007 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 hash function-agile channel binding," <this RFC>. 403 404 Registration of additional extensions SHALL be by IESG Protocol 405 Action. 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 447Emery Expires May 12, 2008 [Page 8] 448 449Internet-Draft Channel Binding Hash Agility November 2007 450 451 4526. Acknowledgements 453 454 Larry Zhu helped in the review of this document overall and provided 455 the suggestions of typed data and server acknowledgement. 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 12, 2008 [Page 9] 504 505Internet-Draft Channel Binding Hash Agility November 2007 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 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 559Emery Expires May 12, 2008 [Page 10] 560 561Internet-Draft Channel Binding Hash Agility November 2007 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 12, 2008 [Page 11] 616 617Internet-Draft Channel Binding Hash Agility November 2007 618 619 620Full Copyright Statement 621 622 Copyright (C) The IETF Trust (2007). 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 662Acknowledgment 663 664 Funding for the RFC Editor function is provided by the IETF 665 Administrative Support Activity (IASA). 666 667 668 669 670 671Emery Expires May 12, 2008 [Page 12] 672 673 674