[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SCRAM-05 notes (was: Clarifying the qualities we desire the DIGEST-MD5 replacement to have)
Abhijit Menon-Sen writes:
>At 2008-03-12 09:33:43 -0500, Chris.Newman@xxxxxxx wrote:
>>> Regarding the SCRAM draft, I hope there'll be a version soon which
>>> spells out what each challenge and response consists of, and what
>>> the server must remember (or be able to construct). It's cumbersome
>>> to dig around in the parameter descriptions in order to figure that
>> Agree this needs work. I simply don't have time to be the active
>> editor on the document.
> I do, but I've held off working on the examples and appendices until I
> have a better understanding of what to do about GS2/GSSAPI. (...)
Some other SCRAM notes/questions, before I forget:
> 1.1. Terminology
> The authentication information for a
> SCRAM identity consists of salt and the "StoredKey" and
> "ServerKey" (as defined in the algorithm overview) for each
> supported cryptographic hash function.
Also iteration count. So, a set of tuples
(hash function, iteration count, salt, StoredKey, ServerKey).
If the iteration count is a config parameter instead of stored per hash,
the admin must throw away all hashes and get all users to set new
> 2. Introduction
> - The server does not gain the ability to impersonate the client to
> other servers (with an exception for server-authorized proxies).
Except to servers with the same parameters (salt, hash function,
iteration-count) for a particular hash. (It can collect the data
clients send, like a passive eavesdropper who has stolen server-side
hashes as described in Security Considerations.)
> - The mechanism permits the use of a server-authorized proxy without
> requiring that proxy to have super-user rights with the back-end
Huh? Is this a strange way to say it supports the SASL authorization
> 3. SCRAM Algorithm Overview
> Similarly, the client authenticates the server by computing the
> ServerSignature and comparing it to the value sent by the server.
Which value sent by the server? This section forgets to mention the
final server message.
> If the two are equal, it proves that the server had access to the
> user's SaltedPassword.
If the client reports that they are not equal, what should the user do?
Has anything been compromised? (If yes, the statement in the intro that
the client can authenticate the server is a bit misleading.)
> 4. SCRAM Authentication Exchange
> C: n=Chris Newman,h=md5,r=ClientNonce
> S: r=ClientNonceServerNonce,h=md5,s=PxR/wv+epq,i=128
> C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
> S: v=WxPv/siO5l+qxN4
Why do the client and server echo each others' nonces?
Something about inserting random data into each other's messages? If
so the client echo is not necessary, since it's included in the hash.
Or is it part of authenticating to each other? The 'r:' description
in 4.1 says the client must verify the nonce, but the server need not.
> First, the client sends a message containing the username, a list of
> the hash functions it supports, and a random, unique nonce. In
> response, the server sends its list of supported hash functions, an
> iteration count i, the user's salt, and appends its own nonce to the
> client-specified one. The client then responds with the same nonce
> and a ClientProof computed as explained earlier.
This looks both too inflexible and too flexible...
I imagine the desired iteration count could depend on the hash function:
The stronger/more expensive hash function, the weaker iteration count.
Or have I guessed wrong what this count is for? (Please explain in
section 5. How to pick a good iteration count?)
The admin could also increase the count for new hashes at some point,
but keep the old hashes with old iteration counts around for a while.
The client must also send the hash function again, if the server
announced several hashes.
> 7. Security Considerations
> If the server detects (from the value of the client-specified "h"
> attribute) that both endpoints support a stronger hash function that
> the one the client actually chooses to use, then it SHOULD treat
> this as a downgrade attack and reject the authentication attempt.
This requires an ordering by strength which the peers agree on, so the
client can select a hash function the server will accept. Instead, let
the server send a list of the hash functions it will accept in this auth
exchange. (Intersection of the ones the client sent and the hashes
available for that user.)
But this "downgrade attack" can be performed easily enough by asking for
weak hash functions which the client is prepared to crack. Maybe first
ask for only weak hash functions, then stronger in another auth
If the server has a lockout after N failed auth attemts for a user, one
could explore the server a bit first by seeing what functions the server
offers for other users than the "target" user.
Back to section 4...
> 4.1 SCRAM attributes
> - n: (...)
> The characters ',' or '=' in usernames are sent as '=2C' and '=3D'
> respectively. If the server receives a username which contains '='
> not followed by either '2C' or '3D', then the server MUST fail the
Is that "MUST" important? It means a protocol which uses UTF-8
identities but allows a wider character range than 'value-safe-char'
must use another escape mechanism in addition.
> - r: (...) No quoting is applied to this string (unless
> the binding of SCRAM to a particular protocol states otherwise).
What does this mean? There isn't any quoting elsewhere in SCRAM either.
And it's not about '=' escaping, since the example shows 'r=' need
not be the last field.
> - c: This optional attribute specifies base64-encoded channel-
> binding data. It may be sent by either the client or the server.
In the first message which either sends?
> - i: This attribute specifies an iteration count for the selected
> hash function, and must be sent by the server along with the
> user's salt.
A hostile server can perform a denial of service attack (against clients
for which this is a meaningful term) by sending a huge iteration count.
Clients can do the same if the server lets clients send plaintext
passwords which it will hash and store as their password, and it lets
clients configure their own hash function and iteration count.
Peers could check the count against a configured max value. Servers
which allow clients to store a prehashed server secret with iteration
count, might also require the stored count to be reasonable.
> 7. Security Considerations
> If the external security layer used to protect the SCRAM exchange
> uses an anonymous key exchange,
What does that mean? The server does not send a certificate or similar
ID? Does it make a difference if the client is anonymous?
> If an attacker obtains the authentication information from the
> authentication repository and either eavesdrops on one
> authentication exchange or impersonates a server, the attacker gains
> the ability to impersonate that user to all servers providing SCRAM
> access using the same password and salt.
same server secret (same hash function, iteration count, password, salt).