Re: What am I waiting on for gs2?

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Thu, Dec 20, 2007 at 10:09:47AM -0500, Sam Hartman wrote:
> 
> >>>>> "Simon" == Simon Josefsson <simon@xxxxxxxxxxxxx> writes:
> 
>     >> The channel binding spec requires applications know about
>     >> channel binding failure.  You added text passing this
>     >> requirement along, but I don't see how your protocol allows the
>     >> client to detect channel binding failure.
>     >> 
>     >> We have c->m->s where m is a passive man in the middle that
>     >> joins the TLS stream.  So, the channel bindings are different.
>     >> C sends the gss_wrap to s using the same qop for channel
>     >> binding and non-channel binding.  How does s indicate to c that
>     >> the channel binding from s's standpoint is not the same as what
>     >> it received from c?
>     >> 
>     >> I think you need a bit (possibly as a flag bit xored in with
>     >> the qop) to indicate this.
> 
>     Simon> FYI, I had interpreted the requirement in RFC 5056:
> 
>     Simon>    o Authentication frameworks and mechanisms that support
>     Simon> channel binding MUST communicate channel binding failure to
>     Simon> applications.
> 
>     Simon> to mean that implementations must let the local
>     Simon> applications know about the situation.  That allows them to
>     Simon> abort the connection depending on local policy.  I didn't
>     Simon> read that to mean that protocols are required to notify the
>     Simon> other side of the situation.  The latter requirement is
>     Simon> stronger than the former.  I must admit that I don't see
>     Simon> why the stronger requirement is a useful one.
> 
> Hmm.  You may be right that I was reading more into RFC 5056 than is
> actually there.  In GS2 I'd prefer that we do indicate channel binding
> failure back because we don't generally want people to abort at least
> if they are willing to use a security layer instead.
> 
> However if the WG doesn't have consensus behind this change then it
> should be backed out.

I'd rather see that bit in the client/server's second wrap token, yes.