Re: Last Call for draft-ietf-sasl-plain-01

[Chris Newman <[e-mail]>]

This is mostly editorial nits, but a few substantive issues are included.

-----
>  This document defines a simple clear-text user/password Simple
>  Authentication and Security Layer (SASL) mechanism called the PLAIN
>  mechanism.  The PLAIN mechanism intended to be used, in combination
                                  ^
                                  is
-----
I suggest adding a reference that would make sense to a broader audience:

>  This document defines the PLAIN Simple Authentication and Security
>  Layer ([SASL]) mechanism for use in protocols with no clear-text login
>  command (e.g., [ACAP]).
                       ^
                       or [SMTP-AUTH]

[SMTP-AUTH] J. Myers, "SMTP Service Extension for Authentication", RFC 2554,
            March 1999.
-----
>  The PLAIN SASL mechanism MUST NOT be advertised unless a strong
>  encryption layer, such as provided by Transport Layer Security
>  ([TLS]), is active.
                     ^
                     or backwards compatibility dictates otherwise.

I _STRONGLY_ object to this substantive change from RFC 2595 which was not
listed in the appendix.  There are deployed SMTP AUTH clients which use PLAIN
without TLS and I need to interoperate with them.  If you drop the backwards
compatibility phrase, I will refuse to comply with this version of the PLAIN
mechanism and encourage others to do the same (which would be a shame if we
want SASLprep to deploy).  If you can't tolerate the phrasing of the text from
RFC 2595, then I recommend using text similar to that in RFC 3501 sec 11.2:
  <http://www.apps.ietf.org/rfc/rfc3501.html#sec-11.2>
which is stronger but still realistic.

I'm all for improving the security of the Internet, but I have to draw the line
at requirements which fail to reflect reality.  IETF specifications only have
value if implementers can comply with them and still interoperate with the
majority of deployed software.
-----
>  character, followed by the clear-text password.   The client leaves
>  the authorization identity empty if wishes the server to derive the
                                      ^
                                      it
-----
> It is noted that the
> UTF-8 encoding of a Unicode character may be as long as 6 octets.

I believe this is incorrect.  Unicode characters range from U+0000 to U+10FFFF
(if I recall correctly).  The largest Unicode character consumes only 4 octets
in UTF-8.
-----
>  Upon receipt of the message, the server will verify presented
                                                      ^
                                                      the
>  authentication identity (authcid) and password (passwd) with the
>  system authentication database and that the authentication credentials
                                      ^^^^
                                      verify
>  permit the client to login as the (presented or derived) authorization
>  identity.  If both steps succeed, the user is authenticated.
-----
>  The presented authentication identity and password strings are not be
                                                                     ^
                                                                     to
>  compared directly with stored strings.  The server SHALL first prepare
>  authentication identity strings and password strings using the
                           XXXXXXX
>  [SASLPrep] profile of the [StringPrep] algorithm.  If preparation
-----
>  stronger SASL mechanisms such as the Kerberos-based GSSAPI mechanism

If you mention it, you need to include an informative reference.
-----
>  address this issue.  Clients are encouraged to have an operational
>  mode where all mechanisms which are likely to reveal the user's
>  password to the server are disabled.  It is RECOMMENDED that this mode
>  be the default.

I object to the addition of the last sentence (which was not in RFC 2595).
Such a default mode would mean the client would not interoperate with about 95%
of deployed servers on the Internet.  Please remove it as it is not realistic.
-----
>  "stringprep" and Unicode security considerations also apply.

Please include references.  If I'm trying to review all the security
considerations that apply I need to be able to find them.  The security
considerations for UTF-8 also apply.
-----
      Person & email address to contact for further information:
          Kurt Zeilenga <[e-mail]>
>          Chris Neuman <[e-mail]>

Please remove me from this registration.  You might want to put the address of
the ietf-sasl mailing list as the contact address for more information.
-----
>  This document is a revision of RFC 2595 by Chris Newman.  Portions of
>  the grammar defined in Section 2 were borrowed from [UTF-8] by
>  Francois Yergeau.

I wrote the grammar in Yergeau's revised document :-)
-----
  [UTF-8]      F. Yergeau, "UTF-8, a transformation format of ISO
               10646", RFC 2279, January 1998.

Please change this to reference the working draft, which has the revised
security considerations.

  [UTF-8]  F. Yergeau, "UTF-8, a transformation format of ISO 10646",
        draft-yergeau-rfc2279bis-04 (work in progress), February 2003.
-----

                - Chris