idnits 2.17.00 (12 Aug 2021) /tmp/idnits23895/draft-ietf-kitten-channel-bound-flag-04.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 (February 5, 2019) is 1194 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: August 9, 2019 February 5, 2019 8 Channel Binding Signalling for the Generic Security Services Application 9 Programming Interface 10 draft-ietf-kitten-channel-bound-flag-04 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 August 9, 2019. 49 Copyright Notice 51 Copyright (c) 2019 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 Attribute . . . . . . . . . . . . . . . . . . 6 77 2.5. Request Flag for Acceptor Confirmation of Channel Binding . 6 78 2.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 6 79 2.6. Handling Empty Contexts in Other GSS-API Functions . . . . 6 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 . . . . . . . . . . . . . . . . . . 8 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 (such as Kerberos [RFC4121]) ignore channel bindings 101 when the acceptor provides none, but not when the initiator provides 102 none. Note that it would be useless to allow security context 103 establishment to succeed when the initiator does not provide channel 104 bindings but the acceptor does, at least as long as there's no 105 outward indication of whether channel binding was used! Since the 106 GSS-APIv2u1 does not provide any such indication, this document 107 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 a mechanism attribute 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 a 153 new mechanism attribute for supporting channel binding confirmation. 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 GSS_C_NO_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 Attribute 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 OID assignments TBD. 268 2.5. Request Flag for Acceptor Confirmation of Channel Binding 270 We add a new request flag for GSS_Init_sec_context(), 271 req_cb_confirmation_flag, to be used by initiators that insist on 272 acceptors providing channel bindings. If set, the mechanism MUST 273 prefer establishment of contexts which provide channel binding 274 confirmation. It SHOULD NOT fail to negotiate just because it cannot 275 provide the GSS_C_MA_CBINDING_CONFIRM attribute. 277 2.5.1. C-Bindings 279 Because GSS_C_CHANNEL_BOUND_FLAG is a return flag only, and this flag 280 is a request flag only, and to save on precious flag bits, we use the 281 same flag bit assignment for both flags: 283 #define GSS_C_CB_CONFIRM_FLAG 2048 /* 0x00000800 */ 285 2.6. Handling Empty Contexts in Other GSS-API Functions 287 GSS_Init_sec_context() and GSS_Accept_sec_context() operate on empty 288 security contexts as specified above (i.e., examining flags). 290 All other GSS-API functions MUST treat empty contexts as they would 291 GSS_C_NO_CONTEXT as well. For most functions, this will result in 292 returning GSS status code GSS_S_NO_CONTEXT. 294 GSS_Delete_sec_context() MUST NOT output a context deletion token 295 when applied to empty security contexts. 297 3. Modified Channel Binding Semantics 299 The channel binding semantics of the base GSS-API are modified as 300 follows: 302 o Whenever both the initiator and acceptor have provided 303 input_channel_bindings to GSS_Init/Accept_sec_context() and the 304 channel bindings do not match, then the mechanism MUST fail to 305 establish a security context token. (This is a restatement of an 306 existing requirement in the base specification.) 308 o Whenever the acceptor application has a) provided channel bindings 309 to GSS_Accept_sec_context(), and b) not indicated support for the 310 ret_channel_bound_flag flag, then the mechanism MUST fail to 311 establish a security context if the initiator did not provide 312 channel bindings data. This requirement is critical for security 313 purposes, to make applications predating this document secure, and 314 this requirement reflects actual implementations as deployed. 316 o Whenever the initiator application has a) provided channel 317 bindings to GSS_Init_sec_context(), and b) not indicated support 318 for the ret_channel_bound_flag flag, then the mechanism SHOULD NOT 319 fail to establish a security context just because the acceptor 320 failed to provide channel bindings data. This strong sugestion is 321 for interoperability purposes, and reflects actual implementations 322 that have been deployed. 324 o Whenever the application has a) provided channel bindings to 325 GSS_Init_sec_context() or GSS_Accept_sec_context(), and b) 326 indicated support for the ret_channel_bound_flag flag, then the 327 mechanism SHOULD NOT fail to establish a security context just 328 because the peer did not provide channel bindings data. The 329 mechanism MUST output the ret_channel_bound_flag if both peers 330 provided the same input_channel_bindings to GSS_Init_sec_context() 331 and GSS_Accept_sec_context(). The mechanism MUST NOT output the 332 ret_channel_bound_flag if either (or both) peer did not provide 333 input_channel_bindings to GSS_Init/Accept_sec_context(). This 334 requirement restores the original base GSS-API specified behavior, 335 with the addition of the ret_channel_bound_flag flag. 337 4. Security Considerations 339 This document deals with security. There are no security 340 considerations that should be documented separately in this section. 341 To recap, this document fixes a significant flaw in the base GSS-API 342 [RFC2743] specification that fortunately has not been implemented, 343 and it adds a feature (that should have been in the base 344 specification) for improved negotiation of use of channel binding 345 [RFC5056]. 347 5. IANA Considerations 349 The GSS-API mechanism attribute is to be added to the "SMI Security 350 for Mechanism gsscma Codes" registry established by RFC5587 351 [RFC5587]. See Section 2.4. 353 6. References 355 6.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 [RFC2743] Linn, J., "Generic Security Service Application Program 363 Interface Version 2, Update 1", RFC 2743, 364 DOI 10.17487/RFC2743, January 2000, 365 . 367 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 368 C-bindings", RFC 2744, DOI 10.17487/RFC2744, January 2000, 369 . 371 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 372 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 373 . 375 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 376 Inquiry APIs", RFC 5587, DOI 10.17487/RFC5587, July 2009, 377 . 379 6.2. Informative References 381 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 382 Version 5 Generic Security Service Application Program 383 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 384 DOI 10.17487/RFC4121, July 2005, 385 . 387 [RFC5653] Upadhyay, M. and S. Malkani, "Generic Security Service API 388 Version 2: Java Bindings Update", RFC 5653, 389 DOI 10.17487/RFC5653, August 2009, 390 . 392 Authors' Addresses 394 Robbie Harwood 395 Red Hat, Inc. 397 Email: rharwood@redhat.com 399 Nicolas Williams 400 Cryptonector, LLC 402 Email: nico@cryptonector.com