[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What am I waiting on for gs2?
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.