--On Saturday, November 08, 2008 05:34:07 PM +0000 Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Hi Stephan,
I am responding to the rest of your comments:
Stephan Bosch wrote:
2.1:
[...]
Why SCRAM?
I am glad that somebody has noticed :-).
I might be too ambitious in this case: I would like to require a SASL
mechanism that doesn't pass password to the server (like SASL PLAIN) and
can be used without TLS. DIGEST-MD5 mechanism would have been my
preferred mechanism a couple of years ago. But the current SASL WG
thinking is that it has too many interop issues and is too hard to
implement. That is why I have SCRAM in the document.
So I think now is good time for having a discussion about which
mandatory-to-implement SASL mechanism we should have in ManageSieve. For
short term and medium term (3 years).
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.
-- Jeff