On Wed, 2 Feb 2005, Pawel Salek wrote:
PS. my reading of RFC1939 is that it is ok to try USER but send PASS only if the server answered with +OK.
Here's where interpretation of RFCs leads us into trouble. There is a very great difference between:
. what is "right"
. what is "obvious" to you and me
. what is "obvious" to someone else
. what the RFCs actually say
Failure to take all four of these into account leads to disaster! [Sad experience here...]
This current thread is a good example.
Unfortunately, RFC 1939 has the following statement in its Security Considerations section:
Servers that answer -ERR to the USER command are giving potential
attackers clues about which names are valid.
We can argue that this does not apply when -ERR is given to any USER command. However, if you read RFC 2449, you will find that the USER capability refers to "USER and PASS".
It may be "obvious" that "USER and PASS" means "any USER command and/or any PASS command". But, it doesn't say that.
This opens the door (wide enough to drive a truck through) for an interpretation that the USER capability applies *only* to sending USER *and* PASS, and not to sending USER by itself (or sending USER along with some token other than a password).
Put another way, it can be argued that the USER capability refers to the PASS command, not the USER command. That argument is completely valid with the way that RFC 1939 and RFC 2449 are worded.
Once that argument is accepted, you then run into the unfortunate statement above in the Security Considerations of RFC 1939, which seems to indicate that a server SHOULD NOT answer -ERR to the USER command.
At this point, a client that has been broken not to respect CAPA (as discussed in this thread) will send the password in the clear to a server which won't accept it and has a policy of no passwords in the clear.
This all may sound like a stretch. However, 30 years of experience with Internet protocols tells me that it isn't a stretch at all. The door is open, and sooner or later a truck *will* be driven through it. The only question left is whether or not we allow the evil hitchhiker through as well.
Since the server in question has CAPA, it is a RFC2449-compliant server and the CAPA response is the authorative way of finding out which commands are available.
Indeed. RFC 1939 reflects the old way of "just try it and see if it works" thinking. Such things has caused enormous problems, and was a major factor in adopting capabilities in the IMAP2 -> IMAP4 transition.
A similar discussion is going on with the NNTP protocol. The difference is that it has a much more entrenched infrastructure of "just try it and see" and capabilities listing that isn't authoritative either way.
The only sane way out of the mess is to demand that capabilities listings to be authoritative, and in turn to respect that authority. This means, among other things, that clients must demand authoritative capabilities listings from servers. Clients should not try to guess and work around, and servers must not assume that clients will guess and work around.
Unfortunately, every client which guesses and works around gives the server an excuse not to adhere to its requirements. Time and time again, I hear "our server works with Outlook and Thunderbird, therefore the bug is in Pine; so we're not going to change our server or even look any further."
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
