[Top] [All Lists]

Re: WGLC on draft-ietf-sieve-managesieve-01.txt (review)

2008-11-09 14:52:17

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




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