Re: more SASLprep/protocol problems

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

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

Kurt D. Zeilenga writes:

>>> One fraction of the community is attempting to improve
>>> interoperability between independently developed implementations.
>>> One faction is attempting to support legacy systems.
> 
> I used "legacy system" to refer to an implementation which is
> gatewaying with an external system which has rules which are
> not easily changed.

OK.

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

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.

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

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.

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

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

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

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

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

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.

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

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

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

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

-- 
Hallvard