Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652)

From: Sean Turner <[email-masked]>
Date: Wed, 09 Mar 2011 10:08:40 -0500

So to close the loop on this one:  I'm going to edit the errata to 
replace the text suggested by Jehan with the text suggested by Simon.

spt

On 1/20/11 4:52 AM, Simon Josefsson wrote:
> Jehan Pagès<[email-masked]>  writes:
>
>> After:
>> ----------------------------------
>> 9. Security Considerations
>>
>> <snip>
>>
>>     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 hash function, password, iteration count, and salt.  For this
>>     reason, it is important to use randomly generated salt values.
>> -----------------------------------
>> Add the following paragraph:
>> -----------------------------------
>> Though an empty string is theoretically a perfectly valid random
>> value, as long as it has the same probability to be generated as any
>> other string, in practice this special case may weaken the salted
>> password. Consequently a server implementation should wisely check a
>> newly generated salt for not being empty, and generate it again if
>> necessary before any further step, whereas a client implementation
>> might refuse to authenticate when an empty salt is received.
>> -----------------------------------
>
> I think we should add something that implementations should have a
> minimum accepted salt length, for security reasons.  A 1 byte octet salt
> does not make sense.  I don't think we want to say that all strings
> should have the same probability to be generated -- an implementation
> that picks good random 15 character strings for salt is OK but there is
> 0 probability for that implementation to generate a 14 character string,
> so it would fail your language.
>
> I suggest to add a sentence after
>
>      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 hash function, password, iteration count, and salt.  For this
>      reason, it is important to use randomly generated salt values.
>
> that says
>
>      Further, implementations are RECOMMENDED to reject salt values
>      shorter than 2 characters and MAY reject even longer salt values if
>      they are considered to be insufficient.  See [RFC4086] on generating
>      randomness.
>
> /Simon
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Jehan Pagès <[email-masked]>
Date: Sun, 13 Mar 2011 19:53:19 +0900

Hi,

On Thu, Mar 10, 2011 at 12:08 AM, Sean Turner <[email-masked]> wrote:
> So to close the loop on this one:  I'm going to edit the errata to replace
> the text suggested by Jehan with the text suggested by Simon.

I would say I agree. :-)
Regards,

Jehan

>> Jehan Pagčs<[email-masked]>  writes:
>>
>>> After: