Re: Please review: http gss authentication mech

On Fri, Nov 10, 2006 at 04:19:42PM +0000, Tim Alsop wrote:
> > I am under the impression that the proposed SASL mechanism doesn't
> support channel
> > bindings, partially because channel bindings have been a notoriously
> difficult problem to get
> > right in SASL space. Personally I din't see the value of adding the
> extra layer of glue.
> 
> My understanding is that, if SASL is using GSS/Kerberos to protect HTTP
> communications, then GSS channel bindings can be used, so SASL does not
> need to have direct support for channel bindings. This is an advantage
> of using a multi-layered architecture.

Your understanding is wrong.

First of all, there's an API issue -- which, since the IETF does not
standardize a SASL API you might hand wave away.

Second, there's a semantic issue, and this is far more important.
Rather than re-hash this here you might want to look at the SASL WG
mailing list archives and the gs2 I-D (draft-ietf-sasl-gs2) and its
evolution.  Then you'll understand why GSS channel bindings in the SASL
"GSSAPI" mechanism are generally not usable.

Third, we need channel binding to TLS to avoid re-doing the GSS (or
SASL) authentication over and over, and so what's the point of using
SASL if the only SASL mechs that would support channel binding were the
GSS-based ones (using SASL/gs2)?  And if channel binding support is
added to SASL MD5-DIGEST, with the same semantics, can't we also add a
GSS-API mechanism that uses the same credentials as MD5-DIGEST?  And why
isn't HTTP MD5-DIGEST good enough anyways?  And what other SASL
mechanisms did you want to use with this?

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten