idnits 2.17.1 draft-ietf-kitten-channel-bound-flag-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2743, but the abstract doesn't seem to directly say this. It does mention RFC2743 though, so this could be OK. -- The draft header indicates that this document updates RFC2744, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2743, updated by this document, for RFC5378 checks: 1997-09-23) (Using the creation date from RFC2744, updated by this document, for RFC5378 checks: 1995-03-08) -- 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 5, 2017) is 2395 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5653 (Obsoleted by RFC 8353) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KITTEN R. Harwood 3 Internet-Draft Red Hat 4 Updates: 2743, 2744 (if approved) N. Williams 5 Intended status: Standards Track Cryptonector 6 Expires: April 8, 2018 October 5, 2017 8 Channel Binding Signalling for the Generic Security Services Application 9 Programming Interface 10 draft-ietf-kitten-channel-bound-flag-02 12 Abstract 14 Channel binding is a technique that allows applications to use a 15 secure channel at a lower layer without having to use authentication 16 at that lower layer. The concept of channel binding comes from the 17 Generic Security Services Application Programming Interface (GSS- 18 API). It turns out that the semantics commonly implemented are 19 different than those specified in the base GSS-API RFC (RFC2743), and 20 that that specification has a serious bug. This document addresses 21 both the inconsistency as-implemented and the specification bug. 23 This Internet-Draft proposes the addition of a "channel bound" return 24 flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() 25 functions. Two behaviors are specified: a default, safe behavior 26 reflecting existing implementation deployments, and a behavior that 27 is only safe when the application specifically tells the GSS-API that 28 it (the application) supports the new behavior. Additional API 29 elements related to this are also added, including a new security 30 context establishment API. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 8, 2018. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Design and Future directions . . . . . . . . . . . . . . . 3 68 1.2. Conventions used in this document . . . . . . . . . . . . . 3 69 2. Channel Binding State Extension . . . . . . . . . . . . . . . 4 70 2.1. GSS_Create_sec_context() . . . . . . . . . . . . . . . . . 4 71 2.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.2. GSS_Set_context_flags() . . . . . . . . . . . . . . . . . . 5 73 2.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.3. Return Flag for Channel Binding State Signalling . . . . . 6 75 2.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 6 76 2.4. New Mechanism Attributes . . . . . . . . . . . . . . . . . 6 77 2.5. Request Flag for Acceptor Confirmation of Channel Binding . 6 78 2.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 7 79 2.6. Handling Empty Contexts in Other GSS-API Functions . . . . 7 80 3. Modified Channel Binding Semantics . . . . . . . . . . . . . 7 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 85 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 The GSS-API [RFC2743] supports "channel binding" [RFC5056], a 91 technique for detection of man-in-the-middle (MITM) attacks in secure 92 channels at lower network layers. This facility is meant to be all- 93 or-nothing: either both the initiator and acceptor use it and it 94 succeeds, or both must not use it. This has created a negotiation 95 problem when retrofitting the use of channel binding into existing 96 application protocols. 98 However, GSS-APIv2u1 [RFC2743] does not specify channel binding 99 behavior when only one party provides provides none. In practice 100 some mechanisms ignore channel bindings when the acceptor provides 101 none, but not when the initiator provides none. [XXX add references 102 to the relevant SSPI docs? -Nico] Note that it would be useless to 103 allow security context establishment to succeed when the initiator 104 does not provide channel bindings but the acceptor does, at least as 105 long as there's no outward indication of whether channel binding was 106 used! Since the GSS-APIv2u1 does not provide any such indication, 107 this document corrects that flaw. 109 Allowing the connection to succeed when an initiator provides 110 bindings but an acceptor does not has helped deployment of channel 111 binding in existing applications: first fix all the initiators, then 112 fix all the acceptors. But even this technique is insufficient when 113 there are many clients to fix, such that fixing them all will take a 114 long time. Additionally, it limits the usefulness of channel 115 bindings, while allowing the acceptor to provide but not enforce 116 would protect against man in the middle attacks (for channel binding 117 aware initiators). 119 This document proposes a new method for deployment of channel binding 120 that allows the feature to be enabled on the acceptor side before 121 fixing all initiators. If the GSS-API had always had a return flag 122 by which to indicate channel binding state then we could have had a 123 simpler method of deploying channel binding: applications check that 124 return flag and act accordingly (e.g., fail when channel binding is 125 required). We cannot safely introduce this behavior now without an 126 indication of support by the application. 128 Additionally, there may be applications where it is important for 129 initiators to know that acceptors did use channel binding, and even 130 to know whether a mechanism is capable of indicating as much. We add 131 a request flag and two mechanism attributes for such applications. 133 1.1. Design and Future directions 135 The design for signalling application flag support and empty contexts 136 is based on the Java Bindings of the GSS-API [RFC5653]. This 137 document begins introduction of additional context inquiry and 138 mutation functions, which eventually will also allow for simplified 139 stepping to replace the GSS_Init/Accept_sec_context() loop. 141 1.2. Conventions used in this document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 2. Channel Binding State Extension 149 We propose a new return flag for GSS_Init_sec_context() and 150 GSS_Accept_sec_context(), as well as a pair of functions for a) 151 creating "empty" security context handles, b) requesting flags and 152 indicating which flags the application understands. We also add new 153 mechanism attributes describing mechanism capabilities. 155 C bindings of these extensions are provided along the lines of 156 [RFC2744] and [RFC5587]. 158 In the future we might move more of the many input (and output) 159 arguments to GSS_Init_sec_context() and GSS_Accept_sec_context() into 160 mutators on empty security context handles. 162 2.1. GSS_Create_sec_context() 164 Inputs: 166 o 168 Outputs: 170 o major_status INTEGER 172 o minor_status INTEGER -- note: mostly useless, but we should keep 173 it 175 o context SECURITY CONTEXT -- "empty" security context 177 Return major status codes: 179 o GSS_S_COMPLETE indicates success. 181 o GSS_S_UNAVAILABLE indicates that memory is not available, for 182 example. 184 o GSS_S_FAILURE indicates a general failure. 186 This function creates an "empty" security context handle that can be 187 passed to GSS_Init_sec_context() or GSS_Accept_sec_context() where 188 they expect a NULL context. 190 2.1.1. C-Bindings 192 OM_uint32 193 gss_create_sec_context(OM_uint32 *minor_status, 194 gss_ctx_id_t *context); 196 2.2. GSS_Set_context_flags() 198 Inputs: 200 context CONTEXT HANDLE 202 req_flags FLAGS Requested flags. Applicable to acceptors and 203 initiators. 205 ret_flags_understood FLAGS The set of return flags understood by the 206 caller. 208 Outputs: 210 o major_status INTEGER 212 o minor_status INTEGER 214 Return major status codes: 216 o GSS_S_COMPLETE indicates success. 218 o GSS_S_FAILURE indicates a general failure. 220 This function tells the mechanism (when one is eventually chosen and 221 invoked) that the application requests the given req_flags and is 222 prepared to check the flags in the given ret_flags_understood. 223 Mechanisms SHOULD NOT limit flags returned to those in 224 ret_flags_understood, but MAY alter behavior accordingly. Initiators 225 can override the req_flags in their GSS_Init_sec_context() call, but 226 if no flags are requested there then the req_flags set on the empty 227 context will be used. GSS_Accept_sec_context() is not required to 228 perform any action based on req_flags at this time. 230 NOTE: The abstract GSS-API [RFC2743] uses individual elements--one 231 per-flag--instead of a "FLAGS" type. This is unwieldy, therefore we 232 introduce an abstract type named "FLAGS" to act as a set of all the 233 request/return flags defined for the abstract GSS-API. 235 2.2.1. C-Bindings 237 OM_uint32 238 gss_set_context_flags(OM_uint32 *minor_status, 239 gss_ctx_id_t context, 240 uint64_t req_flags, 241 uint64_t ret_flags_understood); 243 2.3. Return Flag for Channel Binding State Signalling 245 Whenever both the initiator and the acceptor provide matching channel 246 bindings to GSS_Init_sec_context() and GSS_Accept_sec_context(), 247 respectively, then the mechanism SHALL indicate that the context is 248 channel bound via an output flag, ret_channel_bound_flag, for the 249 established context. Note that some mechanisms have no way for the 250 acceptor to signal CB success to the initiator, in which case 251 GSS_Init_sec_context() MUST NOT output the ret_channel_bound_flag. 253 2.3.1. C-Bindings 255 #define GSS_C_CHANNEL_BOUND_FLAG 2048 /* 0x00000800 */ 257 2.4. New Mechanism Attributes 259 o We add a new mechanism attribute, GSS_C_MA_CBINDING_CONFIRM, to 260 indicate that the initiator can and always does learn whether the 261 acceptor application supplied channel bindings (assuming mutual 262 auth has been requested). Mechanisms advertising this attribute 263 MUST always indicate acceptor channel bound state to the 264 initiator. 266 o We add a new mechanism attribute, GSS_C_MA_CBINDING_MAY_CONFIRM, 267 to indicate that the initiator may learn whether the acceptor 268 application supplied channel bindings (assuming mutual auth has 269 been requested), but only when the acceptor implementation of the 270 mechanism has been suitably updated. Mechanisms MUST advertise 271 this attribute when the local initiator functionality for acceptor 272 channel bound state indication exists but the acceptor may lack 273 the same functionality (because, for example, the mechanism 274 predates this specification). 276 OID assignments TBD. 278 2.5. Request Flag for Acceptor Confirmation of Channel Binding 280 We add a new request flag for GSS_Init_sec_context(), 281 req_cb_confirmation_flag, to be used by initiators that insist on 282 acceptors providing channel bindings. This flag is only of use to 283 mechanism-negotiation pseudo-mechanisms (e.g., SPNEGO [RFC4178]): if 284 set, the pseudo-mechanism MUST NOT negotiate any mechanisms that lack 285 both the GSS_C_MA_CBINDING_CONFIRM and GSS_C_MA_CBINDING_MAY_CONFIRM 286 mechanism attributes, and SHOULD NOT negotiate mechanisms that lack 287 the GSS_C_MA_CBINDING_CONFIRM mechanism attribute (except if allowed 288 by local configuration). 290 2.5.1. C-Bindings 292 Because GSS_C_CHANNEL_BOUND_FLAG is a return flag only, and this flag 293 is a request flag only, and to save on precious flag bits, we use the 294 same flag bit assignment for both flags: 296 #define GSS_C_CB_CONFIRM_FLAG 2048 /* 0x00000800 */ 298 2.6. Handling Empty Contexts in Other GSS-API Functions 300 GSS_Init_sec_context() and GSS_Accept_sec_context() operate on empty 301 security contexts as specified above (i.e., examining flags). 303 All other GSS-API functions MUST treat empty contexts as they would 304 GSS_C_NO_CONTEXT as well. For most functions, this will result in 305 returning GSS status code GSS_S_NO_CONTEXT. 307 GSS_Delete_sec_context() MUST NOT output a context deletion token 308 when applied to empty security contexts. 310 3. Modified Channel Binding Semantics 312 The channel binding semantics of the base GSS-API are modified as 313 follows: 315 o Whenever both the initiator and acceptor have provided 316 input_channel_bindings to GSS_Init/Accept_sec_context() and the 317 channel bindings do not match, then the mechanism MUST fail to 318 establish a security context token. (This is a restatement of an 319 existing requirement in the base specification.) 321 o Whenever the acceptor application has a) provided channel bindings 322 to GSS_Accept_sec_context(), and b) not indicated support for the 323 ret_channel_bound_flag flag, then the mechanism MUST fail to 324 establish a security context if the initiator did not provide 325 channel bindings data. This requirement is critical for security 326 purposes, to make applications predating this document secure, and 327 this requirement reflects actual implementations as deployed. 329 o Whenever the initiator application has a) provided channel 330 bindings to GSS_Init_sec_context(), and b) not indicated support 331 for the ret_channel_bound_flag flag, then the mechanism MUST NOT 332 fail to establish a security context just because the acceptor 333 failed to provide channel bindings data. This requirement is for 334 interoperability purposes, and reflects actual implementations 335 that have been deployed. 337 o Whenever the application has a) provided channel bindings to 338 GSS_Init_sec_context() or GSS_Accept_sec_context(), and b) 339 indicated support for the ret_channel_bound_flag flag, then the 340 mechanism MUST NOT fail to establish a security context just 341 because the peer did not provide channel bindings data. The 342 mechanism MUST output the ret_channel_bound_flag if both peers 343 provided the same input_channel_bindings to GSS_Init_sec_context() 344 and GSS_Accept_sec_context. The mechanism MUST NOT output the 345 ret_channel_bound_flag if either (or both) peer did not provide 346 input_channel_bindings to GSS_Init/Accept_sec_context(). This 347 requirement restores the original base GSS-API specified behavior, 348 with the addition of the ret_channel_bound_flag flag. 350 4. Security Considerations 352 This document deals with security. There are no security 353 considerations that should be documented separately in this section. 354 To recap, this document fixes a significant flaw in the base GSS-API 355 [RFC2743] specification that fortunately has not been implemented, 356 and it adds a feature (that should have been in the base 357 specification) for improved negotiation of use of channel binding 358 [RFC5056]. 360 5. IANA Considerations 362 Two GSS-API mechanism attributes are to be added to the "SMI Security 363 for Mechanism gsscma Codes" registry established by RFC5587 364 [RFC5587]. See Section 2.4. 366 6. References 368 6.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, 373 . 375 [RFC2743] Linn, J., "Generic Security Service Application Program 376 Interface Version 2, Update 1", RFC 2743, 377 DOI 10.17487/RFC2743, January 2000, 378 . 380 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 381 C-bindings", RFC 2744, DOI 10.17487/RFC2744, January 2000, 382 . 384 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 385 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 386 . 388 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 389 Inquiry APIs", RFC 5587, DOI 10.17487/RFC5587, July 2009, 390 . 392 6.2. Informative References 394 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 395 Simple and Protected Generic Security Service Application 396 Program Interface (GSS-API) Negotiation Mechanism", 397 RFC 4178, DOI 10.17487/RFC4178, October 2005, 398 . 400 [RFC5653] Upadhyay, M. and S. Malkani, "Generic Security Service API 401 Version 2: Java Bindings Update", RFC 5653, 402 DOI 10.17487/RFC5653, August 2009, 403 . 405 Authors' Addresses 407 Robbie Harwood 408 Red Hat, Inc. 410 Email: rharwood@redhat.com 412 Nicolas Williams 413 Cryptonector, LLC 415 Email: nico@cryptonector.com