Subject: [sieve] ManageSieve / SCRAM

From: Timo Sirainen <[email-masked]>
Date: Fri, 06 Aug 2010 17:00:26 +0100

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.

---

From: [email-masked]
Date: Fri, 06 Aug 2010 09:18:18 -0700 (PDT)

> support it, but admins can choose if it's actually enabled?)

I don't think it's especially tricky. The text clearly says "implement" and
implement != use.

				Ned

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 06 Aug 2010 13:42:07 -0400

--On Friday, August 06, 2010 09:18:18 AM -0700 
[email-masked] wrote:

> I don't think it's especially tricky. The text clearly says "implement"
> and implement != use.

It's not tricky at all.  The goal, as always, is to insure that you can 
pick arbitrary combinations of clients and servers off the shelf and be 
assured of being able to deploy them in a way that is both secure and 
interoperable.  This is particularly important when the operator of a 
server doesn't have control over the clients, which is most of the time.