--On March 11, 2008 7:16:50 -0400 Jeffrey Hutzelman <jhutz@xxxxxxx> wrote:
I would be very disappointed to see separate password mechanisms for SASL and GSS-API, rather than one mechanism that can be used with either. Producing only a SASL mechanism would fail to meet the needs of GSS-API applications desiring support for password authentication
Having separate password-based mechanisms for SASL and GSS-API would be lunacy, IMHO. Having the same password-based mechanism with different on-wire encodings for SASL and GSS-API is an option I want to leave on the table until I've seen the impact of GS2 on the on-wire encoding.
If the impact of GS2 on the authentication protocol is a fixed-size binary blob at the beginning of the protocol exchange (that can simply be omitted from diagnostic output and made optional when the code is running in debug mode), then I'm fine with a combined mechanism. If the impact of GS2 is variable-sized binary or binary in multiple places in the authentication protocol, then I'd be much less comfortable with a dual-purpose wire-encoding.
If we have two wire encodings of the same mechanism, then SASL applications could access the same mechanism via two different names (e.g., SASL-FRIENDLY-NAME, GS2-KSDJFHSLKDSF). But a simple applicability statement to not use the latter in SASL-based protocols is sufficient to resolve interoperability problems for this case. I can't see this as a matter that will cause significant confusion.
While I prefer to avoid two different wire encodings for the same function, I consider the deployability of the mechanism to be a much more important concern and the deployment impact of binary in the SASL authentication protocol is significant in my experience.
While I once thought use of NUL for field delimiters in SASL PLAIN was clever (as it may benefit languages with NUL terminated strings and avoids quoting), my subsequent experience indicates it was a design error (not significant enough to merit a change now, but a mistake to avoid in the future).
- Chris