One document matched: draft-williams-kitten-channel-bound-flag-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2743 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml">
<!ENTITY rfc2744 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2744.xml">
<!ENTITY rfc5056 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml">
<!ENTITY rfc5587 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5587.xml">
<!ENTITY rfc4121 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4121.xml">
<!ENTITY rfc5653 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5653.xml">
]>
<rfc docName="draft-williams-kitten-channel-bound-flag-02" ipr="trust200902" category="std" updates="RFC2743 RFC2744">
<front>
<title abbrev="GSS Channel Bound Flag">Channel Binding Signalling for the Generic Security Services Application Programming Interface</title>
<author initials="N." surname="Williams" fullname="Nicolas Williams">
<organization abbrev="Cryptonector">Cryptonector, LLC</organization>
<address>
<email>nico@cryptonector.com</email>
</address>
</author>
<date month="February" year="2013"/>
<area>
Security Area
</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
This Internet-Draft proposes the addition of a “channel bound” return flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() functions. Two behaviors are specified: a default, safe behavior, and a behavior that is only safe when the application specifically tells the Generic Security Services Application Programming Interface (GSS-API) that it (the applicaiton) supports the new behavior.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="d1e252">
<t>
The GSS-API <xref target="RFC2743"/> supports “channel binding” <xref target="RFC5056"/>, a technique for detection of man-in-the-middle (MITM) attacks in secure channels at lower network layers. This facility is meant to be all-or-nothing: either both the initiator and acceptor use it and it succeeds, or both must not use it. This has created a negotiation problem when retrofitting the use of channel binding into existing application protocols.</t>
<t>
Many implementations of the Kerberos V5 GSS-API mechanism <xref target="RFC4121"/> cause the acceptor to succeed when the initiator used channel binding but the acceptor application did not. This has helped deployment of channel binding in existing applications: first fix all the initiators, then fix all the acceptors. But even this is insufficient when there are many clients to fix, such that fixing them all will take a long time.</t>
<t>
This document proposes a new method for deployment of channel binding that allows the feature to be enabled on the acceptor side before fixing all initiators. If the GSS-API had always had a return flag by which to indicate channel binding state then we could have had a simpler method of deploying channel binding: applications check that return flag and act accordingly (e.g., fail when channel binding is required). We cannot safely introduce this behavior now without an indication of support by the application.</t>
<t>
It is worth noting that at least one implementor of GSS-API mechanisms (but not of the GSS-API itself) has similar semantics in its API to those proposed herein. [XXX add references to the relevant SSPI docs? -Nico]</t>
<section title="Error in RFC2743" anchor="d1e289">
<t>
The GSS-APIv2u1 <xref target="RFC2743"/> seems to indicate that mechanisms must ignore channel bindings when one party provided none. In practice some mechanisms ignore channel bindings when the acceptor provides none, but not when the initiator provides none. Note that it would be useless to allow security context establishment to succeed when the initiator does not provide channel bindings but the acceptor does, at least as long as there's no outward indication of whether channel binding was used! And indeed, the GSS-APIv2u1 does not provide any such indication. We correct this flaw in this document.</t>
</section>
<section title="Design" anchor="d1e304">
<t>
After some discussion on the mailing list of various designs for signalling application support for the new flag we've settled on copying an aspect of the Java Bindings of the GSS-API <xref target="RFC5653"/>, specifically the notion of creating an “empty” SECURITY CONTEXT handle that can then be passed to GSS_Init_sec_context() and GSS_Accept_sec_context() where they normally expect a NULL handle. This empty security context handle can then be used to set options relating to security context token establishment.</t>
</section>
<section title="Alternative Design" anchor="d1e319">
<t>
The previous design was based on an existing, non-standard extension for carrying security context establishment options in CREDENTIAL HANDLEs. Note that a notion of CREDENTIAL HANDLE options might still be useful for options that are really specific to credentials rather than security context tokens (for example: setting an acceptable cryptographic security profile on a CREDENTIAL HANDLE and receiving a new handle with possibly fewer elements, reflecting that some credentials cannot meet the requirement).</t>
</section>
<section title="Future Directions" anchor="d1e328">
<t>
We're likely to introduce additional mutator functions of empty contexts, with mutators corresponding to many of the existing input arguments of GSS_Init_sec_context() and GSS_Accept_sec_context(), as well as a few additional security context inquiry functions. We're also likely to then introduce new variants of GSS_Init_sec_context() and GSS_Accept_sec_context() with all of those input and output parameters removed that could be set or retrieved with the other new functions. The only inputs that the new GSS_Init/Accept_sec_context() must have are: a security context handle (never NULL), and an input context token, and the only outputs should be the status indicators and an output token -- in fact, we may want to have just one new function called, perhaps, GSS_Step_sec_context(), with the role of initiator or acceptor set as a context option.</t>
</section>
<section title="Conventions used in this document" anchor="d1e337">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Channel Binding State Extension" anchor="d1e353">
<t>
We propose a new return flag for GSS_Init_sec_context() and GSS_Accept_sec_context(), as well as a pair of functions for setting a) creating “empty” security context handles, b) setting req_flags and indicating which ret_flags the application understands. </t>
<t>
C bindings of these extensions are provided along the lines of <xref target="RFC2744"/> and <xref target="RFC5587"/>.</t>
<t>
In the future we might move more of the many input (and output) arguments to GSS_Init_sec_context() and GSS_Accept_sec_context() into mutators on empty security context handles.</t>
<section title="GSS_Create_sec_context()" anchor="d1e380">
<t>
Inputs:</t>
<t>
<list style="symbols">
<t>
<none></t>
</list>
</t>
<t>
Outputs:</t>
<t>
<list style="symbols">
<t>
major_status INTEGER</t>
<t>
minor_status INTEGER -- note: mostly useless, but we should keep it</t>
<t>
context SECURITY CONTEXT</t>
</list>
</t>
<t>
Return major status codes:</t>
<t>
<list style="symbols">
<t>
GSS_S_COMPLETE indicates success.</t>
<t>
GSS_S_UNAVAILABLE indicates that memory is not available, for example.</t>
<t>
GSS_S_FAILURE indicates a general failure.</t>
</list>
</t>
<t>
This function creates an “empty” security context handle that can be passed to GSS_Init_sec_context() or GSS_Accept_sec_context() where they expect a NULL context.</t>
<section title="C-Bindings" anchor="d1e423">
<t>
</t>
<t>
<figure anchor="magicparlabel-146" title="C-Bindings of GSS_Create_sec_context()">
<artwork> OM_uint32
gss_create_sec_context(OM_uint32 *minor_status,
gss_ctx_id_t *context);</artwork>
</figure>
</t>
</section>
</section>
<section title="GSS_Set_context_flags()" anchor="d1e451">
<t>
Inputs:</t>
<t>
<list style="hanging">
<t hangText="context CONTEXT HANDLE">
</t>
<t hangText="req_flags FLAGS">
Requested flags. Applicable to acceptors and initiators.</t>
<t hangText="ret_flags_understood FLAGS">
Return flags understood by the caller.</t>
</list>
</t>
<t>
Outputs:</t>
<t>
<list style="symbols">
<t>
major_status INTEGER</t>
<t>
minor_status INTEGER</t>
</list>
</t>
<t>
Return major status codes:</t>
<t>
<list style="symbols">
<t>
GSS_S_COMPLETE indicates success.</t>
<t>
GSS_S_FAILURE indicates a general failure.</t>
</list>
</t>
<t>
This function tells the mechanism (when one is eventually chosen and invoked) that the application requests the given req_flags and undestands the given ret_flags. Initiators can override the req_flags in their GSS_Init_sec_context() call, but if no flags are requested there then the req_flags set on the empty context will be used.</t>
<t>
NOTE: The abstract GSS-API <xref target="RFC2743"/> uses individual elements -one per-flag- instead of a “FLAGS” type. This is unwieldy, therefore we introduce an abstract type named “FLAGS” to act as a set of all the request/return flags defined for the abstract GSS-API.</t>
<section title="C-Bindings" anchor="d1e509">
<t>
</t>
<t>
<figure anchor="magicparlabel-182" title="C-Bindings of GSS_Set_context_flags()">
<artwork> OM_uint32
gss_set_context_flags(OM_uint32 *minor_status,
gss_ctx_id_t context,
uint64_t req_flags,
uint64_t ret_flags);</artwork>
</figure>
</t>
</section>
</section>
<section title="Return Flag for Channel Binding State Signalling" anchor="d1e537">
<t>
Whenever both the initiator and the acceptor provide matching channel bindings to GSS_Init_sec_context() and GSS_Accept_sec_context(), respectively, then the mechanism SHALL indicate that the context is channel bound via an output flag, ret_channel_bound_flag, for the established context.</t>
<section title="C-Bindings" anchor="d1e546">
<t>
</t>
<t>
<figure anchor="magicparlabel-199" title="C-Bindings of channel_bound_flag">
<artwork> #define GSS_C_CHANNEL_BOUND_FLAG 2048 /* 0x00000800 */</artwork>
</figure>
</t>
</section>
</section>
</section>
<section title="Modified Channel Binding Semantics" anchor="d1e574">
<t>
The channel binding semantics of the base GSS-API are modified as follows:</t>
<t>
<list style="symbols">
<t>
Whenever both, the initiator and acceptor shall have provided input_channel_bindings to GSS_Init/Accept_sec_context() and the channel bindings do not match, then the mechanism MUST fail to establish a security context token. This is a restatement of an existing requirement in the base specification, restated for convenience.</t>
<t>
Whenever the acceptor application shall have a) provided channel bindings to GSS_Accept_sec_context(), and b) not indicated support for the ret_channel_bound_flag flag, then the mechanism MUST fail to establish a security context if the initiator did not provide channel bindings data. This requirement is for security purposes, to make applications predating this document secure, and this requirement reflects actual implementations as deployed.</t>
<t>
Whenever the initiator application shall have a) provided channel bindings to GSS_Init_sec_context(), and b) not indicated support for the ret_channel_bound_flag flag, then the mechanism SHOULD NOT fail to establish a security context just because the acceptor failed to provide channel bindings data. This recommendation is for interoperability purposes, and reflects actual implementations that have been deployed. It is possible that not all security mechanism protocols can implement this requirement easily.</t>
<t>
Whenever the application shall have a) provided channel bindings to GSS_Init_sec_context() or GSS_Accept_sec_context(), and b) indicated support for the ret_channel_bound_flag flag, then the mechanism MUST NOT fail to establish a security context just because the peer did not provide channel bindings data. The mechanism MUST output the ret_channel_bound_flag if both peers provided the same input_channel_bindings to GSS_Init_sec_context() and GSS_Accept_sec_context. The mechanism MUST NOT output the ret_channel_bound_flag if either (or both) peer did not provide input_channel_bindings to GSS_Init/Accept_sec_context(). This requirement restores the original base GSS-API specified behavior, with the addition of the ret_channel_bound_flag flag</t>
</list>
</t>
</section>
<section title="Security Considerations" anchor="d1e597">
<t>
This document deals with security. There are no security considerations that should be documented separately in this section. To recap, this document fixes a significant flaw in the base GSS-API <xref target="RFC2743"/> specification that fortunately has not been implemented, and it adds a feature (that should have been in the base specification) for improved negotiation of use of channel binding <xref target="RFC5056"/>.</t>
</section>
<section title="IANA Considerations" anchor="d1e618">
<t>
This document has no IANA considerations.</t>
</section>
</middle>
<back>
<references title="Normative References">&rfc2119;
&rfc2743;
&rfc2744;
&rfc5056;
&rfc5587;
</references>
<references title="Informative References">&rfc4121;
&rfc5653;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:13:41 |