Re: more SASLprep/protocol problems

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 04:41 AM 9/24/2003, Hallvard B Furuseth wrote:
>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.

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.

>> The specification is primarily written to promote interoperability
>> 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.

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.

>> 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. 

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.