RE: Please review: http gss authentication mech

"Tim Alsop" <Tim.Alsop@CyberSafe.Com> Thu, 16 November 2006 22:03 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkpKR-0006DU-3N; Thu, 16 Nov 2006 17:03:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkpKP-0006D3-Sm for kitten@ietf.org; Thu, 16 Nov 2006 17:03:25 -0500
Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkpKO-0007MN-Fd for kitten@ietf.org; Thu, 16 Nov 2006 17:03:25 -0500
Received: from rly37b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly37b.srv.mailcontrol.com (MailControl) with ESMTP id kAGM3JI0001642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <kitten@ietf.org>; Thu, 16 Nov 2006 22:03:21 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly37b.srv.mailcontrol.com (MailControl) id kAGM2wZ8000786 for kitten@ietf.org; Thu, 16 Nov 2006 22:02:58 GMT
Received: from cybersafe.ltd.uk (dsl-212-23-30-205.zen.co.uk [212.23.30.205]) by rly37b-eth0.srv.mailcontrol.com (envelope-sender Tim.Alsop@CyberSafe.Com) (MIMEDefang) with ESMTP id kAGM2rBr000613; Thu, 16 Nov 2006 22:02:58 +0000 (GMT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 16 Nov 2006 22:02:52 -0000
Message-ID: <0D8F2EFD3A10E24DAEEA48EA6DA07D30299598@postman-pat.csafe.local>
In-Reply-To: <20061116214952.GU25646@binky.Central.Sun.COM>
From: Tim Alsop <Tim.Alsop@CyberSafe.Com>
To: Nicolas Williams <Nicolas.Williams@sun.com>
X-Scanned-By: MailControl A-07-06-75 (www.mailcontrol.com) on 10.66.1.147
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: Kitten <kitten@ietf.org>, Lisa Dusseault <lisa@osafoundation.org>
Subject: RE: Please review: http gss authentication mech
X-BeenThere: kitten@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kitten>
List-Post: <mailto:kitten@lists.ietf.org>
List-Help: <mailto:kitten-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=subscribe>
Errors-To: kitten-bounces@lists.ietf.org

Nico,

Thankyou for correcting me, on my assumption related to channel
bindings.

Regards,
Tim 

-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] 
Sent: 16 November 2006 21:50
To: Tim Alsop
Cc: Leif Johansson; Kitten; Lisa Dusseault
Subject: 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