Nicolas Williams wrote on 1/28/08 9:59 -0600:
Sam is proposing SASL mechanisms that support channel binding but not any security layers, which effectively changes the semantics of channel binding that we had assumed/concluded we wanted. This change can greatly simplify the design of future SASL mechanisms, and it can greatly simplify the design of a SASL/GSS bridge for GSS mechanisms that support channel binding.
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.
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.
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.
- Chris