Re: Channel Binding and GSS-API mechanisms

[Sam Hartman <hartmans-ietf@xxxxxxx>]

>>>>> "Simon" == Simon Josefsson <simon@xxxxxxxxxxxxx> writes:

    Simon> Sam Hartman <hartmans-ietf@xxxxxxx> writes:
    >> Folks, a couple of odd consequences of how GS2 and channel
    >> binding interact came to me during the meeting and I want to
    >> make sure we're aware of them and agree they are OK.
    >> 
    >> First, if you have a channel binding that requires
    >> confidentiality for a channel that does not provide
    >> confidentiality you cannot use it with GS2.  Honestly I don't
    >> consider this a big deal because I cannot think of any reason
    >> you'd define such a channel binding.  It seems like such a bad
    >> idea I'd hope that the expert would decline the registration.
    >> If we do find a channel where this is the right solutionwe'll
    >> have some work to do.

    Simon> There is a security consideration in GS2 about this:

    Simon>    The channel binding is sent without privacy protection
    Simon> and knowledge of it is assumed to provide no advantage to
    Simon> an attacker.  This is a property that has to be considered
    Simon> when specifying channel bindings for a security protocol
    Simon> that will be used with GS2.

    Simon> Is there anything else the document could say, or is this
    Simon> sufficient?

No, I think the doc is fine.
The question is whether the WG is OK with that consequence.
My personal recommendation is no change in this area.

    >> The second problem is more concerning.  The way GS2 handles
    >> channel bindings makes it a bit tricky for things that want to
    >> be both a SASL mechanism and a GSS-API mechanism.  GS2 does not
    >> use the GSS-API binding facility.  It instead uses a wrap
    >> token.  So, you'll need to define a wrap token for your
    >> mechanism.

    Simon> I don't think that is required, see section 4.3.1 of GS2:

    Simon> 4.3.1.  The GS2_Wrap function

    Simon>    The GS2_Wrap function have two implementations, and
    Simon> which one is used depends on whether the negotiated GSS-API
    Simon> context supports per- message protection.  When a context
    Simon> is successfully negotiated (i.e., when GSS_S_COMPLETE is
    Simon> returned from, for clients, GSS_Init_sec_context, or, for
    Simon> servers, GSS_Accept_sec_context) and the output variable
    Simon> integ_avail is FALSE, then GSS_Wrap cannot be used and
    Simon> instead we define GS2_Wrap to be the identity function.
    Simon> When integ_avail is negotiated TRUE, the GS2_Wrap is
    Simon> identical to calling the GSS_Wrap function with conf_flag
    Simon> set to FALSE and using the generated output_message as the
    Simon> output data.

    Simon> The rest of the document uses GS2_Wrap, not GSS_Wrap.

You cannot use channel binding with contexts that do not have
integ_avail.

So, if you are going to design a SASL mechanism as a GSS-API mechanism
and want channel binding to work, you must provide gss_wrap with
integrity tokens.

The GS2 document explains why we made that design decision.  I
understand and agree with that explanation.  I just want to make sure
the WG is aware of the consequences.