[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Holding gs2
On Tue, Jan 29, 2008 at 12:16:36PM -0700, Chris Newman wrote:
> Speaking as a technical participant only...
>
> As a SASL implementer, it is my current intention to not implement the
> "security layer" feature of SASL. If I implement GS2, my implementation
> will always negotiate the GS2 security layer off and will use SSL/TLS
> channel bindings if there's any reasonable way I can get that working with
> the Mozilla/NSS library.
Most SASL apps have StartTLS or TLS port options. I'm inclined to
believe that most SASL implementors would prefer to just do channel
binding to TLS when you want security layers.
So I'm now inclined to believe that Sam is right: we may have gone
overboard with GS2.
The only question left for me then is this: does anyone actually want
SASL security layers with any new mechanisms, or with the replacement
for "GSSAPI"?
If the answer is "noone does" then I say we scrap GS2 and do a new thing
based on GSS-API channel binding semantics and no security layers.
If the answer is "some do" (e.g., Simon), then I think we may want a
light-weight GS2 option, for use when no security layers are desired.
> However, I only plan to implement GS2 if it provides value above the GSSAPI
> mechanism -- that means it's only worth implementing to me if there are
> clients that support the combination of GS2, Kerberos 5 and SSL/TLS channel
> bindings.
OK. To be sure there exist plenty of protocols that use both, TLS and
SASL. What doesn't necessarily exist is support for extracting channel
bindings from TLS libraries.
> 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). However, textual protocols are easier
> to debug, easier to understand and thus easier to deploy. I'd be concerned
> about the real-world deployability of an all-binary SCRAM.
Well, ciphertext and MACs won't look like text... Password-based SASL
mechs with channel binding would make relatively little use of crypto on
the wire -- just some HMACs. So you might be able to get your wish.
Nico
--