Subject: SCRAM minimum PBKDF#2 iteration count

From: Simon Josefsson <[email-masked]>
Date: Mon, 09 Mar 2009 21:51:29 +0100

SCRAM currently contains:

      Servers SHOULD announce a hash iteration-count of at least 128.

I believe this is too low.  RFC 2898 (PKCS#5), an almost 10 year old
document contains:

   the difficulty of attack. For the methods in this document, a minimum
   of 1000 iterations is recommended. This will increase the cost of

A more recent document that uses PBKDF#2 is RFC 3962, published 2005,
and it uses a default of 4096 iterations.

There is a difference between a minimum value, and a default value.
Still, I believe we could reasonable suggest a minimum value of 4096
iterations for SCRAM.

Thoughts?

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Mar 2009 21:19:56 +0000

>Still, I believe we could reasonable suggest a minimum value of 4096
Works for me.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 09 Mar 2009 17:24:33 -0400

> There is a difference between a minimum value, and a default value.

Yes, there is.  A minimum value is one which must be advertised to all 
clients, including those which are mobile devices with limited processing 
power.  If using SCRAM makes fetching mail from a phone too slow, people 
will just keep using PLAIN.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Mar 2009 09:44:08 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> clients, including those which are mobile devices with limited
> processing power.  If using SCRAM makes fetching mail from a phone too
> slow, people will just keep using PLAIN.

Right.  This argues that the document need to discuss that point.  I
think a limited platform is a valid reason to not follow a SHOULD
related to the iteration count.  However, right now it is the server
that sets the iteration count.  Maybe we want the client to be able to
request a particular iteration count?  On the other hand, this adds
complexity to the protocol, and I'm not sure if it is worth it.

Anyway, if we are deviating from the recommended minimum iteration count
of 1000 specified close to ten years ago I think we need a motivation.
Supporting mobile devices may be one, but I think we need to understand
whether there are mobile devices out there that implement TLS, SCRAM,
SMTP, IMAP etc without being able to do 1000 SHA-1 iterations quickly.

/Simon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 10 Mar 2009 10:46:42 +0100

Simon Josefsson writes:
> Anyway, if we are deviating from the recommended minimum iteration 
> count of 1000 specified close to ten years ago I think we need a 
> motivation. Supporting mobile devices may be one, but I think we need 
> to understand whether there are mobile devices out there that 
> implement TLS, SCRAM, SMTP, IMAP etc without being able to do 1000 
> SHA-1 iterations quickly.

They do it quickly, but it may just burn the battery.

IMO we're better of with two values: A recommended default with vague 
language like "increase this by 15% per year", and a fixed minimum.

I'd like the fixed minimum to be smallish (suitable for use when TLS has 
already told the server who's on the other end) and the recommended 
default to be much larger.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Mar 2009 09:52:29 +0000

Simon Josefsson wrote:

>Right.  This argues that the document need to discuss that point.
>
Agreed.

>I think a limited platform is a valid reason to not follow a SHOULD
I don't think the complexity is worth it.

Besides, the iteration count can be stored together with user's secret, 
so it is really controlled by the server end.

>SMTP, IMAP etc without being able to do 1000 SHA-1 iterations quickly.
Yes. Can anybody in the WG comment on this?

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Mar 2009 11:22:37 +0100

Arnt Gulbrandsen <[email-masked]> writes:

>> motivation. Supporting mobile devices may be one, but I think we
>> need to understand whether there are mobile devices out there that
> I'd like the fixed minimum to be smallish (suitable for use when TLS
> has already told the server who's on the other end) and the
> recommended default to be much larger.

Is SCRAM likely to be ever used with client TLS authentication?  Why not
use EXTERNAL?

I believe the use case for SCRAM is for TLS without client
authentication, and possibly even without server authentication (hence
the channel binding).

/Simon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 10 Mar 2009 11:24:54 +0100

Simon Josefsson writes:
> Is SCRAM likely to be ever used with client TLS authentication?

I was thinking about TLS session resumption, actually. Mobile clients 
have a way of losing the connection and then reconnecting, so TLS 
session resumption happens quite often.

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Tue, 10 Mar 2009 11:57:21 +0000

On Mon Mar  9 21:24:33 2009, Jeffrey Hutzelman wrote:
> Yes, there is.  A minimum value is one which must be advertised to  
> all clients, including those which are mobile devices with limited  
> processing power.  If using SCRAM makes fetching mail from a phone  
> too slow, people will just keep using PLAIN.

The iteration count is only used in the generation of the actual  
shared secret from the password, though - once this is generated  
once, it can be stored for future authentications.

So while it's reasonable to say that initial authentication might be  
slower (and burn battery), subsequent authentication is roughly as  
fast as CRAM-MD5, isn't it?

Given the figures Simon gave on the XMPP Security list, I think a  
recommended minimum of 4096 is reasonable. (I'm enclosing that  
message, because I think it's probably useful to supply some context).

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

Subject: Re: [Security] TLS Libraries
From: Simon Josefsson <[email-masked]>
To: XMPP Security <[email-masked]>
Date: Fri, 06 Mar 2009 16:49:04 +0100
List-Id: XMPP Security <security.xmpp.org>

Dave Cridland <[email-masked]> writes:

> On Fri Mar  6 14:58:05 2009, Eric Rescorla wrote:
>> What do you mean rejects it? The attacker simulates a TCP-level
>> failure.
>> Alternately, he just stalls and waits for the client to give up if
>> he can't
>> brute-force the password in time.
>
> Right, well, I think I've made myself look stupid enough for one day,
> so I'll restrict myself to asking questions.
>
> So, we have some potential problems with the use of anything that's
> subject to an offline dictionary attack.
>
> Have you got any figures on timescales for this, and computing power
> required? I mean, is this something that anyone who hasn't upset the
> NSA or GCHQ should be concerned about, or are we within reasonable
> range of someone trying to phish credit card numbers?

SCRAM says to use an iteration count of 128, and due to the salting,
that means the attacker needs to perform 128 hashes to test a particular
password for one session.  'openssl speed sha1' on my machine does
around 1000000 16-byte hashes per second.  So the attacker can test
around 8000 passwords per second.  My /usr/share/dict/american-english
contains around 100000 words.  So it takes around 13 seconds to go
through this dictionary on my laptop.

This may not be completely correct, and I may be completely wrong about
something, but I hope the magnitude is about right.

Btw, this argues that the SCRAM iteration count should really be much
higher.  RFC 3962 uses 4096 by default but even that is slightly low.

/Simon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 10 Mar 2009 13:16:45 +0100

> once, it can be stored for future authentications.

Oh, right.

Might be good to mention this in the RFC, though. And particularly 
mention that a cacheless server is not very friendly to battery-powered 
clients.

> recommended minimum of 4096 is reasonable.

OK.

Arnt

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Mar 2009 13:52:44 +0100

> fast as CRAM-MD5, isn't it?

That assumes the server doesn't change the salt too frequently for the
particular user.  Some servers may not be able to store a salt, and may
just have access to username + password.  In this case, it would
generate a random salt on every connection.

On the other hand, I believe even 4096 hash iterations will be
sufficiently quick on any processor that is capable of implementing TLS
& SASL and a user interface.

> recommended minimum of 4096 is reasonable.

That works for me.

/Simon

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Mar 2009 15:31:53 +0000

> so it is really controlled by the server end.

However note that a very large proportion of users use multiple clients of
varying capability, so per-user isn't fine grained enough.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Mar 2009 16:04:03 +0000

>varying capability, so per-user isn't fine grained enough.
Tony, I don't think doing anything more granular (i.e. per-client) would 
work.

We want to allow servers to store hashed passwords. This means that the 
server end dictates the minimum iteration count.

We could extend the protocol to allow the client to say "oh, but I want 
to have an iteration count bigger than the one advertised by the 
server". But I really doubt any client would ever make use of this 
feature and so I think it adds unnecessary complexity.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 10 Mar 2009 16:40:22 +0000

> varying capability, so per-user isn't fine grained enough.

I don't think there's a significant problem with asking a mobile or  
embedded client to do 4097 SHA-1's the first time it logs in as a  
one-off. If it were every time, it'd be a problem, sure, but it  
shouldn't need to be.

I would add that this needs not only a stable iteration count, but a  
stable salt - implementations not capable of storing a salt should  
therefore generate one using some stable algorithm (like  
H(<username>,<server hostname>,<configured constant>) or something).

Dave.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Mar 2009 18:19:55 +0100

Alexey Melnikov <[email-masked]> writes:

> Tony, I don't think doing anything more granular (i.e. per-client)
> would work.
>
> We want to allow servers to store hashed passwords. This means that
> the server end dictates the minimum iteration count.

I don't think we can assume all servers will store hashed passwords.

There are many deployments where passwords are stored in separate
databases.  I would be surprised if all implementations supports stored
hashed passwords.

This means that we will see servers that use a random salt in SCRAM on
every connection.

If we don't want this, the protocol needs to require that servers store
hashed passwords and explain the problem that happens otherwise.  I'm
not sure it is practical to make this a MUST.  Or is there already text
in SCRAM to address this?

/Simon

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 10 Mar 2009 10:29:07 -0700

> I don't think we can assume all servers will store hashed passwords.

I agree.  Storing the actual password is common when the servers  
support a wide range of password-based authentication mechanisms.

> This means that we will see servers that use a random salt in SCRAM on

Or possibly separately store (per user) the salt they use for SCRAM.

> hashed passwords and explain the problem that happens otherwise.

I would oppose this as there is a general need to support a wide range  
of password-based authentication mechanisms.

> I'm not sure it is practical to make this a MUST.  Or is there  
> already text

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Mar 2009 17:23:23 +0000

>I don't think we can assume all servers will store hashed passwords.
We shouldn't assume that, but we shouldn't preclude that either.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Mar 2009 12:32:56 -0500

> language like "increase this by 15% per year", and a fixed minimum.

A minimum iteration count protects the client from downgrade attacks.

But when SCRAM is used with channel binding, as it ought to be, the
iteration count need only be high enough to prevent real-time, online
dictionary attacks.  In the channel binding mode then the iteration
count can be low and may not need to grow as time passes.

We might want two minimum iteration counts then: one for the channel
binding use case and one for the non-CB use case.

The problem with "increase this by X% per year" is that that implies
re-computing and replacing the password verifier stored by the server,
so if the client were to enforce such a moving target it would get
itself locked out unless the users change their passwords periodically.

Also, I'm not sure that Moore's "law" applies to mobile devices.  The
limiting factor for mobile devices is power, or, more likely, heat
dissipation, and Moore's law doesn't really apply there.  So, though an
"increase this by X% per year" seems quite sensible from a security
p.o.v., it may not be at all from a mobile hardware p.o.v.

Nico
--

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 10 Mar 2009 18:54:46 +0100

> This means that we will see servers that use a random salt in SCRAM on 

Or that derive the salt from e.g. the user name and a per-installation 
constant, as Dave suggested.

Anyway it's just a quality-of-service matter, and one that applies only 
to battery-powered clients.

Arnt

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Mar 2009 19:42:54 +0100

> support a wide range of password-based authentication mechanisms.

Right.

> Or possibly separately store (per user) the salt they use for SCRAM.

I don't think we can assume that all servers are able to do this either.

> of password-based authentication mechanisms.

I agree.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Mar 2009 19:48:05 +0100

Nicolas Williams <[email-masked]> writes:

> dictionary attacks.

Consider active attackers with offline dictionary attack ability.  Do a
MITM on one connection, get a SCRAM exchange, then go at the exchange
using your dictionary.  Return when you have found the password.

Given that a failed connection attempt are likely not noticed by the
majority of users, if it only happens once in a while, I think this is a
realistic scenario.

Whether it is worth worrying about is another question, but increasing
the minimum iteration count helps to mitigate this type of attack.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Mar 2009 13:54:46 -0500

> using your dictionary.  Return when you have found the password.

Correct, the "high enough to prevent real-time" attacks rule has to be
combined with heuristic detection of MITMs in the case that the server
fails to complete the SCRAM authentication exchange.

In the case of TLS w/o server certs that means every such failure has to
be treated as equivalent to handing an attacker material that can be
attacked off-line.

In the case of TLS w/ server certs a subsequent successful
authentication with channel binding means that the previous failure is
not a problem.

But I think the rest of this thread has brought us to a consensus: a
high iteration count is not a problem for mobile devices, particularly
provided that they can cache the PBKDF2 results.

So I think there's no need to distinguish CB and non-CB cases when it
comes to minimum iteration count.

Nico
--