idnits 2.17.1 draft-ietf-kitten-gssapi-channel-bindings-00.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 367. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 383), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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.) ** There are 23 instances of lines with control characters in the document. 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 (July 2004) is 7226 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 282, but not defined == Unused Reference: 'RFC2743' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC0854' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC2025' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC2203' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RFC2478' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'RFC2623' is defined on line 317, but no explicit reference was found in the text == Unused Reference: 'RFC3530' is defined on line 321, 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: 8 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 KITTEN WG N. Williams 2 Internet-Draft Sun 3 Expires: December 30, 2004 July 2004 5 Clarifications and Extensions to the GSS-API for the Use of Channel 6 Bindings 7 draft-ietf-kitten-gssapi-channel-bindings-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 30, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document clarifies and generalizes the GSS-API "channel 41 bindings" facility. This document also specifies the format of the 42 various types of channel bindings. 44 Table of Contents 46 1. Conventions used in this document . . . . . . . . . . . . . . 3 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. Generic Structure for GSS-API Channel Bindings . . . . . . . . 5 49 3.1 Proper Mechanism Use of Channel Bindings . . . . . . . . . 5 50 4. Channel Bindings for SSHv2 . . . . . . . . . . . . . . . . . . 6 51 4.1 GSS_Make_sshv2_channel_bindings() . . . . . . . . . . . . 6 52 4.1.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . 6 53 5. Channel Bindings for TLS . . . . . . . . . . . . . . . . . . . 7 54 5.1 GSS_Make_tls_channel_bindings() . . . . . . . . . . . . . 7 55 5.1.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Channel Bindings for IPsec . . . . . . . . . . . . . . . . . . 8 57 6.1 GSS_Make_ipsec_channel_bindings() . . . . . . . . . . . . 8 58 6.1.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . 9 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 8.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 8.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 11 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 64 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 65 Intellectual Property and Copyright Statements . . . . . . . . 14 67 1. Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 2. Introduction 75 The concept of "channel bindings" and the abstract construction of 76 channel bindings for several types of channels are described in 77 [CHANNEL-BINDINGS] 79 To actually use channel bindings in GSS-API aplications additional 80 details are required that are given below. 82 First the structure given to channel bindings data in [RFC2744] is 83 generalized to all of the GSS-API, not just its C-Bindings. 85 Then the actual construction of channel bindings to SSHv2, TLS and 86 IPsec channels is given. 88 3. Generic Structure for GSS-API Channel Bindings 90 The base GSS-API v2, update 1 specification [RFC2743]describes 91 channel bindings as an OCTET STRING and leaves it to the GSS-API v2, 92 update 1 C-Bindings specification to specify the structure of the 93 contents of the channel bindings OCTET STRINGs. The C-Bindings 94 specification [RFC2744]then defines, in terms of C, what should be 95 generic structure for channel bindings. The Kerberos V GSS mechanism 96 [RFC1964]then defines a method for encoding GSS channel bindings in a 97 way that is independent of the C-Bindings! 99 In other words, the structure of GSS channel bindings given in 100 [RFC2744] is actually generic, rather than specific to the C 101 programming language. 103 Here, then, is a generic re-statement of this structure, in 104 pseudo-ASN.1: 106 GSS-CHANNEL-BINDINGS := SEQUENCE { 107 initiator-address-type INTEGER, 108 initiator-address OCTET STRING, 109 acceptor-address-type INTEGER, 110 acceptor-address OCTET STRING, 111 application-data OCTET STRING, 112 } 114 The values for the address fields are described in [RFC2744]. 116 Language-specific bindings of the GSS-API should specify a 117 language-specific formulation of this structure. 119 3.1 Proper Mechanism Use of Channel Bindings 121 As described in [CHANNEL-BINDINGS], GSS mechanisms should exchange 122 integrity protected proofs of channel bindings, where the proof is 123 obtained by running a strong hash of the channel bindings data 124 (encoded as per some mechanism-specific, such as in [RFC1964]) and a 125 binary value to represent the initiator->acceptor, and opposite, 126 direction. 128 The encoding of channel bindings used in [RFC1964], with the addition 129 of a binary value as described above, and the substitution of SHA-1 130 for MD5 is a reasonable, generic encoding of GSS-CHANNEL-BINDINGS 131 that any future GSS mechanisms can use. 133 4. Channel Bindings for SSHv2 135 The SSHv2 channel bindings are constructed as an octet string for the 136 'application-data' field of the channel bindings by concatenating the 137 following values and in this order: 139 1. The ASCII string "GSS SSHv2 CB:" 140 2. The SSHv2 session ID 141 3. Any additional application-provided data, encoded as the DER 142 encoding of an ASN.1 OCTET STRING 144 4.1 GSS_Make_sshv2_channel_bindings() 146 Inputs: 148 o session_id OCTET STRING, 149 o additional_app_data OCTET STRING 151 Outputs: 153 o major_status INTEGER, 154 o minor_status INTEGER, 155 o channel_bindings_app_data OCTET STRING 157 Return major_status codes: 158 o GSS_S_COMPLETE indicates no error. 159 o GSS_S_FAILURE indicates failure to construct the channel bindings 160 as a result, perhaps, of a memory management, or similar failure. 162 This function constructs an OCTET STRING for use as the value of the 163 application-data field of the GSS-CHANNEL-BINDINGS structure 164 described above. 166 4.1.1 C-Bindings 168 OM_uint32 gss_make_sshv2_channel_bindings( 169 OM_uint32 *minor_status, 170 const gss_buffer_t session_id, 171 const gss_buffer_t additional_app_data, 172 gss_buffer_t channel_bindings_app_data 173 ); 175 5. Channel Bindings for TLS 177 The TLS channel bindings are constructed as an octet string for the 178 'application-data' field of the channel bindings by concatenating the 179 following values and in this order: 181 1. The ASCII string "GSS TLSv1.0 CB:" 182 2. The TLS finished message sent by the client 183 3. The TLS finished message sent by the server 184 4. Any additional application-provided data, encoded as the DER 185 encoding of an ASN.1 OCTET STRING 187 5.1 GSS_Make_tls_channel_bindings() 189 Inputs: 191 o client_finished_msg OCTET STRING, 192 o server_finished_msg OCTET STRING, 193 o additional_app_data OCTET STRING 195 Outputs: 197 o major_status INTEGER, 198 o minor_status INTEGER, 199 o channel_bindings_app_data OCTET STRING 201 Return major_status codes: 202 o GSS_S_COMPLETE indicates no error. 203 o GSS_S_FAILURE indicates failure to construct the channel bindings 204 as a result, perhaps, of a memory management, or similar failure. 206 This function constructs an OCTET STRING for use as the value of the 207 application-data field of the GSS-CHANNEL-BINDINGS structure 208 described above. 210 5.1.1 C-Bindings 212 OM_uint32 gss_make_tls_channel_bindings( 213 OM_uint32 *minor_status, 214 const gss_buffer_t client_finished_msg, 215 const gss_buffer_t server_finished_msg, 216 const gss_buffer_t additional_app_data, 217 gss_buffer_t channel_bindings_app_data 218 ); 220 6. Channel Bindings for IPsec 222 The IPsec channel bindings are constructed as an octet string for the 223 'application-data' field of the channel bindings by concatenating the 224 following values and in this order: 226 1. The ASCII string "GSS IPsec CB:" 227 2. The transform ID for encryption, as a 16-bit big-endian word 228 3. The transform ID for integrity protection, as 16-bit in 229 big-endian word 230 4. The initiator ID payload as used in the key exchange protocol 231 used for setting up the channel's SAs 232 5. The responder ID payload as used in the key exchange protocol 233 used for setting up the channel's SAs 234 6. Any additional application-provided data, encoded as the DER 235 encoding of an ASN.1 OCTET STRING 237 Note that traffic selectors are not included. Inclusion of 238 confidentiality/integrity algorithms protects against MITMs that can 239 compromise weaker algorithms that policy might permit, for the same 240 peers, for other traffic. 242 6.1 GSS_Make_ipsec_channel_bindings() 244 Inputs: 246 o encr_alg INTEGER, 247 o integ_alg INTEGER, 248 o initiator_id OCTET_STRING, 249 o acceptor_id OCTET_STRING, 250 o additional_app_data OCTET STRING 252 Outputs: 254 o major_status INTEGER, 255 o minor_status INTEGER, 256 o channel_bindings_app_data OCTET STRING 258 Return major_status codes: 259 o GSS_S_COMPLETE indicates no error. 260 o GSS_S_FAILURE indicates failure to construct the channel bindings 261 as a result, perhaps, of a memory management, or similar failure. 263 This function constructs an OCTET STRING for use as the value of the 264 application-data field of the GSS-CHANNEL-BINDINGS structure 265 described above. 267 6.1.1 C-Bindings 269 OM_uint32 gss_make_ipsec_channel_bindings( 270 OM_uint32 *minor_status, 271 OM_uint32 encr_alg, 272 OM_uint32 integ_alg, 273 const gss_buffer_t initiator_id, 274 const gss_buffer_t acceptor_id, 275 const gss_buffer_t additional_app_data, 276 gss_buffer_t channel_bindings_app_data 277 ); 279 7. Security Considerations 281 For general security considerations relating to channel bindings see 282 [CHANNEL-BINDINGS] 284 8. References 286 8.1 Normative 288 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 289 1964, June 1996. 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, March 1997. 294 [RFC2743] Linn, J., "Generic Security Service Application Program 295 Interface Version 2, Update 1", RFC 2743, January 2000. 297 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 298 C-bindings", RFC 2744, January 2000. 300 8.2 Informative 302 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 303 Specification", STD 8, RFC 854, May 1983. 305 [RFC1035] Mockapetris, P., "Domain names - implementation and 306 specification", STD 13, RFC 1035, November 1987. 308 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 309 (SPKM)", RFC 2025, October 1996. 311 [RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol 312 Specification", RFC 2203, September 1997. 314 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 315 Negotiation Mechanism", RFC 2478, December 1998. 317 [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues 318 and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", 319 RFC 2623, June 1999. 321 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 322 Beame, C., Eisler, M. and D. Noveck, "Network File System 323 (NFS) version 4 Protocol", RFC 3530, April 2003. 325 Author's Address 327 Nicolas Williams 328 Sun Microsystems 329 5300 Riata Trace Ct 330 Austin, TX 78727 331 US 333 EMail: Nicolas.Williams@sun.com 335 Appendix A. Acknowledgments 337 The author would like to thank Mike Eisler for his work on the 338 Channel Conjunction Mechanism I-D and for bringing the problem to a 339 head, Sam Hartman for pointing out that channel bindings provide a 340 general solution to the channel binding problem, Jeff Altman for his 341 suggestion of using the TLS finished messages as the TLS channel 342 bindings, Bill Sommerfeld, for his help in developing channel 343 bindings for IPsec, and Radia Perlman for her most helpful comments. 345 Intellectual Property Statement 347 The IETF takes no position regarding the validity or scope of any 348 Intellectual Property Rights or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; nor does it represent that it has 352 made any independent effort to identify any such rights. Information 353 on the procedures with respect to rights in RFC documents can be 354 found in BCP 78 and BCP 79. 356 Copies of IPR disclosures made to the IETF Secretariat and any 357 assurances of licenses to be made available, or the result of an 358 attempt made to obtain a general license or permission for the use of 359 such proprietary rights by implementers or users of this 360 specification can be obtained from the IETF on-line IPR repository at 361 http://www.ietf.org/ipr. 363 The IETF invites any interested party to bring to its attention any 364 copyrights, patents or patent applications, or other proprietary 365 rights that may cover technology that may be required to implement 366 this standard. Please address the information to the IETF at 367 ietf-ipr@ietf.org. 369 Disclaimer of Validity 371 This document and the information contained herein are provided on an 372 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 373 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 374 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 375 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 376 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 379 Copyright Statement 381 Copyright (C) The Internet Society (2004). This document is subject 382 to the rights, licenses and restrictions contained in BCP 78, and 383 except as set forth therein, the authors retain all their rights. 385 Acknowledgment 387 Funding for the RFC Editor function is currently provided by the 388 Internet Society.