[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Channel Binding and GSS-API mechanisms
>>>>> "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
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
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
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
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.