1 2KITTEN WG N. Williams 3Internet-Draft Sun 4Expires: December 30, 2004 July 2004 5 6 7 Clarifications and Extensions to the GSS-API for the Use of Channel 8 Bindings 9 draft-ietf-kitten-gssapi-channel-bindings-00.txt 10 11Status of this Memo 12 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I 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 December 30, 2004. 35 36Copyright Notice 37 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 40Abstract 41 42 This document clarifies and generalizes the GSS-API "channel 43 bindings" facility. This document also specifies the format of the 44 various types of channel bindings. 45 46 47 48 49 50 51 52 53 54Williams Expires December 30, 2004 [Page 1] 55 56Internet-Draft GSS-API Channel Bindings July 2004 57 58 59Table of Contents 60 61 1. Conventions used in this document . . . . . . . . . . . . . . 3 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Generic Structure for GSS-API Channel Bindings . . . . . . . . 5 64 3.1 Proper Mechanism Use of Channel Bindings . . . . . . . . . 5 65 4. Channel Bindings for SSHv2 . . . . . . . . . . . . . . . . . . 6 66 4.1 GSS_Make_sshv2_channel_bindings() . . . . . . . . . . . . 6 67 4.1.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Channel Bindings for TLS . . . . . . . . . . . . . . . . . . . 7 69 5.1 GSS_Make_tls_channel_bindings() . . . . . . . . . . . . . 7 70 5.1.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Channel Bindings for IPsec . . . . . . . . . . . . . . . . . . 8 72 6.1 GSS_Make_ipsec_channel_bindings() . . . . . . . . . . . . 8 73 6.1.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . 9 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 8.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 79 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 80 Intellectual Property and Copyright Statements . . . . . . . . 14 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 110Williams Expires December 30, 2004 [Page 2] 111 112Internet-Draft GSS-API Channel Bindings July 2004 113 114 1151. Conventions used in this document 116 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 120 121 122 123 124 125 126 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 166Williams Expires December 30, 2004 [Page 3] 167 168Internet-Draft GSS-API Channel Bindings July 2004 169 170 1712. Introduction 172 173 The concept of "channel bindings" and the abstract construction of 174 channel bindings for several types of channels are described in 175 [CHANNEL-BINDINGS] 176 177 To actually use channel bindings in GSS-API aplications additional 178 details are required that are given below. 179 180 First the structure given to channel bindings data in [RFC2744] is 181 generalized to all of the GSS-API, not just its C-Bindings. 182 183 Then the actual construction of channel bindings to SSHv2, TLS and 184 IPsec channels is given. 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 222Williams Expires December 30, 2004 [Page 4] 223 224Internet-Draft GSS-API Channel Bindings July 2004 225 226 2273. Generic Structure for GSS-API Channel Bindings 228 229 The base GSS-API v2, update 1 specification [RFC2743]describes 230 channel bindings as an OCTET STRING and leaves it to the GSS-API v2, 231 update 1 C-Bindings specification to specify the structure of the 232 contents of the channel bindings OCTET STRINGs. The C-Bindings 233 specification [RFC2744]then defines, in terms of C, what should be 234 generic structure for channel bindings. The Kerberos V GSS mechanism 235 [RFC1964]then defines a method for encoding GSS channel bindings in a 236 way that is independent of the C-Bindings! 237 238 In other words, the structure of GSS channel bindings given in 239 [RFC2744] is actually generic, rather than specific to the C 240 programming language. 241 242 Here, then, is a generic re-statement of this structure, in 243 pseudo-ASN.1: 244 245 GSS-CHANNEL-BINDINGS := SEQUENCE { 246 initiator-address-type INTEGER, 247 initiator-address OCTET STRING, 248 acceptor-address-type INTEGER, 249 acceptor-address OCTET STRING, 250 application-data OCTET STRING, 251 } 252 253 The values for the address fields are described in [RFC2744]. 254 255 Language-specific bindings of the GSS-API should specify a 256 language-specific formulation of this structure. 257 2583.1 Proper Mechanism Use of Channel Bindings 259 260 As described in [CHANNEL-BINDINGS], GSS mechanisms should exchange 261 integrity protected proofs of channel bindings, where the proof is 262 obtained by running a strong hash of the channel bindings data 263 (encoded as per some mechanism-specific, such as in [RFC1964]) and a 264 binary value to represent the initiator->acceptor, and opposite, 265 direction. 266 267 The encoding of channel bindings used in [RFC1964], with the addition 268 of a binary value as described above, and the substitution of SHA-1 269 for MD5 is a reasonable, generic encoding of GSS-CHANNEL-BINDINGS 270 that any future GSS mechanisms can use. 271 272 273 274 275 276 277 278Williams Expires December 30, 2004 [Page 5] 279 280Internet-Draft GSS-API Channel Bindings July 2004 281 282 2834. Channel Bindings for SSHv2 284 285 The SSHv2 channel bindings are constructed as an octet string for the 286 'application-data' field of the channel bindings by concatenating the 287 following values and in this order: 288 289 1. The ASCII string "GSS SSHv2 CB:" 290 2. The SSHv2 session ID 291 3. Any additional application-provided data, encoded as the DER 292 encoding of an ASN.1 OCTET STRING 293 2944.1 GSS_Make_sshv2_channel_bindings() 295 296 Inputs: 297 298 o session_id OCTET STRING, 299 o additional_app_data OCTET STRING 300 301 Outputs: 302 303 o major_status INTEGER, 304 o minor_status INTEGER, 305 o channel_bindings_app_data OCTET STRING 306 307 Return major_status codes: 308 o GSS_S_COMPLETE indicates no error. 309 o GSS_S_FAILURE indicates failure to construct the channel bindings 310 as a result, perhaps, of a memory management, or similar failure. 311 312 This function constructs an OCTET STRING for use as the value of the 313 application-data field of the GSS-CHANNEL-BINDINGS structure 314 described above. 315 3164.1.1 C-Bindings 317 318 OM_uint32 gss_make_sshv2_channel_bindings( 319 OM_uint32 *minor_status, 320 const gss_buffer_t session_id, 321 const gss_buffer_t additional_app_data, 322 gss_buffer_t channel_bindings_app_data 323 ); 324 325 326 327 328 329 330 331 332 333 334Williams Expires December 30, 2004 [Page 6] 335 336Internet-Draft GSS-API Channel Bindings July 2004 337 338 3395. Channel Bindings for TLS 340 341 The TLS channel bindings are constructed as an octet string for the 342 'application-data' field of the channel bindings by concatenating the 343 following values and in this order: 344 345 1. The ASCII string "GSS TLSv1.0 CB:" 346 2. The TLS finished message sent by the client 347 3. The TLS finished message sent by the server 348 4. Any additional application-provided data, encoded as the DER 349 encoding of an ASN.1 OCTET STRING 350 3515.1 GSS_Make_tls_channel_bindings() 352 353 Inputs: 354 355 o client_finished_msg OCTET STRING, 356 o server_finished_msg OCTET STRING, 357 o additional_app_data OCTET STRING 358 359 Outputs: 360 361 o major_status INTEGER, 362 o minor_status INTEGER, 363 o channel_bindings_app_data OCTET STRING 364 365 Return major_status codes: 366 o GSS_S_COMPLETE indicates no error. 367 o GSS_S_FAILURE indicates failure to construct the channel bindings 368 as a result, perhaps, of a memory management, or similar failure. 369 370 This function constructs an OCTET STRING for use as the value of the 371 application-data field of the GSS-CHANNEL-BINDINGS structure 372 described above. 373 3745.1.1 C-Bindings 375 376 OM_uint32 gss_make_tls_channel_bindings( 377 OM_uint32 *minor_status, 378 const gss_buffer_t client_finished_msg, 379 const gss_buffer_t server_finished_msg, 380 const gss_buffer_t additional_app_data, 381 gss_buffer_t channel_bindings_app_data 382 ); 383 384 385 386 387 388 389 390Williams Expires December 30, 2004 [Page 7] 391 392Internet-Draft GSS-API Channel Bindings July 2004 393 394 3956. Channel Bindings for IPsec 396 397 The IPsec channel bindings are constructed as an octet string for the 398 'application-data' field of the channel bindings by concatenating the 399 following values and in this order: 400 401 1. The ASCII string "GSS IPsec CB:" 402 2. The transform ID for encryption, as a 16-bit big-endian word 403 3. The transform ID for integrity protection, as 16-bit in 404 big-endian word 405 4. The initiator ID payload as used in the key exchange protocol 406 used for setting up the channel's SAs 407 5. The responder ID payload as used in the key exchange protocol 408 used for setting up the channel's SAs 409 6. Any additional application-provided data, encoded as the DER 410 encoding of an ASN.1 OCTET STRING 411 412 Note that traffic selectors are not included. Inclusion of 413 confidentiality/integrity algorithms protects against MITMs that can 414 compromise weaker algorithms that policy might permit, for the same 415 peers, for other traffic. 416 4176.1 GSS_Make_ipsec_channel_bindings() 418 419 Inputs: 420 421 o encr_alg INTEGER, 422 o integ_alg INTEGER, 423 o initiator_id OCTET_STRING, 424 o acceptor_id OCTET_STRING, 425 o additional_app_data OCTET STRING 426 427 Outputs: 428 429 o major_status INTEGER, 430 o minor_status INTEGER, 431 o channel_bindings_app_data OCTET STRING 432 433 Return major_status codes: 434 o GSS_S_COMPLETE indicates no error. 435 o GSS_S_FAILURE indicates failure to construct the channel bindings 436 as a result, perhaps, of a memory management, or similar failure. 437 438 This function constructs an OCTET STRING for use as the value of the 439 application-data field of the GSS-CHANNEL-BINDINGS structure 440 described above. 441 442 443 444 445 446Williams Expires December 30, 2004 [Page 8] 447 448Internet-Draft GSS-API Channel Bindings July 2004 449 450 4516.1.1 C-Bindings 452 453 OM_uint32 gss_make_ipsec_channel_bindings( 454 OM_uint32 *minor_status, 455 OM_uint32 encr_alg, 456 OM_uint32 integ_alg, 457 const gss_buffer_t initiator_id, 458 const gss_buffer_t acceptor_id, 459 const gss_buffer_t additional_app_data, 460 gss_buffer_t channel_bindings_app_data 461 ); 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 502Williams Expires December 30, 2004 [Page 9] 503 504Internet-Draft GSS-API Channel Bindings July 2004 505 506 5077. Security Considerations 508 509 For general security considerations relating to channel bindings see 510 [CHANNEL-BINDINGS] 511 512 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 558Williams Expires December 30, 2004 [Page 10] 559 560Internet-Draft GSS-API Channel Bindings July 2004 561 562 5638. References 564 5658.1 Normative 566 567 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 568 1964, June 1996. 569 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 573 [RFC2743] Linn, J., "Generic Security Service Application Program 574 Interface Version 2, Update 1", RFC 2743, January 2000. 575 576 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 577 C-bindings", RFC 2744, January 2000. 578 5798.2 Informative 580 581 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 582 Specification", STD 8, RFC 854, May 1983. 583 584 [RFC1035] Mockapetris, P., "Domain names - implementation and 585 specification", STD 13, RFC 1035, November 1987. 586 587 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 588 (SPKM)", RFC 2025, October 1996. 589 590 [RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol 591 Specification", RFC 2203, September 1997. 592 593 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 594 Negotiation Mechanism", RFC 2478, December 1998. 595 596 [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues 597 and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", 598 RFC 2623, June 1999. 599 600 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 601 Beame, C., Eisler, M. and D. Noveck, "Network File System 602 (NFS) version 4 Protocol", RFC 3530, April 2003. 603 604 605 606 607 608 609 610 611 612 613 614Williams Expires December 30, 2004 [Page 11] 615 616Internet-Draft GSS-API Channel Bindings July 2004 617 618 619Author's Address 620 621 Nicolas Williams 622 Sun Microsystems 623 5300 Riata Trace Ct 624 Austin, TX 78727 625 US 626 627 EMail: Nicolas.Williams@sun.com 628 629 630 631 632 633 634 635 636 637 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 670Williams Expires December 30, 2004 [Page 12] 671 672Internet-Draft GSS-API Channel Bindings July 2004 673 674 675Appendix A. Acknowledgments 676 677 The author would like to thank Mike Eisler for his work on the 678 Channel Conjunction Mechanism I-D and for bringing the problem to a 679 head, Sam Hartman for pointing out that channel bindings provide a 680 general solution to the channel binding problem, Jeff Altman for his 681 suggestion of using the TLS finished messages as the TLS channel 682 bindings, Bill Sommerfeld, for his help in developing channel 683 bindings for IPsec, and Radia Perlman for her most helpful comments. 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726Williams Expires December 30, 2004 [Page 13] 727 728Internet-Draft GSS-API Channel Bindings July 2004 729 730 731Intellectual Property Statement 732 733 The IETF takes no position regarding the validity or scope of any 734 Intellectual Property Rights or other rights that might be claimed to 735 pertain to the implementation or use of the technology described in 736 this document or the extent to which any license under such rights 737 might or might not be available; nor does it represent that it has 738 made any independent effort to identify any such rights. Information 739 on the procedures with respect to rights in RFC documents can be 740 found in BCP 78 and BCP 79. 741 742 Copies of IPR disclosures made to the IETF Secretariat and any 743 assurances of licenses to be made available, or the result of an 744 attempt made to obtain a general license or permission for the use of 745 such proprietary rights by implementers or users of this 746 specification can be obtained from the IETF on-line IPR repository at 747 http://www.ietf.org/ipr. 748 749 The IETF invites any interested party to bring to its attention any 750 copyrights, patents or patent applications, or other proprietary 751 rights that may cover technology that may be required to implement 752 this standard. Please address the information to the IETF at 753 ietf-ipr@ietf.org. 754 755 756Disclaimer of Validity 757 758 This document and the information contained herein are provided on an 759 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 760 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 761 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 762 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 763 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 764 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 765 766 767Copyright Statement 768 769 Copyright (C) The Internet Society (2004). This document is subject 770 to the rights, licenses and restrictions contained in BCP 78, and 771 except as set forth therein, the authors retain all their rights. 772 773 774Acknowledgment 775 776 Funding for the RFC Editor function is currently provided by the 777 Internet Society. 778 779 780 781 782Williams Expires December 30, 2004 [Page 14] 783 784 785