idnits 2.17.1 draft-ietf-kitten-channel-bound-flag-01.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 (March 30, 2017) is 2581 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) -- No information found for draft-williams-williams-kitten-ctx-simple-async - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KITTEN N. Williams 3 Internet-Draft Cryptonector 4 Updates: 2743, 2744 (if approved) March 30, 2017 5 Intended status: Standards Track 6 Expires: October 1, 2017 8 Channel Binding Signalling for the Generic Security Services Application 9 Programming Interface 10 draft-ietf-kitten-channel-bound-flag-01 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 that 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 http://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 October 1, 2017. 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 (http://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. Error in RFC2743 . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Alternative Design . . . . . . . . . . . . . . . . . . . . 4 70 1.4. Future Directions . . . . . . . . . . . . . . . . . . . . . 4 71 1.5. Conventions used in this document . . . . . . . . . . . . . 4 72 2. Channel Binding State Extension . . . . . . . . . . . . . . . 5 73 2.1. GSS_Create_sec_context() . . . . . . . . . . . . . . . . . 5 74 2.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 5 75 2.2. GSS_Set_context_flags() . . . . . . . . . . . . . . . . . . 6 76 2.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 6 77 2.3. Return Flag for Channel Binding State Signalling . . . . . 7 78 2.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 7 79 2.4. New Mechanism Attributes . . . . . . . . . . . . . . . . . 7 80 2.5. Request Flag for Acceptor Confirmation of Channel Binding . 7 81 2.5.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . 8 82 2.6. GSS_Delete_sec_context() Behavior When Applied to Empty 83 Security Contexts . . . . . . . . . . . . . . . . . . . . . 8 84 3. Modified Channel Binding Semantics . . . . . . . . . . . . . 8 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 87 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 89 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 92 1. Introduction 94 The GSS-API [RFC2743] supports "channel binding" [RFC5056], a 95 technique for detection of man-in-the-middle (MITM) attacks in secure 96 channels at lower network layers. This facility is meant to be all- 97 or-nothing: either both the initiator and acceptor use it and it 98 succeeds, or both must not use it. This has created a negotiation 99 problem when retrofitting the use of channel binding into existing 100 application protocols. 102 Many implementations of the Kerberos V5 GSS-API mechanism [RFC4121] 103 cause the acceptor to succeed when the initiator used channel binding 104 but the acceptor application did not. This has helped deployment of 105 channel binding in existing applications: first fix all the 106 initiators, then fix all the acceptors. But even this technique is 107 insufficient when there are many clients to fix, such that fixing 108 them all will take a long time. 110 This document proposes a new method for deployment of channel binding 111 that allows the feature to be enabled on the acceptor side before 112 fixing all initiators. If the GSS-API had always had a return flag 113 by which to indicate channel binding state then we could have had a 114 simpler method of deploying channel binding: applications check that 115 return flag and act accordingly (e.g., fail when channel binding is 116 required). We cannot safely introduce this behavior now without an 117 indication of support by the application. 119 It is worth noting that at least one implementor of GSS-API 120 mechanisms (but not of the GSS-API itself) has similar semantics in 121 its API to those proposed herein. [XXX add references to the 122 relevant SSPI docs? -Nico] 124 Additionally, there may be applications where it is important for 125 initiators to know that acceptors did use channel binding, and even 126 to know whether a mechanism is capable of indicating as much. We add 127 a request flag and two mechanism attributes for such applications. 129 1.1. Error in RFC2743 131 The GSS-APIv2u1 [RFC2743] seems to indicate that mechanisms must 132 ignore channel bindings when one party provided none. In practice 133 some mechanisms ignore channel bindings when the acceptor provides 134 none, but not when the initiator provides none. Note that it would 135 be useless to allow security context establishment to succeed when 136 the initiator does not provide channel bindings but the acceptor 137 does, at least as long as there's no outward indication of whether 138 channel binding was used! And indeed, the GSS-APIv2u1 does not 139 provide any such indication. We correct this flaw in this document. 141 1.2. Design 143 After some discussion on the mailing list of various designs for 144 signalling application support for the new flag we've settled on 145 copying an aspect of the Java Bindings of the GSS-API [RFC5653], 146 specifically the notion of creating an "empty" SECURITY CONTEXT 147 handle that can then be passed to GSS_Init_sec_context() and 148 GSS_Accept_sec_context() where they normally expect a NULL handle. 149 This empty security context handle can then be used to set options 150 relating to security context token establishment. 152 In [I-D.williams-williams-kitten-ctx-simple-async] we explore and 153 extend this design to produce a more usable GSS-API (as well as 154 support for asynchronous operation). 156 1.3. Alternative Design 158 An earlier design was based on an existing, non-standard extension 159 for carrying security context establishment options in CREDENTIAL 160 HANDLEs. A notion of CREDENTIAL HANDLE options might still be useful 161 for options that are really specific to credentials rather than 162 security context tokens, but for the time being we have no use for 163 such a thing. 165 1.4. Future Directions 167 We're likely to introduce additional mutator functions of empty 168 contexts, with mutators corresponding to many of the existing input 169 arguments of GSS_Init_sec_context() and GSS_Accept_sec_context(), as 170 well as a few additional security context inquiry functions. We're 171 also likely to then introduce new variants of GSS_Init_sec_context() 172 and GSS_Accept_sec_context() with all of those input and output 173 parameters removed that could be set or retrieved with the other new 174 functions. The only inputs that the new GSS_Init/ 175 Accept_sec_context() must have are: a security context handle (never 176 NULL), and an input context token, and the only outputs should be the 177 status indicators and an output token. In fact, we may want to have 178 just one new function called, perhaps, GSS_Step_sec_context(), with 179 the role of initiator or acceptor set as a context option. 181 See [I-D.williams-williams-kitten-ctx-simple-async]. 183 1.5. Conventions used in this document 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 2. Channel Binding State Extension 191 We propose a new return flag for GSS_Init_sec_context() and 192 GSS_Accept_sec_context(), as well as a pair of functions for a) 193 creating "empty" security context handles, b) setting req_flags and 194 indicating which ret_flags the application understands. We also add 195 new mechanism attributes describing mechanism capabilities. 197 C bindings of these extensions are provided along the lines of 198 [RFC2744] and [RFC5587]. 200 In the future we might move more of the many input (and output) 201 arguments to GSS_Init_sec_context() and GSS_Accept_sec_context() into 202 mutators on empty security context handles. 204 2.1. GSS_Create_sec_context() 206 Inputs: 208 o 210 Outputs: 212 o major_status INTEGER 214 o minor_status INTEGER -- note: mostly useless, but we should keep 215 it 217 o context SECURITY CONTEXT -- "empty" security context 219 Return major status codes: 221 o GSS_S_COMPLETE indicates success. 223 o GSS_S_UNAVAILABLE indicates that memory is not available, for 224 example. 226 o GSS_S_FAILURE indicates a general failure. 228 This function creates an "empty" security context handle that can be 229 passed to GSS_Init_sec_context() or GSS_Accept_sec_context() where 230 they expect a NULL context. 232 2.1.1. C-Bindings 234 OM_uint32 235 gss_create_sec_context(OM_uint32 *minor_status, 236 gss_ctx_id_t *context); 238 2.2. GSS_Set_context_flags() 240 Inputs: 242 context CONTEXT HANDLE 244 req_flags FLAGS Requested flags. Applicable to acceptors and 245 initiators. 247 ret_flags_understood FLAGS The set of return flags understood by the 248 caller. 250 Outputs: 252 o major_status INTEGER 254 o minor_status INTEGER 256 Return major status codes: 258 o GSS_S_COMPLETE indicates success. 260 o GSS_S_FAILURE indicates a general failure. 262 This function tells the mechanism (when one is eventually chosen and 263 invoked) that the application requests the given req_flags and 264 undestands the given ret_flags. Initiators can override the 265 req_flags in their GSS_Init_sec_context() call, but if no flags are 266 requested there then the req_flags set on the empty context will be 267 used. 269 NOTE: The abstract GSS-API [RFC2743] uses individual elements -one 270 per-flag- instead of a "FLAGS" type. This is unwieldy, therefore we 271 introduce an abstract type named "FLAGS" to act as a set of all the 272 request/return flags defined for the abstract GSS-API. 274 2.2.1. C-Bindings 276 OM_uint32 277 gss_set_context_flags(OM_uint32 *minor_status, 278 gss_ctx_id_t context, 279 uint64_t req_flags, 280 uint64_t ret_flags); 282 2.3. Return Flag for Channel Binding State Signalling 284 Whenever both the initiator and the acceptor provide matching channel 285 bindings to GSS_Init_sec_context() and GSS_Accept_sec_context(), 286 respectively, then the mechanism SHALL indicate that the context is 287 channel bound via an output flag, ret_channel_bound_flag, for the 288 established context. Note that some mechanisms have no way for the 289 acceptor to signal CB success to the initiator, in which case 290 GSS_Init_sec_context() MUST NOT output the ret_channel_bound_flag. 292 2.3.1. C-Bindings 294 #define GSS_C_CHANNEL_BOUND_FLAG 2048 /* 0x00000800 */ 296 2.4. New Mechanism Attributes 298 o We add a new mechanism attribute, GSS_C_MA_CBINDING_CONFIRM, to 299 indicate that the initiator can and always does learn whether the 300 acceptor application supplied channel bindings. Mechanisms 301 advertising this attribute MUST always indicate acceptor channel 302 bound state to the initiator. 304 o We add a new mechanism attribute, GSS_C_MA_CBINDING_MAY_CONFIRM, 305 to indicate that the initiator may learn whether the acceptor 306 application supplied channel bindings, but only when the acceptor 307 implementation of the mechanism has been suitably updated. 308 Mechanisms MUST advertise this attribute when the local initiator 309 functionality for acceptor channel bound state indication exists 310 but the acceptor may lack the same functionality (because, for 311 example, the mechanism predates this specification). 313 OID assignments TBD. 315 2.5. Request Flag for Acceptor Confirmation of Channel Binding 317 We add a new request flag for GSS_Init_sec_context(), 318 req_cb_confirmation_flag, to be used by initiators that insist on 319 acceptors providing channel bindings. This flag is only of use to 320 mechanism-negotiation pseudo-mechanisms (e.g., SPNEGO [RFC4178]): if 321 set the pseudo-mechanism MUST NOT negotiate any mechanisms that lack 322 the GSS_C_MA_CBINDING_CONFIRM or GSS_C_MA_CBINDING_MAY_CONFIRM 323 mechanism attributes, and SHOULD NOT negotiate mechanisms that lack 324 the GSS_C_MA_CBINDING_CONFIRM mechanism attribute (except if allowed 325 by local configuration). 327 2.5.1. C-Bindings 329 Because GSS_C_CHANNEL_BOUND_FLAG is a return flag only, and this flag 330 is a request flag only, and to save on precious flag bits, we use the 331 same flag bit assignment for both flags: 333 #define GSS_C_CB_CONFIRM_FLAG 2048 /* 0x00000800 */ 335 2.6. GSS_Delete_sec_context() Behavior When Applied to Empty Security 336 Contexts 338 GSS_Delete_sec_context() MUST NOT output a context deletion token 339 when applied to empty security contexts. 341 3. Modified Channel Binding Semantics 343 The channel binding semantics of the base GSS-API are modified as 344 follows: 346 o Whenever both, the initiator and acceptor shall have provided 347 input_channel_bindings to GSS_Init/Accept_sec_context() and the 348 channel bindings do not match, then the mechanism MUST fail to 349 establish a security context token. This is a restatement of an 350 existing requirement in the base specification, restated for the 351 reader's convenience. 353 o Whenever the acceptor application shall have a) provided channel 354 bindings to GSS_Accept_sec_context(), and b) not indicated support 355 for the ret_channel_bound_flag flag, then the mechanism MUST fail 356 to establish a security context if the initiator did not provide 357 channel bindings data. This requirement is critical for security 358 purposes, to make applications predating this document secure, and 359 this requirement reflects actual implementations as deployed. 361 o Whenever the initiator application shall have a) provided channel 362 bindings to GSS_Init_sec_context(), and b) not indicated support 363 for the ret_channel_bound_flag flag, then the mechanism SHOULD NOT 364 fail to establish a security context just because the acceptor 365 failed to provide channel bindings data. This recommendation is 366 for interoperability purposes, and reflects actual implementations 367 that have been deployed. It is possible that not all security 368 mechanism protocols can implement this requirement easily. 370 o Whenever the application shall have a) provided channel bindings 371 to GSS_Init_sec_context() or GSS_Accept_sec_context(), and b) 372 indicated support for the ret_channel_bound_flag flag, then the 373 mechanism MUST NOT fail to establish a security context just 374 because the peer did not provide channel bindings data. The 375 mechanism MUST output the ret_channel_bound_flag if both peers 376 provided the same input_channel_bindings to GSS_Init_sec_context() 377 and GSS_Accept_sec_context. The mechanism MUST NOT output the 378 ret_channel_bound_flag if either (or both) peer did not provide 379 input_channel_bindings to GSS_Init/Accept_sec_context(). This 380 requirement restores the original base GSS-API specified behavior, 381 with the addition of the ret_channel_bound_flag flag. 383 4. Security Considerations 385 This document deals with security. There are no security 386 considerations that should be documented separately in this section. 387 To recap, this document fixes a significant flaw in the base GSS-API 388 [RFC2743] specification that fortunately has not been implemented, 389 and it adds a feature (that should have been in the base 390 specification) for improved negotiation of use of channel binding 391 [RFC5056]. 393 5. IANA Considerations 395 Two GSS-API mechanism attributes are to be added to the "SMI Security 396 for Mechanism gsscma Codes" registry established by RFC5587 397 [RFC5587]. See Section 2.4. 399 6. References 401 6.1. Normative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 [RFC2743] Linn, J., "Generic Security Service Application Program 409 Interface Version 2, Update 1", RFC 2743, 410 DOI 10.17487/RFC2743, January 2000, 411 . 413 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 414 C-bindings", RFC 2744, DOI 10.17487/RFC2744, January 2000, 415 . 417 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 418 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 419 . 421 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 422 Inquiry APIs", RFC 5587, DOI 10.17487/RFC5587, July 2009, 423 . 425 6.2. Informative References 427 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 428 Version 5 Generic Security Service Application Program 429 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 430 DOI 10.17487/RFC4121, July 2005, 431 . 433 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 434 Simple and Protected Generic Security Service Application 435 Program Interface (GSS-API) Negotiation Mechanism", 436 RFC 4178, DOI 10.17487/RFC4178, October 2005, 437 . 439 [RFC5653] Upadhyay, M. and S. Malkani, "Generic Security Service API 440 Version 2: Java Bindings Update", RFC 5653, 441 DOI 10.17487/RFC5653, August 2009, 442 . 444 [I-D.williams-williams-kitten-ctx-simple-async] 445 Williams, N., "Simplified and Asynchronous Security 446 Context Interfaces for the Generic Security Services 447 Application Programming Interface", draft-williams- 448 williams-kitten-ctx-simple-async-00 (work in progress), 449 February 2013. 451 Author's Address 453 Nicolas Williams 454 Cryptonector, LLC 456 Email: nico@cryptonector.com