Subject: more SASLprep/protocol problems

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 23 Sep 2003 15:55:03 +0200

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 24 Sep 2003 07:19:45 -0700

I think here are opposing objectives.   One fraction of the
community is attempting to improve interoperability between
independently developed implementations.  One faction is
attempting to support legacy systems.

Legacy systems, by their very nature, are dependently developed.
For example, in the "campus" scenario, there is an assumption
that of consistency of input devices, operating system platform,
application code, etc., to ensure that user input of a textual
string results in the desired octet string.

In independently developed systems, there is the assumption that
there may be no consistency between input devices, operating
system platforms.  Using a preparation algorithm is sound way
of addressing these problems.  As the server doesn't generally
have knowledge of user input devices and operating system
platforms used, preparation by the client is a sound approach.
(Note: It is possible to split the preparation between the client
and the server, PLAIN does this (client handles transcoding
to Unicode and UTF-8 encoding, server handles SASLprep).  With
LDAP, this is not a good option as the server has no way to
determine whether the password is textual or not.)

The specification is primarily written to promote interoperability
of independently developed implementations.  What dependently
developed implementations decide to do (or not do) is, to a
large degree, beyond the scope of the standard.  This is
not meant that we should abandon "legacy" issues, but to note why
we there is a "SHOULD".  A "SHOULD" allows implementations to
go against the recommendation where appropriate.  Maybe what
we need to be a bit more explicit about where going against the
SHOULD might be appropriate.

How's this?

     The simple form of an AuthenticationChoice specifies a simple
     password to be used for authentication.  To improve matching
     of textual passwords, clients SHOULD prepare textual passwords
     for transfer by transcoding to [Unicode], applying [SASLprep],
     and encoding as UTF-8.  Clients MAY prepare textual passwords
     using other algorithms (including null preparation) to support,
     for instance, legacy systems.  Non-textual passwords MUST NOT
     be mutated.

- Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 24 Sep 2003 13:41:42 +0200

Kurt D. Zeilenga writes:
> I think here are opposing objectives.

Yes...

> One fraction of the community is attempting to improve
> interoperability between independently developed implementations.
> One faction is attempting to support legacy systems.

I disagree.  This has nothing to do with legacy systems.  Maybe LDAP
will someday conquer the world to the point where an operating system
whose password handling is not written with LDAP in mind, is a legacy
system, but that time is far away.  Today, that is a _normal_ system.

> of addressing these problems.

If they use that, there is also the assumption that the system's
password handling is written with LDAP in mind, or is otherwise
restricted so it can handle prepared passwords.  (Ours does,
incidentally: it only accepts ASCII passwords.  So this is all a
somewhat abstract argument to me.)

> As the server doesn't generally

Sometimes true.  But as I mentioned in the encrypted passwords thread,
if the server only knows a hashed version of the password, and the hash
did not do SASLprep first (i.e. it was not done with LDAP in mind), the
server must reverse the preparation before matching the passwords, so
then it _must_ know the character set the password was stored with.
Thus preparation can enforce just the opposite of what it is supposed to
give us.

The server doesn't have to know that if preparation is not done: Then it
can leave such problems to the user, who has presumably been instructed
by the sysadmin about how to handle any problems with mismatching input
devices.  E.g. "only use ASCII passwords".

> of independently developed implementations.

I know.  I still think this is an area where the interoperability comes
at too great cost.  Interoperability is good when it comes in _addition_
to working well at campus, but if it causes the system to not work at
all on campus, any interoperability which is offered doesn't seem very
relevant to me.

> This is not meant that we should abandon "legacy" issues, but to note
> why we there is a "SHOULD".

And that is why I don't think there should be a "SHOULD", since I don't
think it's a legacy issue.  Or rather, I think implementations "SHOULD"
support both options.

> How's this?

Nope...

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 24 Sep 2003 16:11:52 +0200

> attempting to support legacy systems.

BTW, since you are talking about interoperability in response to a
message about prohibited characters in passwords: Are you arguing that
'interoperability' of the kind 'your password never works in LDAP' is
better than 'it works at least on campus'?

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 25 Sep 2003 00:30:26 -0700

>system, but that time is far away.  Today, that is a _normal_ system.

I used "legacy system" to refer to an implementation which is
gatewaying with an external system which has rules which are
not easily changed.

While such systems are common place, it is extremely to develop
a client which will interoperate in such environments without
knowledge of the rules of the external system.

Take, for example, that the external system is EBCDIC based as
are existing clients.  It is quite unlikely that any independently
developed system would interoperate with such a system.

I think if you look at existing gateways to external passwords
stores you will find they have an implicit preparation rule:
Clients are to prepare passwords in the same fashion in which
the password storage application producing and storing them
(or their hashes).  Interoperability with all of these systems
is dependent on implementing that rule.  That is generally
done by implementing (deploying) the client on similar
(in hardware, software and configuration) operating system
platforms.  In such deployments, interoperability is primarily
the result of controlling the hardware, software, and their
configurations.

So, one can say that both approaches assume that the asserted
password is prepared in the same fashion as the stored password
(or password used to generate the stored hash).  The difference
is whether the preparation algorithm is specified or a local
matter.

>all on campus, any interoperability which is offered doesn't seem very

I would argue that an independently developed system won't
interoperate on your campus without knowing the particulars
of your password preparation rules.  If we remove the statement,
a client produces EBCDIC (or even UTF-16) passwords would be fully
conformant but fail to interoperate with your ASCII based external
password store.  That is actually a good enough reason to say
clients SHOULD NOT pass textual passwords onto the wire without
preparation.

>think it's a legacy issue. 

It's a SHOULD for interoperability reasons, the additional statement
is added for legacy (support of external systems with local rules)
reasons.

>Or rather, I think implementations "SHOULD" support both options.

I disagree.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 24 Sep 2003 23:06:46 +0200

Hallvard B Furuseth wrote:
 >
> it only accepts ASCII passwords.

This is not an option. Maybe the input device of the user's system does not 
have ASCII keys at all.
=> passwords should be UTF-8'ed before being stored or calculating the hash 
of the password unless a legacy system is used.

Ciao, Michael.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 29 Sep 2003 14:32:13 +0200

Michael Ströder writes:
> This is not an option. Maybe the input device of the user's system
> does not have ASCII keys at all.

I wasn't suggesting to put that in the draft.  I just mentioned that
that's what our site is doing.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 30 Sep 2003 23:51:21 +0200

Sorry to be late.  Your previous message had me reading SASL documents
for a while, but it was a false alarm.  Anyway,

> gatewaying with an external system which has rules which are

OK.

> While such systems are common place, it is extremely [hard] to develop

OTOH, it's extremely easy to develop a client which simply assumes that
server-side and client-side passwords are encoded the same way, or that
the user will otherwise take care of the problem.  The client simply has
to do nothing.  Or if it has to do something, that routine will already
be implemented somewhere in the system, it just needs to be called.

And, as you say, such systems are common.

> developed system would interoperate with such a system.

True, but at least clients developed _there_ would interoperate with
both outside systems and their own server if these clients had options
to both prepare and to not prepare passwords.

For that matter, these clients developed on the outside of the EBCDIC
campus would at least _allow_ users to type in passwords that would be
accepted, if they too had a 'do not prepare' option.  Users would have
to mess with character tables or something in order to know the right
character codeds for the passwords, but it could be done.  I'm not sure
how strong an arugment that is though - I'd like to hear from people on
EBCDIC systems what they do when they telnet 'home' from an outside
system.

> is dependent on implementing that rule.

What preparation?  The systems I know don't modify passwords input by
the user at all.

> That is generally

True.  Well, at least software and configuration.  But you make it sound
harder than it usually is, since it in practice tends to mean 'do
nothing'.

> of your password preparation rules.

Rule: 'Do nothing'.  Or when that's not enough: 'call the function which
is probably already a built-in routine to do such preparation in your
system.'

> If we remove the statement, a client produces EBCDIC (or even UTF-16)
> passwords would be fully conformant but fail to interoperate with your
> ASCII based external password store.

Not if the client offers an option to prepare passwords.

> is added for legacy (support of external systems with local rules)

I think it's a bad choice, but I can live with that one...

>> Or rather, I think implementations "SHOULD" support both options.

...but I really think omitting this is to paint a big "DON't USE ME"
sign on LDAP.

-- 
Hallvard