Re: SASL to draft questionnaire

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Chris Newman <Chris.Newman@xxxxxxx> writes:

> Here's a proposed questionnaire for an implementation report.

Thanks for your initiative!

> I am not volunteering to compile responses to the questions, but I am
> willing to answer these questions for my implementations.

Here is my implementation report.

> RFC 4422 Implementation Questionnaire
> ===============================================
> 0. Contact and Description
> Organization Name:

Simon Josefsson <simon@xxxxxxxxxxxxx>.

> Implementation (Software or Service) Name:

See 1.

> 1. Have you implemented SASL and/or SASL mechanism?

Yes.

A. Client authentication for the Emacs SMTP library, see
<http://www.pdc.kth.se/~jas/emacs-rfc2554.html>.

B. A client/server C library in GNU SASL, see
<http://josefsson.org/gsasl/>.

C. Help maintain a client-side SASL library written by Daiki Ueno inside
Gnus (an Emacs-based MUA), see <http://www.gnus.org/>.

D. The client-side SASL handling in imap.el, an Emacs based IMAP
library, see <http://josefsson.org/nnimap/>.

I've probably implemented it a couple of other times, but the above are
the ones that I still actively have an interest in and are widely
deployed and used, at least as far as I can recall when I'm writing
this.

> 2. Which SASL mechanisms have you implemented?

A. CRAM-MD5, PLAIN, LOGIN.

B. PLAIN, CRAM-MD5, DIGEST-MD5, NTLM, GSSAPI, SECURID, EXTERNAL,
ANONYMOUS.

C. CRAM-MD5, DIGEST-MD5, PLAIN, LOGIN, ANONYMOUS, NTLM, SCRAM-MD5.  (Not
implemented by me though, I'm just helping maintaining it inside Gnus.)

D. GSSAPI, KERBEROS4, DIGEST-MD5, CRAM-MD5, LOGIN, ANONYMOUS.

> 3. For how long has it been deployed?

A. 7 years.

B. 6 years.

C. 4 years.

D. 10 years.

> 4. What features have NOT been implemented from SASL?

In A, C, and D SASLprep have not been implemented.

In A, C, and D security layers have not been implemented.  (Although D
uses external tools that may support security layers for
GSSAPI/KERBEROS_V4).

> 5. What features of SASL or SASL mechanisms are problematic for your
> implementation?

Security layers of DIGEST-MD5 have had interop problems.  Other aspects
of DIGEST-MD5 have had interop problems too (such as ", ," quoting and
other minor issues due to its specification complexity).  I would prefer
to see DIGEST-MD5 go away, as it provides negligible benefits over
TLS+CRAM-MD5 or TLS+PLAIN.

In general, security layers are largely under-utilized and I prefer to
depend on TLS and deprecate security layers in SASL.  Users rarely know
or asks about security layers in SASL.  When they do, they are typically
confused and really means TLS.

Only B implements SASLprep.  While SASLprep in B has been used
successfully in deployments, my original complaints about SASLprep's
poor future compatibility are today practical problems that make me
avoid talking actively about it with customers.

I believe the SASL base specification should merely suggest that
mechanisms should be UTF-8 ready and that they have to deal with i18n
issues, and not go into more specifics than that.  Similar to security
technology (HMAC, MD5, Kerberos, etc), internationalization is an
evolving area, and SASL mechanism should be allowed to make sensible
trade-offs in this area.  Customer demand can decide growth.

The semantics of EXTERNAL is under-specified, and the mechanism is
typically only useful when users have good insight into the
administration of both the server and client.  I propose that a revised
EXTERNAL mechanism as specified, that just does channel binding to
another security layer and transfers an authorization identity.

> 6. Please add any other comments you wish to share:

Let me echo Chris's summary, which is the exact same as mine:

I fully support advancement of RFC 4422 to draft status.  It is my
opinion both SASLprep and SASL security layers should be deprecated or
omitted when RFC 4422 advances.  However, I would rather 4422 advances
with those features than have it not advance.

/Simon