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

From: Jehan Pagès <[email-masked]>
Date: Thu, 20 Jan 2011 12:17:20 +0900

Hi,

sorry I got caught up in several stuffs the whole month and left
several stuffs unattended on a few topic. I am back on the horse.

2010/12/3 Simon Josefsson <[email-masked]>:
> Jehan Pagès <[email-masked]> writes:
>
>> Hi,
>>
>> On Fri, Dec 3, 2010 at 4:54 AM, Simon Josefsson <[email-masked]> wrote:
>>> Chris Newman <[email-masked]> writes:
>>> FWIW, my implementation GNU SASL checks that salt is at least non-empty.
>>>
>>
>> But that's exactly the point of my erratum. Currently SASL-SCRAM does
>> not say that the salt must not be empty. And the base64's formal
>> syntax currently authorizes it to be empty. Hence as the salt is
>> passed base64-encoded, we could assume the RFC currently authorizes
>> the salt to be empty.
>> But as you say, your implementation checks a salt is not-empty for
>> security reason. And this is exactly the point that I think is worth
>> being added in the spec.
>
> It is already mentioned by the spec, see above (a randomly generated
> salt is rarely empty), although I can certainly agree that it could be
> re-inforced with stronger language and with a reference to 4086.  I
> don't believe empty salts should be forbidden at the syntax level.
>
> Please propose updated text, and I'm sure it can be included in 5802bis.
>
> /Simon

Ok so as we all (even me) agree that my approach to the problem was
not right and that an updated security considerations section could be
a better suited solution.
So I propose to reject my errata, and propose this kind of update to
be discussed on this list (I may not be the best RFC writer, so don't
hesitate to heavily modify):

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.
-----------------------------------

And then move the following line from the end of the "Security
Considerations" section to just after the previously written paragraph
where it is more significant:
-----------------------------------
See [RFC4086] for more information about generating randomness.
-----------------------------------

Thanks.

Jehan

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Jan 2011 10:52:42 +0100

> After:

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

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

---

From: Greg Hudson <[email-masked]>
Date: Thu, 20 Jan 2011 11:37:40 -0500

>     they are considered to be insufficient.  See [RFC4086] on generating

Is it common to use language like this (RFC 2119 words) in a security
considerations section?

If you can only interoperate by using salts above a certain length, then
it seems like that should be part of the syntactic or semantic
constraints of the actual standard section describing salts.

I continue to think it's pointless complexity for one side of a
connection to police the other side's randomness.  A zero-length salt
could be the very uncommon output of a random-length salt generation
process, and a 15-character salt could be a fixed string.  But I seem to
be in the rough.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Jan 2011 21:50:58 +0100

> Is it common to use language like this (RFC 2119 words) in a security

It is probably better to avoid it.

> constraints of the actual standard section describing salts.

I don't think that conclusion follows -- there are many things permitted
by syntax rules that are forbidden by semantic rules.  Pushing all
semantic rules down into syntax rules is not always a good thing.  I
wouldn't oppose doing so if others feel it is a better way.

> process, and a 15-character salt could be a fixed string.  But I seem to

Not necessarily.  I don't see a serious problem with the current
specification here, despite my proposal to add more text.  The spec
already says salts should be random.

/Simon

---

From: Greg Hudson <[email-masked]>
Date: Thu, 20 Jan 2011 23:48:43 -0500

> wouldn't oppose doing so if others feel it is a better way.

I said "syntactic or semantic constraints"; I wasn't advocating one or
the other.  I was just arguing that interoperability constraints should
be documented in the appropriate section of the main RFC, not in
security considerations text.

---

From: krithika swaminathan <[email-masked]>
Date: Fri, 21 Jan 2011 14:22:34 +0530

Hello All,

Can you please unscubscribe me from this list

Thanks
Krithika S

On Fri, Jan 21, 2011 at 10:18 AM, Greg Hudson <[email-masked]> wrote:

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 21 Jan 2011 14:19:48 +0100

> security considerations text.

Oh, sorry.  I agree.

/Simon