Re: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)

[Alexey Melnikov <[e-mail]>]

Nicolas Williams wrote:

>Perhaps we can just simplify GS2 enough that all concerns go away.
>
>The primary differences between the GSS-API and SASL:
>
>a) one is message-oriented (GSS), the other is stream-oriented (SASL);
>
>b) SASL client apps must send the name of the mech being used before
>   using it, while the GSS-API includes the "name" of the selected mech
>   in the first authentication message;
>
This might be a minor detail, but if understand correctly, GSS-API is 
using OIDs for naming, while SASL typically doesn't.

>c) SASL authentication message exchanges negotiate what security layers
>   will be used and maximum message sizes; the GSS-API does no such
>   negotiations;
>
>d) the GSS-API has channel binding, but it's all or nothing, and it's
>   optional; SASL has never had channel binding.
>
>e) terminology :)
>
>(a) is easy to address in a SASL/GSS bridge.
>(b) is easy to address in a SASL/GSS bridge.
>
I am not entirely sure what you call "bridge" in this case, but I tend 
to agree with your conclusion ;-).

>(c) is easy to addres by replacing security layers with channel binding
>    to TLS,
>
As a side note: we shouldn't be requiring TLS to be the only channel 
binding, even though we can recommend it.

>which has the added advantage of simplifying mechanisms and
>    making (a) not matter.
>  
>
Agreed.
I think draft-newman-auth-scram-gs2-00.txt already made the same choice.

>(d) matters only if we want channel binding in SASL, and I think we long
>    ago agreed we did, and if we re-open that question I believe we'll
>    again conclude that we want it.
>  
>
Agreed.

>(e) we can ignore :)
>  
>
I think this is mostly an editorial issue, which might require quite a 
bit of work.
But I agree it should be ignored for now.

>So what makes GS2 not simple?  The fact that we chose to make the GS2
>channel binding semantics different from the GSS-API's: we chose to make
>channel binding success/failure affect the negotiation of security
>layers.
>
>If we reconsider that one choice we could simplify GS2 enough that a
>single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.
>
I agree that would make GS2 simpler, but I am not convinced that that 
would be enough to make SCRAM-as-GS2 satisfy Chris Newman's requirement 
on simplicity. But anyway, I am willing to participate and see what the 
result would be.

I think the extra complexity lies is the need to have authorization 
identity separate from the rest of SCRAM data (because it is transported 
by GS2 itself), this requires an extra hash for protecting it. The same 
applies to the channel binding data, but your proposal above addresses 
this to some extend.