[Date Prev][Date Next]
more SASLprep/protocol problems
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,
- 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.