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.
In the case of SASL, there is no protocol difference between "not implemented"
and "implemented but not offered". 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.
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.
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.
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.
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
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.
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.
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.
> 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.
To be credible, IESG can't ignore reality, both in the IMAP world and in
general technical issues. Let me emphasize that I do *NOT* oppose the
underlying principles. I am just unwilling to be set up as the guy who wrote
an idiotic requirement into a document that any sane person will ignore. So
please let's find something that doesn't do that.
The following options are possible:
1) Recognize the status quo: the legacy LOGIN must be implemented by all
servers, even if it is to refuse because plaintext authentication is
disabled. If necessary, add some document fluff to note this. No SASL
authenticators of any kind are currently required, although SASL is
certainly encouraged.
2) Declare that the LOGIN and/or PLAIN SASL authentication mechanisms must be
implemented. This will have one of two effects:
a) a server may choose not to offer these, in which case the entire
statement is meaningless; there is no way to discern the difference
between a server which has PLAIN disabled and one that does not
implement it.
b) these must be offered, in which case it will declare existing servers to
be non-compliant and define a mandatory security hole in IMAP.
3) Declare that a mechanism such as CRAM-MD5 or Kerberos, which is impossible
to implement in some environments, is mandatory to implement. The effect
of this would be widespread violation and further erosion of IESG's
credibility.
I hope that IESG recognizes that (3) is completely wrong-headed and would
choose between (1) and (2). I can describe (3) with much harsher words than
"completely wrong-headed"... :-)
Assuming that IESG sees the choice as being between (1) and (2), then I would
argue that from a security standpoint there is no real difference between (1)
and (2). However, (2) has undesirable side effects and (1) does not.
The closest peer protocol to IMAP is POP3, which has been approved by the IESG
as a Full Standard. POP3 has SASL, but no mandatory to implement SASL
mechanisms; in effect, POP3 uses option (1).
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?
> 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.
> The rationale here as I understand it is that this makes it easier during
> standards advancement to figure out what the real dependencies are. But
> regardless of whether or not you believe this is useful or strance or
> whatever, having such a split is a recent requirement imposed by the RFC
> Editor and approved by the IESG. As such, I believe this one is
> nonnegotiable.
OK, I've done this.
