begin quotation by Mark Crispin on 2002/5/30 18:25 -0700:
> I therefore recommend to the group that we declare that:
> . *the* solution is TLS+AUTH=PLAIN
> . TLS+AUTH=PLAIN is mandatory to implement on both client and server
> . the problem is solved
> and abandon alternatives.
This is acceptable to me.
begin quotation by Alexey Melnikov on 2002/5/31 10:15 -0600:
> Having said that I would like to leave at least one non-plaintext SASL
> mechanism as mandatory to implement. So, what about
>
> Clients: MUST TLS+AUTH=PLAIN and DIGEST-MD5
> Servers: MUST TLS+AUTH=PLAIN or DIGEST-MD5
>
> What client implementors think? I don't feel that I have a moral ground to
> make a decision for client implementors, as I currently not writing one,
> although I used to a long time ago (and it had DIGEST-MD5 support ;-)).
Don't you have the logic reversed for clients and servers? On servers,
code bloat is simply not an issue so implementing both is a no-brainer.
The primary reason for considering more than one mechanism would be the
noticable wall-clock time cost of a PKI operation on a low-end handheld
client device. If that is a consideration, we would want:
Clients: MUST implement TLS+AUTH=PLAIN or DIGEST-MD5 (SHOULD implement both)
Servers: MUST implement TLS+AUTH=PLAIN and DIGEST-MD5
But my instinct is that with the way technology is advancing, Mark's
simpler proposal will be practical even on low-end handheld devices by the
time this is all rolled out. But I'm willing to be told otherwise by
someone with more expertise in the handheld client space.
FWIW, our server uses LDAP for password stoarge. If passwords in LDAP are
in-the-clear, then DIGEST-MD5 and CRAM-MD5 can be enabled. If passwords in
LDAP are one-way-hashed, then only SSL+AUTH=PLAIN is available. I'm also
lobbying our LDAP group to support MD5( username : realm : password ) as
the preferred password one-way-hash so we can support DIGEST-MD5 _and_
hashed passwords.
- Chris
