Re: Textual/non-textual passwords and SASLprep

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Jim Sermersheim writes:
> (Lifting snippets from here and there) How does this sound?
>  
> Textual passwords (consisting of a character sequence with a known
> character set and encoding) SHALL be transferred as [UTF-8] encoded
> [Unicode].  The determination of whether a password is textual is a
> local client matter.  Prior to transfer, clients SHOULD prepare text
> passwords by applying the [SASLprep] profile of the [Stringprep]
> algorithm.  Passwords consisting of other data (such as random octets)
> MUST NOT be altered.

OK for the client-side passwords.


On the server side, I think it should be specified that the server
itself does not apply [SASLprep] to Simple Bind; one should apply
[SASLprep] before storing a textual password in the server.  (The SASL
bind case is more complicated, see below.)  The userPassword text in
[syntaxes] might then refer to this text.

[SASL] will probably recommend SASL mechanism definitions to specify
that the server does apply [SASLprep] to server-side passwords, see
message
  http://www.imc.org/ietf-sasl/mail-archive/msg01134.html
and, if you wish, the surrounding thread.

Maybe LDAP (authmeth) should override this, and emphasize that SASLprep
must be expected to have been applied already.  I'm not sure if that
will be possible - maybe some SASL implementations will not offer an
option to _not_ apply SASLprep to server-side passwords?

Or we could accept that with SASL methods, the server may apply SASLprep
even to non-textual passwords (since I take it the server doesn't know
which passwords are textual), or to textual passwords which incorrectly
have not been SASLprep'ed.  Which would mean that simple bind could fail
and SASL bind could succeed with the same incorrect password.  That's a
bit ugly, but I don't know if it's important enough to worry about.  In
particular since simple bind in any case could succeed when SASL bind
fails with the same _correct_ non-textual password - since SASL bind
would incorrectly assume the password was textual and apply SASLprep.

A final option is to bring the issue up at the SASL list, and request
that protocol profiles may specify that the server should not apply
SASLprep to server-side passwords, but depend on it already having been
applied.  They may dislike such an increase of the protocol profile,
which is getting big enough already.

-- 
Hallvard