
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <hbf.20070430vknn@bombur.uio.no>
Date: Mon, 30 Apr 2007 21:05:49 +0200
To: ietf-sasl@imc.org
Subject: Re: Hide presence/absence of users in server (HEXA, SCRAM)
In-Reply-To: <hbf.20070430yyzi@bombur.uio.no>
References: <hbf.20070430yyzi@bombur.uio.no>
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk

I wrote:
> Generate the salt from the authcid and a random secret string, and
> we are better off -
> (...)
> One could generate "real" salts the same way, in case one could tell
> fake from real salts from the algorithm which generates them.

...and then if it is possible to tell the difference, "real" salts get
less than random and thus an attack on a real user easier.  Not my
brightest idea.

-- 
Regards,
Hallvard


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UFgxVV085364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 08:42:59 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3UFgxQY085363; Mon, 30 Apr 2007 08:42:59 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UFgaLa085308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-sasl@imc.org>; Mon, 30 Apr 2007 08:42:58 -0700 (MST) (envelope-from hbf@bombur.uio.no)
Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from <hbf@bombur.uio.no>) id 1HiY1L-0000TQ-QB for ietf-sasl@imc.org; Mon, 30 Apr 2007 17:42:35 +0200
Received: from bombur.uio.no ([129.240.202.105]) by mail-mx9.uio.no with esmtp (Exim 4.66) (envelope-from <hbf@bombur.uio.no>) id 1HiY1L-0006Iu-Di for ietf-sasl@imc.org; Mon, 30 Apr 2007 17:42:35 +0200
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HiY1J-000112-4w for ietf-sasl@imc.org; Mon, 30 Apr 2007 17:42:33 +0200
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Message-Id: <hbf.20070430yyzi@bombur.uio.no>
To: ietf-sasl@imc.org
Subject: Hide presence/absence of users in server (HEXA, SCRAM)
Date: Mon, 30 Apr 2007 17:42:33 +0200
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.3, required=12.0, autolearn=disabled, AWL=0.736,UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 4E8A346FC9E8D27004AEDBF5BC6C88E31AF00594
X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -42 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 246 max/h 5 blacklist 0 greylist 0 ratelimit 0
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:ietf-sasl-request@imc.org?body=unsubscribe>

draft-cridland-sasl-hexa-00.txt.gz and draft-newman-auth-scram-04.txt
describe SASL mechanisms that send the salt from the authcid's server
secret in a challenge.  They need to specify what to send if the authcid
is not found or cannot be authenticated with the mechanism.

Returning a failure immediately would allow clients to use SASL to
discover the presence or indicate the absence of specific authcids in
the server.  I think that'd be wrong, at least for the default behavior.

A fix may be nontrivial though, depending on how seriously one wants to
hide this information.  I guess the fix for the drafts is to just
specify that the mechanism should by default act as if the authcid was
present, and to refer to some other document for the general problem of
faking the existence of users.

Anyone know such a document?  I can only list some quick thoughts on
the subject.  Hopefully someone has written something more thorough:


If you just send a fixed salt for non-existent uses, the client can
compare the salts for several authcids and discover which ones use the
same.  Send a random salt, and one can ask for the same authcid twice
and compare the salts.

Generate the salt from the authcid and a random secret string, and
we are better off - but first the server/protocol must normalize
the authcid.  E.g. if the server looks up SASL users in a case-
insensitive fashion (even when the mechanism says authcids are
case-sensitive), then "john" and "John" must get the same salt.

One could generate "real" salts the same way, in case one could tell
fake from real salts from the algorithm which generates them.

You may want to change the random secret string once in a while, so one
can't notice over time the giveaway that a lot of users don't seem to
ever change their passwords.  That gets messy because a lot of users
would apparently change their password (and salt) at the same time,
which would also giveaway.  So... generate the supposed time of password
change from authcid and one secret random string, and use that to select
from a set of other secret random strings which is used to generate the
salt..


By now I'm far beyond what makes sense to say in a mechanism spec
though.  Which is why a reference to another document makes more sense.

After all it may be trivially easy to discover the existence of a user
in any case, e.g. if the users can be found with 'ypcat passwd' on Unix
or can be looked up via the protocol.

Also one can often discover the presence/absence of users in other
ways, even if the protocol's way of hiding users is to pretend they
are not there.  E.g. take the time of protocol requests (auth or other
operations) involving the user.

-- 
Regards,
Hallvard


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RFHhdr048098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 08:17:43 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3RFHhEd048097; Fri, 27 Apr 2007 08:17:43 -0700 (MST) (envelope-from owner-ietf-sasl@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f
Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3RFHgQP048091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-sasl@imc.org>; Fri, 27 Apr 2007 08:17:43 -0700 (MST)
Received: from iesg by megatron.ietf.org with local (Exim 4.43) id 1HhSCc-0001Vd-Bu for ietf-sasl@imc.org; Fri, 27 Apr 2007 11:17:42 -0400
Content-Type: multipart/mixed; boundary="===============0860186178=="
MIME-Version: 1.0
Content-Disposition: inline
From: iesg@ietf.org
Subject: Please confirm your message
Reply-To: iesg+ietf-confirm+1177687062.5801.f81837@ietf.org
Date: Fri, 27 Apr 2007 11:17:42 -0400
Message-ID: <1177687062.5801.TMDA@stiedprmman1.va.neustar.com>
To: ietf-sasl@imc.org
Auto-Submitted: auto-replied
X-Delivery-Agent: TMDA/1.1.11 (Ladyburn)
Sender: owner-ietf-sasl@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:ietf-sasl-request@imc.org?body=unsubscribe>

--===============0860186178==
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Description: Confirmation Request
Content-Disposition: inline

This message was created automatically by mail delivery software (TMDA).

Your message attached below is being held because the address
<ietf-sasl@imc.org> has not been verified.

To release your message for delivery, please send an empty message
to the following address, or use your mailer's "Reply" feature.

   iesg+ietf-confirm+1177687062.5801.f81837@ietf.org

This confirmation verifies that your message is legitimate and not
junk-mail. You should only have to confirm your address once.

If you do not respond to this confirmation request within 14 days,
your message will not be delivered.

--===============0860186178==
Content-Type: message/rfc822
MIME-Version: 1.0
Content-Description: Original Message
Content-Disposition: inline

Return-path: <ietf-sasl@imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSCc-0001VV-1Y
	for iesg@ietf.org; Fri, 27 Apr 2007 11:17:42 -0400
Received: from [57.73.22.34] (helo=vm-apidev)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhSCa-0001Ky-HT
	for iesg@ietf.org; Fri, 27 Apr 2007 11:17:42 -0400
From: "ietf-sasl" <ietf-sasl@imc.org>
To: <iesg@ietf.org>
Subject: Fw: DSC-00465.jpg
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_2.12007641792297E-02"
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014

This is a multi-part message in MIME format.

------=_NextPart_2.12007641792297E-02
Content-Type: text/plain; format=flowed

forwarded message attached.

------=_NextPart_2.12007641792297E-02


------=_NextPart_2.12007641792297E-02--

--===============0860186178==--