idnits 2.17.1 draft-ietf-kitten-gssapi-channel-bindings-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 400. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 16, 2005) is 6761 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CHANNEL-BINDINGS' is mentioned on line 315, but not defined == Unused Reference: 'RFC2743' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC0854' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'RFC2025' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC2203' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC2478' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC2623' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC3530' is defined on line 354, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2478 (Obsoleted by RFC 4178) -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KITTEN WG N. Williams 3 Internet-Draft Sun 4 Expires: April 19, 2006 October 16, 2005 6 Clarifications and Extensions to the GSS-API for the Use of Channel 7 Bindings 8 draft-ietf-kitten-gssapi-channel-bindings-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 19, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document clarifies and generalizes the GSS-API "channel 42 bindings" facility. This document also specifies the format of the 43 various types of channel bindings. 45 Table of Contents 47 1. Conventions used in this document . . . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. Generic Structure for GSS-API Channel Bindings . . . . . . . . 5 50 3.1. Proper Mechanism Use of Channel Bindings . . . . . . . . . 5 51 4. Channel Bindings for SSHv2 . . . . . . . . . . . . . . . . . . 6 52 4.1. GSS_Make_sshv2_channel_bindings() . . . . . . . . . . . . 6 53 4.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . 7 54 5. Channel Bindings for TLS . . . . . . . . . . . . . . . . . . . 8 55 5.1. GSS_Make_tls_channel_bindings() . . . . . . . . . . . . . 8 56 5.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . 9 57 6. Channel Bindings for IPsec . . . . . . . . . . . . . . . . . . 10 58 6.1. GSS_Make_ipsec_channel_bindings() . . . . . . . . . . . . 10 59 6.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . 11 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 8.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 13 63 8.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 13 64 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 Intellectual Property and Copyright Statements . . . . . . . . . . 16 68 1. Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in [RFC2119]. 74 2. Introduction 76 The concept of "channel bindings" and the abstract construction of 77 channel bindings for several types of channels are described in 78 [CHANNEL-BINDINGS] 80 To actually use channel bindings in GSS-API aplications additional 81 details are required that are given below. 83 First the structure given to channel bindings data in [RFC2744] is 84 generalized to all of the GSS-API, not just its C-Bindings. 86 Then the actual construction of channel bindings to SSHv2, TLS and 87 IPsec channels is given. 89 3. Generic Structure for GSS-API Channel Bindings 91 The base GSS-API v2, update 1 specification [RFC2743]describes 92 channel bindings as an OCTET STRING and leaves it to the GSS-API v2, 93 update 1 C-Bindings specification to specify the structure of the 94 contents of the channel bindings OCTET STRINGs. The C-Bindings 95 specification [RFC2744]then defines, in terms of C, what should be 96 generic structure for channel bindings. The Kerberos V GSS mechanism 97 [RFC1964]then defines a method for encoding GSS channel bindings in a 98 way that is independent of the C-Bindings! 100 In other words, the structure of GSS channel bindings given in 101 [RFC2744] is actually generic, rather than specific to the C 102 programming language. 104 Here, then, is a generic re-statement of this structure, in pseudo- 105 ASN.1: 107 GSS-CHANNEL-BINDINGS := SEQUENCE { 108 initiator-address-type INTEGER, 109 initiator-address OCTET STRING, 110 acceptor-address-type INTEGER, 111 acceptor-address OCTET STRING, 112 application-data OCTET STRING, 113 } 115 The values for the address fields are described in [RFC2744]. 117 Language-specific bindings of the GSS-API should specify a language- 118 specific formulation of this structure. 120 3.1. Proper Mechanism Use of Channel Bindings 122 As described in [CHANNEL-BINDINGS], GSS mechanisms should exchange 123 integrity protected proofs of channel bindings, where the proof is 124 obtained by running a strong hash of the channel bindings data 125 (encoded as per some mechanism-specific, such as in [RFC1964]) and a 126 binary value to represent the initiator->acceptor, and opposite, 127 direction. 129 The encoding of channel bindings used in [RFC1964], with the addition 130 of a binary value as described above, and the substitution of SHA-1 131 for MD5 is a reasonable, generic encoding of GSS-CHANNEL-BINDINGS 132 that any future GSS mechanisms can use. 134 4. Channel Bindings for SSHv2 136 The SSHv2 channel bindings are constructed as an octet string for the 137 'application-data' field of the channel bindings by concatenating the 138 following values and in this order: 140 1. The ASCII string "GSS SSHv2 CB:" 142 2. The SSHv2 session ID 144 3. Any additional application-provided data, encoded as the DER 145 encoding of an ASN.1 OCTET STRING 147 4.1. GSS_Make_sshv2_channel_bindings() 149 Inputs: 151 o session_id OCTET STRING, 153 o additional_app_data OCTET STRING 155 Outputs: 157 o major_status INTEGER, 159 o minor_status INTEGER, 161 o channel_bindings_app_data OCTET STRING 163 Return major_status codes: 165 o GSS_S_COMPLETE indicates no error. 167 o GSS_S_FAILURE indicates failure to construct the channel bindings 168 as a result, perhaps, of a memory management, or similar failure. 170 This function constructs an OCTET STRING for use as the value of the 171 application-data field of the GSS-CHANNEL-BINDINGS structure 172 described above. 174 4.1.1. C-Bindings 176 OM_uint32 gss_make_sshv2_channel_bindings( 177 OM_uint32 *minor_status, 178 const gss_buffer_t session_id, 179 const gss_buffer_t additional_app_data, 180 gss_buffer_t channel_bindings_app_data 181 ); 183 5. Channel Bindings for TLS 185 The TLS channel bindings are constructed as an octet string for the 186 'application-data' field of the channel bindings by concatenating the 187 following values and in this order: 189 1. The ASCII string "GSS TLSv1.0 CB:" 191 2. The TLS finished message sent by the client 193 3. The TLS finished message sent by the server 195 4. Any additional application-provided data, encoded as the DER 196 encoding of an ASN.1 OCTET STRING 198 5.1. GSS_Make_tls_channel_bindings() 200 Inputs: 202 o client_finished_msg OCTET STRING, 204 o server_finished_msg OCTET STRING, 206 o additional_app_data OCTET STRING 208 Outputs: 210 o major_status INTEGER, 212 o minor_status INTEGER, 214 o channel_bindings_app_data OCTET STRING 216 Return major_status codes: 218 o GSS_S_COMPLETE indicates no error. 220 o GSS_S_FAILURE indicates failure to construct the channel bindings 221 as a result, perhaps, of a memory management, or similar failure. 223 This function constructs an OCTET STRING for use as the value of the 224 application-data field of the GSS-CHANNEL-BINDINGS structure 225 described above. 227 5.1.1. C-Bindings 229 OM_uint32 gss_make_tls_channel_bindings( 230 OM_uint32 *minor_status, 231 const gss_buffer_t client_finished_msg, 232 const gss_buffer_t server_finished_msg, 233 const gss_buffer_t additional_app_data, 234 gss_buffer_t channel_bindings_app_data 235 ); 237 6. Channel Bindings for IPsec 239 The IPsec channel bindings are constructed as an octet string for the 240 'application-data' field of the channel bindings by concatenating the 241 following values and in this order: 243 1. The ASCII string "GSS IPsec CB:" 245 2. The transform ID for encryption, as a 16-bit big-endian word 247 3. The transform ID for integrity protection, as 16-bit in big- 248 endian word 250 4. NOTE: The following needs to be updated to take into account 251 progress of BTNS. 253 5. The initiator ID payload as used in the key exchange protocol 254 used for setting up the channel's SAs 256 6. The responder ID payload as used in the key exchange protocol 257 used for setting up the channel's SAs 259 7. Any additional application-provided data, encoded as the DER 260 encoding of an ASN.1 OCTET STRING 262 Note that traffic selectors are not included. Inclusion of 263 confidentiality/integrity algorithms protects against MITMs that can 264 compromise weaker algorithms that policy might permit, for the same 265 peers, for other traffic. 267 6.1. GSS_Make_ipsec_channel_bindings() 269 Inputs: 271 o encr_alg INTEGER, 273 o integ_alg INTEGER, 275 o initiator_id OCTET_STRING, 277 o acceptor_id OCTET_STRING, 279 o additional_app_data OCTET STRING 281 Outputs: 283 o major_status INTEGER, 285 o minor_status INTEGER, 287 o channel_bindings_app_data OCTET STRING 289 Return major_status codes: 291 o GSS_S_COMPLETE indicates no error. 293 o GSS_S_FAILURE indicates failure to construct the channel bindings 294 as a result, perhaps, of a memory management, or similar failure. 296 This function constructs an OCTET STRING for use as the value of the 297 application-data field of the GSS-CHANNEL-BINDINGS structure 298 described above. 300 6.1.1. C-Bindings 302 OM_uint32 gss_make_ipsec_channel_bindings( 303 OM_uint32 *minor_status, 304 OM_uint32 encr_alg, 305 OM_uint32 integ_alg, 306 const gss_buffer_t initiator_id, 307 const gss_buffer_t acceptor_id, 308 const gss_buffer_t additional_app_data, 309 gss_buffer_t channel_bindings_app_data 310 ); 312 7. Security Considerations 314 For general security considerations relating to channel bindings see 315 [CHANNEL-BINDINGS] 317 8. References 319 8.1. Normative 321 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 322 RFC 1964, June 1996. 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [RFC2743] Linn, J., "Generic Security Service Application Program 328 Interface Version 2, Update 1", RFC 2743, January 2000. 330 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 331 C-bindings", RFC 2744, January 2000. 333 8.2. Informative 335 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 336 Specification", STD 8, RFC 854, May 1983. 338 [RFC1035] Mockapetris, P., "Domain names - implementation and 339 specification", STD 13, RFC 1035, November 1987. 341 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 342 (SPKM)", RFC 2025, October 1996. 344 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 345 Specification", RFC 2203, September 1997. 347 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 348 Negotiation Mechanism", RFC 2478, December 1998. 350 [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues 351 and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", 352 RFC 2623, June 1999. 354 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 355 Beame, C., Eisler, M., and D. Noveck, "Network File System 356 (NFS) version 4 Protocol", RFC 3530, April 2003. 358 Appendix A. Acknowledgments 360 The author would like to thank Mike Eisler for his work on the 361 Channel Conjunction Mechanism I-D and for bringing the problem to a 362 head, Sam Hartman for pointing out that channel bindings provide a 363 general solution to the channel binding problem, Jeff Altman for his 364 suggestion of using the TLS finished messages as the TLS channel 365 bindings, Bill Sommerfeld, for his help in developing channel 366 bindings for IPsec, and Radia Perlman for her most helpful comments. 368 Author's Address 370 Nicolas Williams 371 Sun Microsystems 372 5300 Riata Trace Ct 373 Austin, TX 78727 374 US 376 Email: Nicolas.Williams@sun.com 378 Intellectual Property Statement 380 The IETF takes no position regarding the validity or scope of any 381 Intellectual Property Rights or other rights that might be claimed to 382 pertain to the implementation or use of the technology described in 383 this document or the extent to which any license under such rights 384 might or might not be available; nor does it represent that it has 385 made any independent effort to identify any such rights. Information 386 on the procedures with respect to rights in RFC documents can be 387 found in BCP 78 and BCP 79. 389 Copies of IPR disclosures made to the IETF Secretariat and any 390 assurances of licenses to be made available, or the result of an 391 attempt made to obtain a general license or permission for the use of 392 such proprietary rights by implementers or users of this 393 specification can be obtained from the IETF on-line IPR repository at 394 http://www.ietf.org/ipr. 396 The IETF invites any interested party to bring to its attention any 397 copyrights, patents or patent applications, or other proprietary 398 rights that may cover technology that may be required to implement 399 this standard. Please address the information to the IETF at 400 ietf-ipr@ietf.org. 402 Disclaimer of Validity 404 This document and the information contained herein are provided on an 405 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 406 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 407 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 408 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 409 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 410 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 412 Copyright Statement 414 Copyright (C) The Internet Society (2005). This document is subject 415 to the rights, licenses and restrictions contained in BCP 78, and 416 except as set forth therein, the authors retain all their rights. 418 Acknowledgment 420 Funding for the RFC Editor function is currently provided by the 421 Internet Society.