The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
draft-ietf-sasl-plain-09

[Ballot discuss]
>  Clear-text passwords are simple...
>  The drawback is that they are unacceptable for use over an unencrypted
>  network connection.

Is encryption really the only way to achieve a connection that is acceptable for using a clear-text password over? What if the threat model only includes offband attacks? What if physical security is sufficient? Perhaps "untrusted" or "unsecure" network connection is a better term here. The rest of the document talks more about obtaining "adequate security" rather than encryption per se, so changing this should make the document more consistent with itself as well.

Also, are not some plain-text password methods, for example those that use a one-time password, considered secure even over unsecured connections? If so, perhaps this could be listed as a valid exception case.

[Ballot comment]
From Gen-ART review by Eric Gray. A few sentences seem to need clarification.

----

In the second paragraph on page 4, I am having some trouble
parsing the text "The SASLprep preparation algorithm is not
mandatory to allow, when appropriate, the server to employ
other preparation algorithms (including none)."

What I think this means is "To allow the server to employ
other preparation algorithms (when appropriate, including
none), the SASLprep preparation algorithm is not mandatory."
Alternatively, a construction identical in meaning would be
"The SASLprep preparation algorithm is not mandatory.  This
allows, when appropriate, the server to employ other
preparation algorithms (including none)."

Is this interpretation correct?

Another potential (mis?) interpretation of this statement is
"It is not mandatory, in the SASLprep preparation algorithm,
to allow the server to employ other preparation algorithms
(when appropriate, including none)."

The latter interpretation is a stretch as well as not being
self-consistent, but it is a possible interpretation...
============================================================

I am not certain what the first two paragraphs on page 6 are
trying to say.

"It is noted that the DerivateAuthzid and Authorize functions
(whether implemented as one function or two, whether designed
in a manner in which these functions or the mechanism
implementation can be reused elsewhere) require knowledge and
understanding of mechanism and the application-level protocol
specification and/or implementation details to implement

"It is also noted that the Authorize function outcome is clearly
dependent on details of the local authorization model and policy.
Both functions may be dependent on other factors as well."


After struggling with it for a while, I think it means -

'Implementation of portions of the functionality shown in the
above pseudo-code (e.g. - DerivateAuthzid and Authorize) will
require understanding of specific mechanisms, application level
protocols and implementation details.  Also, the functionality
associated, in the pseudo code example, with the "Authorize"
function depends on local authorization and policy details.
Represented functionality may also depend on other factors.'

Is this correct?

I had trouble with the wording because:

1) I have no idea what value to associate with "noting" these
  things as opposed to simply saying them.  Is there any?
2) I had to look a couple of times to realize that the intent
  of the parenthesized text in the first paragraph seems to
  be to avoid giving any sort of "definitive weight" to the
  example represented by the pseudo code (in other words, I
  had to read it twice to realize that I never had to read
  it at all).
3) I had some touble parsing the last two lines of the first
  paragraph.
============================================================

The following text in section 5 -

"The second example shows how the PLAIN mechanism might be
used to assume the identity of another user.  In this example,
the server rejects the request."

The first sentence implies success, the second failure.

I assume the second is correct.  In that case, shouldn't the
first sentence refer to an "attempt to assume ..."?

There is some shock value in the current wording, because I
thought it was getting ready to tell me how to do something
I should not be able to do.
===========================================================

NITs:
====

Section 1 - 6th paragaph "a strong data security service"
as opposed to "an strong ..."

Page 4, third paragraph - "unassigned code points are allowed
to appear in" as opposed to "... allowed appear in".

[Ballot comment]
The Security Considerations say:
  >
  > "stringprep" and Unicode [StringPrep] security considerations
  > also apply, as do [UTF-8] security considerations.
  >
  I think it would be better if this were a separate paragraph.  Also,
  it will be easier to read if it was reworded slightly:
  >
  > Unicode and "stringprep" [StringPrep] security considerations
  > also apply, as do [UTF-8] security considerations.

[Ballot discuss]
The Security Considerations say:
  >
  >  General SASL security considerations apply to this mechanism.
  >
  Please add a pointer to these SASL security considerations.

[Ballot comment]
The changes from RFC2595 section explicitly notes that CR and LF are now legal as authzid characters.  As I understand it, since this document updates RFC2595, an application protocol specification would have to write a new profile to use this, and could then exclude CR and LF characters if those cause any problems in the application layer.  Sam and I discussed the possibility of adding this kind of explanation to this document, which I feel would be useful.

Re-reviewed.  Requested working group separate out preparation of
authorization id in the non-normative section 4 to be more consistent
with how I think frameworks will be implemented.

From: Simon Josefsson
Subject: Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard
Date: Tue, 22 Feb 2005 14:55:24 +0100



The following came up when implementing authzid derivation.  My
recommendations on solving this are given below, but first some
discussion on the problem.  In section 2:

  When an empty authorization identity is provided, the server SHALL
  derive the authorization identity from the prepared representation of
  the provided authentication identity string.  This ensures that the
  derivation of different representations of the authentication identity
  produce the same authorization identity.

Given that the strings are prepared as query strings, it is not
strictly true that, as the last sentence suggest, the step ensure that
different representations produce the same authorization identity.

Consider two authid strings with unassigned code points (e.g., with
some new Unicode 4.0 code points).  They could be two different
Unicode representations of essentially the same string.  I.e., had
Unicode 4.0 NFKC been used on the two strings, the output would have
been identical.

Further, the pseudo code description for this case appear
miss-leading, consider:

        string pAuthcid = SASLprep(authcid, true); # prepare authcid
...
        if (authzid == NULL) {
          authzid = DeriveAuthzid(pAuthcid);
          if (authzid == NULL || authzid == "") {
              return false; # could not derive authzid
          }
        }
        if (!Authorize(pAuthcid, authzid)) {
          return false;    # not authorized
        }
...
  The second parameter provided to the Authorize function is not
  prepared by this code.  The application-level SASL profile should be
  consulted to determine what, if any, preparation is necessary.

Now, if authzid is NULL in the first 'if' clause, 'authzid' will
actually be prepared by the code, which doesn't match the explanation.

RECOMMENDATIONS:

Don't derive authorization identities from the prepared representation
of authentication identities, when the presented authzid is empty.

Change the paragraph above into something like:

  When an empty authorization identity is provided, the server SHALL
  derive the authorization identity from the provided authentication
  identity string.  The application-level SASL profile should be
  consulted to determine what, if any, preparation is necessary.

In the pseudo-code, let the DeriveAuthzid function take 'authcid' as
parameter:

        if (authzid == NULL) {
          authzid = DeriveAuthzid(authcid);
          if (authzid == NULL || authzid == "") {
              return false; # could not derive authzid
          }
        }

Further, add an explanation of the DeriveAuthzid function, that
suggest the function prepare the string internally, if required by the
application profile:

  The DeriveAuthzid function is responsible for deriving an
  authorization identity string given the presented authentication
  identity string.  The application-level SASL profile should be
  consulted to determine what, if any, preparation is necessary.

I've asked the working group to correct the fact that some times the
document uses TLS or other strong encryption layer while in other
cases TLS is mandated.

The following last call comment was received:
From: "Jeffrey I. Schiller"
Message-ID: <20050211174940.B863@mit.edu>
Subject: [saag] Re: Last Call: 'The Plain SASL Mechanism' to Proposed Standard

I object to this document being made a proposed standard. It
effectively permits the use of plain text passwords over an insecure
mechanism. I thought we were trying to eliminate such things in IETF
protocols.

Although the document purports to be used only when an underlying
transport is providing security (aka TLS) it provides an escape
clause. Namely the phrase "or backwards compatibility dictates
otherwise." This phrase appears twice in the document. In section 1
and again in the Security Considerations Section. To wit:

=46rom Section 1:

  The PLAIN SASL mechanism does not provide a security layer.  This
  mechanism MUST NOT be used without adequate security protection as the
  mechanism affords no integrity nor confidentiality protection itself.
  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.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=2E..

6. Security Considerations

  The PLAIN mechanism relies on the TLS encryption layer for security.
  When used without TLS, it is vulnerable to a common network
  eavesdropping attack.  Therefore PLAIN MUST NOT be advertised or used
  unless a suitable TLS encryption layer is active or backwards
                                                      ^^^^^^^^^
  compatibility dictates otherwise.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I will withdraw my objection if this "escape clause" is removed (and
an equivalent one isn't substituted...).