Subject: [kitten] RFC5802: question about unknown-user error

From: Jehan Pagès <[email-masked]>
Date: Fri, 3 Dec 2010 23:36:19 +0900

Hi,

I have made some search on SASL and kitten list and did not see a
discussion about this (sorry if I missed it).
I can't help but think that the unknown-user error is a security
concern, because it allows attackers to test usernames and get the
information whether they exist or no. This can have at least 2 uses:

- because the attacker wants indeed to penetrate an account, so one
can know whether it is worth continuing the attack or not (if one did
not know if the username does exist or not, one might waste one's time
on a non-existent account, which is good in such a case).

- because the attacker simply wants to fill his database with real
accounts, for instance so that he can spam/scam there after (when
SCRAM is used in a protocol where this is relevant like emails, or
XMPP) or for another annoying reason.
So an attacker can fill a database of usernames on a server very
fastly: one sends random (or using a dictionary of common usernames)
usernames in client-first-messages and if the exchange directly fails
with unknown-user, hop! in the database!

Personally I would find more secure not to have such an error and to
continue the exchange (simply with some meaningless salt and iteration
count when the user does not exist), then simply fail with the same
error than when the authentication fails ("invalid-proof" I guess) on
the server-final-message. Then existing accounts are protected from
username information gathering because an attacker won't be able to
differentiate whether the exchange failed because the password was
wrong or because the username simply does not exist.

For me the current unknown-user error is a big security flaw. I would
propose to remove this error, and add a security notice about this.
Has this issue already been raised?

Jehan

P.S.: on a half-unrelated topic, what is the "no-resources" error? I
could not find any text about the meaning of "resource" neither in the
SASL, nor SCRAM context (by searching the string "resource" in the
RFC).

---

From: Tobias Markmann <[email-masked]>
Date: Fri, 03 Dec 2010 17:09:54 +0100

> Has this issue already been raised?

Almost any information you return on failure, beside the failure itself,
can be used by a malicious user against a server. I think that's why the
whole server-final-message is OPTIONAL in case of an error.

Those error messages only seem useful for debugging purposed, since some
protocols using SASL, i.e. XMPP, provide SASL errors on that protocol
level [1].

A security notice about this would be nice but actually the problem
isn't specific to SCRAM but to nearly all SASL mechanisms.

Cheers,
Tobi

[1] http://tools.ietf.org/html/rfc3920#section-6.4

-- 
Tobias Markmann
http://ayena.de

---

From: Dave Cridland <[email-masked]>
Date: Fri, 03 Dec 2010 16:19:02 +0000

> whole server-final-message is OPTIONAL in case of an error.
And moreover it also says that specifically for this purpose, you can  
say "other-error" even if there's a more specific reason.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Jehan Pagès <[email-masked]>
Date: Sat, 4 Dec 2010 01:53:39 +0900

Hi,

> whole server-final-message is OPTIONAL in case of an error.

Most other error are far less usable for attack. They are rather
syntax bugs, which are very useful for normal implementers and would
only tell an attacker that he made a technical error in his own
implementation. But it does not give away information about data
stored by the server (like "does this username exist?"), other than
what he would have known with a proper implementation. Those errors
are for instance encoding issues, CB incompatibility, incompatibility
of mandatory extensions (for the future when there will be some), etc.

> protocols using SASL, i.e. XMPP, provide SASL errors on that protocol

Good example If you check the link you give (the last draft of the
updated RFC has similar content as well:
http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-19#section-6.5 ),
in XMPP, we use only one error (<not-authorized/>) whether you fail
because of a wrong password or because your username does not exist,
for instance. The attacker does not know if he is wasting his time on
this attack, nor can he fill his db with any useful data on existence
of a JID.

So of course that's nice when the higher level protocol filters the
SASL errors (in XMPP, we closed the leak created in some SASL
mechanisms like SCRAM), but I don't see why it should prevent us from
fixing this data leak on the SASL-SCRAM level as well.

> isn't specific to SCRAM but to nearly all SASL mechanisms.

I agree about this, but first we can fix this in SCRAM by removing the
unknown-user error; and then we can add a security notice in SASL,
telling that SASL mechanisms should take care about this kind of leak.
There are 2 levels of RFC changes here.

Jehan

---

From: Jehan Pagès <[email-masked]>
Date: Sat, 4 Dec 2010 02:15:40 +0900

Hi,

On Sat, Dec 4, 2010 at 1:19 AM, Dave Cridland <[email-masked]> wrote:
>> On 03.12.10 15:36, Jehan Pagčs wrote:
> And moreover it also says that specifically for this purpose, you can say
> "other-error" even if there's a more specific reason.
>

I read this note in the RFC before sending the email, but it does not
prevent the leak if the implementation strictly follows the current
logics of the exchange where the server-first-message includes a salt
and an iteration count specific to the username. Hence it seems
logical that if you want to fail because of unknown user, you would
fail directly after the client-first-message, hence giving away that
this is related to the client-first-message (before any kind of
password related data has been sent for instance).

As a consequence, even if I receive a "other-error", if I receive it
after the client-first-message and if I am absolutely sure that my
implementation is perfect (no problem of encoding, of SASL-SCRAM's
exchange syntax, no error in the channel binding, etc.), I am nearly
sure that I received this apparently generic error because the
username does not exist. Consequently again, if I don't receive the
error (or any error in fact) after the client-first-message, I am
absolutely sure the username exist, and I quietly stop the SASL
exchange at this point (and fill my database with this username for
further spam for instance).
Hence server data has been leaked.

The only way to prevent this is by continuing with the
server-first-message (and providing fake salt/iteration count) even
though you already know that it will fail in the end.
Therefore only after client-final-message can we send a other-error or
invalid-proof (whatever error as long as you send the same one
whichever the real error is that the password is wrong or that the
username does not exist).

So I think this would deserve a security note telling implementers
they can implement this way to avoid data leak. I will try to make a
proposition later.

Jehan

---

From: Chris Newman <[email-masked]>
Date: Fri, 03 Dec 2010 15:04:37 -0800

Not only do I disagree with your proposal to remove the no-such-user error, 
I consider it a useful capability for several use cases of a 
general-purpose protocol.

When it comes to a threat analysis of an entire system, sometimes hiding 
the no-such-user information has no security value at all and thus the 
diagnostic/maintenance benefit of the error becomes important.

For example, in SMTP servers, spam/virus/phishing is the #1 threat and the 
related denial of service attacks are important. Since it's impossible to 
detect spam/virus/phishing content until an after the DATA has been 
transferred (costing a lot of Internet bandwidth), it's important to reject 
an email with all invalid mail addresses before the DATA in order to 
minimize the denial-of-service impact on the mail server. So the ability to 
probe for valid mail addresses is present in a properly configured system. 
While administrators can choose to have mail addresses different from login 
identities that has a usability impact some administrators find 
unacceptable. So if they're the same, then on a properly configured mail 
system, whether an account is valid or not is public information. So the 
no-such-user error provides no additional information to attackers, but it 
provides very useful information to end-users and service desk teams.

I could also argue that the actual security has to come from the password, 
since there are so many other ways that usernames can leak. So pretending 
that usernames do not leak to attackers becomes a self-delusion that 
prevents sysadmins from paying proper attention to password security.

That's not to say I entirely disagree with your concern. There are many, 
perhaps the majority of use cases where obscuring username validity 
increases the magnitude of the attacker's problem enough to have real-world 
value. But SCRAM has sufficient provision for these cases already.

		- Chris

--On December 4, 2010 1:53:39 +0900 Jehan Pagès 
<[email-masked]> wrote:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 06 Dec 2010 16:52:38 -0500

--On Saturday, December 04, 2010 01:53:39 AM +0900 Jehan Pagès 
<[email-masked]> wrote:

> unknown-user error

No.  Not reporting unknown-user is a policy preference, and one which the 
protocol already permits.  You now propose to encode your policy preference 
into the protocol, thereby usurping the operator's authority to set policy.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 8 Dec 2010 10:23:22 -0800

On Dec 6, 2010, at 1:52 PM, Jeffrey Hutzelman wrote:

> --On Saturday, December 04, 2010 01:53:39 AM +0900 Jehan Pagès <[email-masked]> wrote:
> 
> No.  Not reporting unknown-user is a policy preference, and one which the protocol already permits.  You now propose to encode your policy preference into the protocol, thereby usurping the operator's authority to set policy.
> 
> -- Jeff

Agree with Jeff.  

In practice it's usually a lot easier to guess usernames ("smith"??) than it is passwords, so I don't see much loss.  Also in a large enterprise there are probably lots of different ways to find out a username.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]