RFC 5804 says:
To ensure interoperability, both client and server implementations of
the ManageSieve protocol MUST implement the SCRAM-SHA-1 [SCRAM] SASL
mechanism, as well as [PLAIN] over [TLS].
How can this be a requirement, when SCRAM requires passwords to be
stored either as plaintext or in a special SCRAM format? Very few
existing installations would be able to easily start supporting SCRAM.
(Or is this just a tricky way of saying that server code must be able to
support it, but admins can choose if it's actually enabled?)
I see Jeffrey Hutzelman mentioned this earlier too, without replies:
I think perhaps the right answer, for ManageSieve and for many other
protocols, is to require
- clients MUST implement both PLAIN and FOO
- servers MUST implement at least one of PLAIN or FOO
where FOO is some mechanism with the properties you describe.
The problem is that there are a wide variety of underlying
authentication
services that people might want to deploy which can work with PLAIN
but not
with any of the mechanisms that are candidates for FOO. Examples
include
Kerberos password validation (used where the client has no Kerberos
support), RSA SecurID, and OTP mechanisms such as that described in
RFC2289.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve