more SASLprep/protocol problems

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

Another point about SASLprep:

SASLprep prohibits some strings.  As far as I can tell from
[StringPrep], some transformations can also result in errors.  The
result of either is that users with such passwords cannot authenticate.

I don't think that's acceptable for a transformation recommended by
[Protocol].  It's OK if the program which changes passwords for users is
written with SASLprep in mind, but if LDAP just stores passwords which
are _not_ written for SASLprep, we can't just tell users with unlucky
passwords that they can't log in because LDAP doesn't like them.

I can think of two fixes:

- One is for SASLprep to leave currently prohibited characters alone,
  and transformations which return errors should instead be no-ops.
  That doesn't fix the issue with server-side encrypted passwords,
  though.

- Another is the variant I mentioned in the SASLprep/userPassword
  thread: Remove the sentence in [Protocol] 4.2 (Bind Operation) that
  bind passwords SHOULD be prepared.  Instead say that implementations
  could either prepare or not, and recommend that both variants are
  offered as options.

  If so, I don't even think [Protocol] should recommend one of the
  variants as a default:

  Because of prohibited characters and the issue with server-side
  encrypted (or rather, hashed) passwords, not preparing will usually
  work best on campus.  This is one instance where interoperability will
  often have to take second place, because if LDAP can't even be used
  for authentication on campus, many will choose to use something else
  than LDAP for authentication, and then any interoperability it might
  have is quite irrelevant.

  OTOH, e.g. EBCDIC sites whose users often log in from ASCII sites
  face a tougher choice here, they are likely to prefer to translate
  passwords to an ASCII superset, i.e. to prepare the passwords.

-- 
Hallvard