> 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.
LOGIN isn't acceptable since it is a clear text mechanism. (I guess I should
have made it clear that such a mechanism cannot qualify as the mandatory to
implement one. Sorry about that.)
> In the case of SASL, there is no protocol difference between "not implemented"
> and "implemented but not offered".
This is true but irrelevant. The issue isn't whether you can set up your
servers not to interoperate. It is obvious you can do that.
The issue is whether or not you can end up with two standards compliant servers
that cannot be configured to interoperate. If you can end up with that you have
an interoperability failure.
> Either there is an AUTH=xxx which says
> that mechanism xxx can be used, or there isn't; and there is no way that IESG
> can require there to be *any* AUTH=xxx offered.
Exactly. But the IESG can, and does, require that implementations be able to
interoperate in order to be compliant.
> Of the SASL authentication mechanisms which are commonly implemented:
> 1) Kerberos (KERBEROS_V4 or GSSAPI) is unsuitable for "must be implemented."
> I hope that I don't have to explain why to anyone. Almost no software
> implements Kerberos.
Agreed.
> 2) CRAM-MD5 is unimplementable unless the password store on the server is in
> plaintext or plaintext equivalent. Most software does not implement
> CRAM-MD5.
This doesn't necessarily mean that it cannot be implemented as an option, only
that it may not work with some authentication sources.
> 3) DIGEST is too recent; a requirement that it must be implemented would
> declare previously compliant servers as being non-compliant. Most software
> does not implement DIGEST.
It may well be that a revised version of a specification means existing
implementations have to do a bit of work to be fully compliant. This happens
all the time.
> 4) PLAIN is too recent; a requirement that it must be implemented would
> declare previously compliant servers as being non-compliant. A majority
> of modern servers implement PLAIN, somewhat less than a majority of clients
> do
Plain uses clear text passwords and is hence a nonstarter.
> 5) LOGIN (SASL mechanism not legacy command) was never published in any IESG
> specification due to IESG politics. It could be published now; it
> certainly is silly not to do so, given that IESG published PLAIN. A
> majority of clients and servers implement the LOGIN SASL mechanism.
Another nonstarter due to clear text password issues.
You're missing one from the list: SSL and LOGIN (or PLAIN). This likely would
be acceptable. I believe the IESG could be convinced this is the way to go.
Perhaps this would be more acceptable as a mandatory to implement: It certainly
avoids all the authentication source issues.
Still another option is to go with more than one mandatory to implement. You
could say that all clients must do SSL+LOGIN and DIGEST-MD5 while servers can
choose between the two. (I don't know if this helps, but I thought I should
mention it.)
> ALL clients and servers implement the legacy LOGIN command.
> The bottom line is that there are no SASL authentication mechanisms which are
> being implemented in all IMAP servers; the most widely implemented SASL
> authentication mechanism isn't documented; the better SASL authentication
> mechanisms aren't always implementable; and the always-implementable SASL
> authentication mechanisms aren't in any way better than the legacy LOGIN
> command.
It is precisely this sort of fragmentation that a mandatory to implement
mechanism is intended to correct.
> In fact, a properly written IMAP client does not use the legacy LOGIN command
> unless there are no SASL authentication mechanisms available in common on
> client and server.
> > Similar arguments were made in the LDAP case, BTW. They did not fly.
> Does LDAP have a legacy LOGIN command? If not, I don't see how this matters.
That's exactly what LDAP had. The situations are fairly comparable.
> > Now, if the group decides to push back against the IESG's position, I will
> > take whatever justification for this position the group comes up with back
> > to the IESG and see what they say. However, I have to say that I think the
> > chances of the IESG changing their position on this are practically
> > nonexistant.
I'll skip the part about the IESG's wrong-headedness, as responding to it is
not constructive.
> There is a variant of (1) which IESG may find more palatable but remains in
> accord with contemporary reality (and likely future reality). This is to
> start with (1) but then recommend SASL implementation along the lines of:
> a) PLAIN should be offered in all circumstances where the legacy LOGIN
> command is permitted.
> b) CRAM-MD5 and/or DIGEST should be offered in all circumstances where
> password credentials are stored in the server in a way in which make
> these implementable.
> c) Kerberos should be available for those sites which use Kerberos.
> The primary effect of this is to further the deprecation of the legacy LOGIN
> command. It also points at what is likely to be implemented by other
> software.
> Would this be acceptable?
If you added SSL to a) this would probably fly. Of course clients would have
to support all three, which sounds like a lot of work...
> > I am willing to argue that this properly belongs in the revised SASL
> > specification, but it would help to have some degree of acceptance on the
> > SASL side as part of this.
> Thank you. A secondary argument is to consider the egg on IESG's face if IESG
> approves IMAP with a authorization failure policy that flies in the face of
> some other IESG approved standard, corporate policy, or even law.
All the IESG suggested was that some discussion of these issues in the document
might be appropriate. That is lightyears away from a policy requirement in
the area.
Ned
