idnits 2.17.1 draft-williams-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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2013) is 4053 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 (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Williams 3 Internet-Draft Cryptonector 4 Updates: RFC2743 RFC2744 February 22, 2013 5 (if approved) 6 Intended status: Standards Track 7 Expires: August 26, 2013 9 Channel Binding Signalling for the Generic Security Services Application 10 Programming Interface 11 draft-williams-kitten-channel-bound-flag-02 13 Abstract 15 This Internet-Draft proposes the addition of a "channel bound" return 16 flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() 17 functions. Two behaviors are specified: a default, safe behavior, 18 and a behavior that is only safe when the application specifically 19 tells the Generic Security Services Application Programming Interface 20 (GSS-API) that it (the applicaiton) supports the new behavior. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 26, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Error in RFC2743 . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.3. Alternative Design . . . . . . . . . . . . . . . . . . . . 4 60 1.4. Future Directions . . . . . . . . . . . . . . . . . . . . 4 61 1.5. Conventions used in this document . . . . . . . . . . . . 4 62 2. Channel Binding State Extension . . . . . . . . . . . . . 5 63 2.1. GSS_Create_sec_context() . . . . . . . . . . . . . . . . . 5 64 2.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. GSS_Set_context_flags() . . . . . . . . . . . . . . . . . 6 66 2.2.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.3. Return Flag for Channel Binding State Signalling . . . . . 7 68 2.3.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Modified Channel Binding Semantics . . . . . . . . . . . . 8 70 4. Security Considerations . . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 74 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 75 Author's Address . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 The GSS-API [RFC2743] supports "channel binding" [RFC5056], a 80 technique for detection of man-in-the-middle (MITM) attacks in secure 81 channels at lower network layers. This facility is meant to be all- 82 or-nothing: either both the initiator and acceptor use it and it 83 succeeds, or both must not use it. This has created a negotiation 84 problem when retrofitting the use of channel binding into existing 85 application protocols. 87 Many implementations of the Kerberos V5 GSS-API mechanism [RFC4121] 88 cause the acceptor to succeed when the initiator used channel binding 89 but the acceptor application did not. This has helped deployment of 90 channel binding in existing applications: first fix all the 91 initiators, then fix all the acceptors. But even this is 92 insufficient when there are many clients to fix, such that fixing 93 them all will take a long time. 95 This document proposes a new method for deployment of channel binding 96 that allows the feature to be enabled on the acceptor side before 97 fixing all initiators. If the GSS-API had always had a return flag 98 by which to indicate channel binding state then we could have had a 99 simpler method of deploying channel binding: applications check that 100 return flag and act accordingly (e.g., fail when channel binding is 101 required). We cannot safely introduce this behavior now without an 102 indication of support by the application. 104 It is worth noting that at least one implementor of GSS-API 105 mechanisms (but not of the GSS-API itself) has similar semantics in 106 its API to those proposed herein. [XXX add references to the 107 relevant SSPI docs? -Nico] 109 1.1. Error in RFC2743 111 The GSS-APIv2u1 [RFC2743] seems to indicate that mechanisms must 112 ignore channel bindings when one party provided none. In practice 113 some mechanisms ignore channel bindings when the acceptor provides 114 none, but not when the initiator provides none. Note that it would 115 be useless to allow security context establishment to succeed when 116 the initiator does not provide channel bindings but the acceptor 117 does, at least as long as there's no outward indication of whether 118 channel binding was used! And indeed, the GSS-APIv2u1 does not 119 provide any such indication. We correct this flaw in this document. 121 1.2. Design 123 After some discussion on the mailing list of various designs for 124 signalling application support for the new flag we've settled on 125 copying an aspect of the Java Bindings of the GSS-API [RFC5653], 126 specifically the notion of creating an "empty" SECURITY CONTEXT 127 handle that can then be passed to GSS_Init_sec_context() and 128 GSS_Accept_sec_context() where they normally expect a NULL handle. 129 This empty security context handle can then be used to set options 130 relating to security context token establishment. 132 1.3. Alternative Design 134 The previous design was based on an existing, non-standard extension 135 for carrying security context establishment options in CREDENTIAL 136 HANDLEs. Note that a notion of CREDENTIAL HANDLE options might still 137 be useful for options that are really specific to credentials rather 138 than security context tokens (for example: setting an acceptable 139 cryptographic security profile on a CREDENTIAL HANDLE and receiving a 140 new handle with possibly fewer elements, reflecting that some 141 credentials cannot meet the requirement). 143 1.4. Future Directions 145 We're likely to introduce additional mutator functions of empty 146 contexts, with mutators corresponding to many of the existing input 147 arguments of GSS_Init_sec_context() and GSS_Accept_sec_context(), as 148 well as a few additional security context inquiry functions. We're 149 also likely to then introduce new variants of GSS_Init_sec_context() 150 and GSS_Accept_sec_context() with all of those input and output 151 parameters removed that could be set or retrieved with the other new 152 functions. The only inputs that the new GSS_Init/ 153 Accept_sec_context() must have are: a security context handle (never 154 NULL), and an input context token, and the only outputs should be the 155 status indicators and an output token -- in fact, we may want to have 156 just one new function called, perhaps, GSS_Step_sec_context(), with 157 the role of initiator or acceptor set as a context option. 159 1.5. Conventions used in this document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 2. Channel Binding State Extension 167 We propose a new return flag for GSS_Init_sec_context() and 168 GSS_Accept_sec_context(), as well as a pair of functions for setting 169 a) creating "empty" security context handles, b) setting req_flags 170 and indicating which ret_flags the application understands. 172 C bindings of these extensions are provided along the lines of 173 [RFC2744] and [RFC5587]. 175 In the future we might move more of the many input (and output) 176 arguments to GSS_Init_sec_context() and GSS_Accept_sec_context() into 177 mutators on empty security context handles. 179 2.1. GSS_Create_sec_context() 181 Inputs: 183 o 185 Outputs: 187 o major_status INTEGER 189 o minor_status INTEGER -- note: mostly useless, but we should keep 190 it 192 o context SECURITY CONTEXT 194 Return major status codes: 196 o GSS_S_COMPLETE indicates success. 198 o GSS_S_UNAVAILABLE indicates that memory is not available, for 199 example. 201 o GSS_S_FAILURE indicates a general failure. 203 This function creates an "empty" security context handle that can be 204 passed to GSS_Init_sec_context() or GSS_Accept_sec_context() where 205 they expect a NULL context. 207 2.1.1. C-Bindings 208 OM_uint32 209 gss_create_sec_context(OM_uint32 *minor_status, 210 gss_ctx_id_t *context); 212 Figure 1: C-Bindings of GSS_Create_sec_context() 214 2.2. GSS_Set_context_flags() 216 Inputs: 218 context CONTEXT HANDLE 220 req_flags FLAGS Requested flags. Applicable to acceptors and 221 initiators. 223 ret_flags_understood FLAGS Return flags understood by the caller. 225 Outputs: 227 o major_status INTEGER 229 o minor_status INTEGER 231 Return major status codes: 233 o GSS_S_COMPLETE indicates success. 235 o GSS_S_FAILURE indicates a general failure. 237 This function tells the mechanism (when one is eventually chosen and 238 invoked) that the application requests the given req_flags and 239 undestands the given ret_flags. Initiators can override the 240 req_flags in their GSS_Init_sec_context() call, but if no flags are 241 requested there then the req_flags set on the empty context will be 242 used. 244 NOTE: The abstract GSS-API [RFC2743] uses individual elements -one 245 per-flag- instead of a "FLAGS" type. This is unwieldy, therefore we 246 introduce an abstract type named "FLAGS" to act as a set of all the 247 request/return flags defined for the abstract GSS-API. 249 2.2.1. C-Bindings 250 OM_uint32 251 gss_set_context_flags(OM_uint32 *minor_status, 252 gss_ctx_id_t context, 253 uint64_t req_flags, 254 uint64_t ret_flags); 256 Figure 2: C-Bindings of GSS_Set_context_flags() 258 2.3. Return Flag for Channel Binding State Signalling 260 Whenever both the initiator and the acceptor provide matching channel 261 bindings to GSS_Init_sec_context() and GSS_Accept_sec_context(), 262 respectively, then the mechanism SHALL indicate that the context is 263 channel bound via an output flag, ret_channel_bound_flag, for the 264 established context. 266 2.3.1. C-Bindings 268 #define GSS_C_CHANNEL_BOUND_FLAG 2048 /* 0x00000800 */ 270 Figure 3: C-Bindings of channel_bound_flag 272 3. Modified Channel Binding Semantics 274 The channel binding semantics of the base GSS-API are modified as 275 follows: 277 o Whenever both, the initiator and acceptor shall have provided 278 input_channel_bindings to GSS_Init/Accept_sec_context() and the 279 channel bindings do not match, then the mechanism MUST fail to 280 establish a security context token. This is a restatement of an 281 existing requirement in the base specification, restated for 282 convenience. 284 o Whenever the acceptor application shall have a) provided channel 285 bindings to GSS_Accept_sec_context(), and b) not indicated support 286 for the ret_channel_bound_flag flag, then the mechanism MUST fail 287 to establish a security context if the initiator did not provide 288 channel bindings data. This requirement is for security purposes, 289 to make applications predating this document secure, and this 290 requirement reflects actual implementations as deployed. 292 o Whenever the initiator application shall have a) provided channel 293 bindings to GSS_Init_sec_context(), and b) not indicated support 294 for the ret_channel_bound_flag flag, then the mechanism SHOULD NOT 295 fail to establish a security context just because the acceptor 296 failed to provide channel bindings data. This recommendation is 297 for interoperability purposes, and reflects actual implementations 298 that have been deployed. It is possible that not all security 299 mechanism protocols can implement this requirement easily. 301 o Whenever the application shall have a) provided channel bindings 302 to GSS_Init_sec_context() or GSS_Accept_sec_context(), and b) 303 indicated support for the ret_channel_bound_flag flag, then the 304 mechanism MUST NOT fail to establish a security context just 305 because the peer did not provide channel bindings data. The 306 mechanism MUST output the ret_channel_bound_flag if both peers 307 provided the same input_channel_bindings to GSS_Init_sec_context() 308 and GSS_Accept_sec_context. The mechanism MUST NOT output the 309 ret_channel_bound_flag if either (or both) peer did not provide 310 input_channel_bindings to GSS_Init/Accept_sec_context(). This 311 requirement restores the original base GSS-API specified behavior, 312 with the addition of the ret_channel_bound_flag flag 314 4. Security Considerations 316 This document deals with security. There are no security 317 considerations that should be documented separately in this section. 318 To recap, this document fixes a significant flaw in the base GSS-API 319 [RFC2743] specification that fortunately has not been implemented, 320 and it adds a feature (that should have been in the base 321 specification) for improved negotiation of use of channel binding 322 [RFC5056]. 324 5. IANA Considerations 326 This document has no IANA considerations. 328 6. References 330 6.1. Normative References 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, March 1997. 335 [RFC2743] Linn, J., "Generic Security Service Application Program 336 Interface Version 2, Update 1", RFC 2743, January 2000. 338 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 339 C-bindings", RFC 2744, January 2000. 341 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 342 Channels", RFC 5056, November 2007. 344 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 345 Inquiry APIs", RFC 5587, July 2009. 347 6.2. Informative References 349 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 350 Version 5 Generic Security Service Application Program 351 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 352 July 2005. 354 [RFC5653] Upadhyay, M. and S. Malkani, "Generic Security Service API 355 Version 2: Java Bindings Update", RFC 5653, August 2009. 357 Author's Address 359 Nicolas Williams 360 Cryptonector, LLC 362 Email: nico@cryptonector.com