begin quotation by Mark Crispin on 2002/5/29 13:19 -0700:
> On Wed, 29 May 2002 12:35:17 -0700 (PDT), [EMAIL PROTECTED] wrote:
>> A specific protocol is another matter. The IESG's belief is that specific
>> protocols need to have one or more mandatory to implement SASL
>> mechanisms. Mandatory to implement doesn't mean mandatory to use. Just
>> because you have to implement something to be compliant does not mean
>> all setups must make that option available.
>
> I guess then that I don't understand this.
>
> The legacy LOGIN command seems to be "mandatory to implement" by this
> criteria (as is the legacy USER command in POP3) but a server advertising
> the LOGINDISABLED capability will return an error.
The IESG has had a requirement for years that all protocols which need
authentication include a non-plaintext mandatory-to-implement mechanism for
authentication. I spent years trying to understand and address this issue
for ACAP. It's not a flexible requirement, there's no way out. (POP3 and
IMAP4rev1 slipped out the door just before the requirement came into
effect).
Be aware that "mandatory to implement" does not mean mandatory to use.
What it means is if you take _any_ compliant client and _any_ compliant
server they can be configured to use the "mandatory to implement" mechanism
and they will interoperate without sending a password unencrypted over the
Internet. This is a reasonable interoperability/security requirement to
place on implementors.
It may be the case that some RFC 2060 compliant servers will not be RFC
IMAP4rev1bis complaint because they don't implement the mandatory
mechanism. But that's OK.
I believe there are two viable choices for mandatory to implement:
(1) Require implementation of STARTTLS (making the most common RSA+RC4
cipher suite mandatory would be most realistic) and use it with the LOGIN
command (or PLAIN SASL if you wish).
This is the most widely deployed secure authentication mechanism today.
It's a bit heavy-weight, but TLS has become so fundamental to security on
the Internet that it's not unreasonable to require.
(2) Require implementation of DIGEST-MD5.
This is not as widely deployed, but I believe we have rough concensus in
the applications area that it's an appropriate cross-application MTI
candidate. It's compatible with HTTP-digest, it's mandatory in LDAP and
other protocols. Microsoft is capable of supporting it (unlike other
"lightweight" mechanisms like CRAM-MD5). There are some annoying issues
with password migration and storage. But mandatory-to-implement doesn't
mean mandatory-to-use.
Both options have open-source code available and many existing IMAP servers
already comply.
We could even do "1 and 2" as MTI for servers and "1 or 2" as MTI for
clients.
Let's pick one and move on, please. I put a lot of effort into the
STARTTLS and DIGEST-MD5 specs so this wouldn't be a problem.
- Chris
