Re: SCRAM with(out) GS2 (was Re: Holding gs2)

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Wed, Jan 30, 2008 at 12:21:08PM +0100, Arnt Gulbrandsen wrote:
> Chris Newman writes:
> >I would personally have no problem implementing an all-binary SCRAM 
> >regardless of how ugly the ASN.1 and binary encoding happens to be 
> >(it just requires more lines of parsing code since I have to include 
> >all the binary->text logic for debugging).
> 
> My two cents: I want SCRAM as a replacement for Digest-MD5 and to some 
> degree Cram-MD5. That may not be a good reason, but it's mine, and I 
> worry that GS2 hurts rather than helps.
> 
> As I see it, the people I want to implement SCRAM have Cram-MD5 and/or 
> (bad) Digest-MD5 implementations, and most of them don't have 
> GSS-API/GS2 implementations. For these people, basing SCRAM on GS2 
> means that they must read and understand more RFC text and their 
> implementations will be more complex. Chris has no problem with that, 
> but I fear that many people do. More text to read and understand means 
> a greater reluctance to implement, and in turn a slower pace of 
> adoption. More complexity means worse interoperation.

We can deal with this, and we've already agreed to, by providing two
descriptions of the mechanism, one without reference to the GSS-API nor
GS2, and one with.

The simplified GS2 option we've been discussing would make that task
much, much easier, and would make the design of SCRAM much simpler also.

Thus I am strongly in favor of at least adding the channel-binding-only
option to GS2.  I am also leaning towards being in favor of removing
support for security layers and security layer negotiation from GS2 as
well -- that would another significant simplification.  On the latter
point I'd like to hear from Simon and others whether they are OK with
GS2 (GS3, whatever) mechanisms not providing any security layers.

Nico
--