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

From: Sean Turner <[email-masked]>
Date: Wed, 01 Dec 2010 10:34:27 -0500

-------- Original Message --------
Subject: [Technical Errata Reported] RFC5802 (2652)
Date: Tue, 30 Nov 2010 10:58:12 -0800 (PST)
From: RFC Errata System <[email-masked]>
To: [email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked]
CC: [email-masked], [email-masked], [email-masked]

The following errata report has been submitted for RFC5802,
"Salted Challenge Response Authentication Mechanism (SCRAM) SASL and 
GSS-API Mechanisms".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5802&eid=2652

--------------------------------------
Type: Technical
Reported by: Jehan Pagès <[email-masked]>

Section: 7

Original Text
-------------
    base64-char     = ALPHA / DIGIT / "/" / "+"

    base64-4        = 4base64-char

    base64-3        = 3base64-char "="

    base64-2        = 2base64-char "=="

    base64          = *base64-4 [base64-3 / base64-2]

Corrected Text
--------------
    base64-char     = ALPHA / DIGIT / "/" / "+"

    base64-4        = 4base64-char

    base64-3        = 3base64-char "="

    base64-2        = 2base64-char "=="

    base64          = *base64-4 (base64-4 / base64-3 / base64-2)

Notes
-----
The original version would allow the empty string (hence the base64 
encoding of an empty string). Though it may technically be an acceptable 
base64 encoded string, it is not acceptable in our use as we use it for 
security features which are not supposed to be empty (though it is not 
defined this way, but common sense tells).

This formal definition added to the fact there is no textual 
counter-indication would imply it is authorized to generate for instance 
an empty salt, salt being formally defined as:

salt            = "s=" base64

And textually (section 2.1):
"Salt: A random octet string that is combined with a password
       before applying a one-way encryption function.  This value is used
       to protect passwords that are stored in an authentication
       database.
"

Other uses of base64 (proof, verifier and channel-binding) are less 
problematic as they are encoding of formerly exchanged data (hence if 
empty, it would fail the exchange). But salt being generated by client 
and server, the current definition would authorize an obviously faulty 
random salt-generation behaviour.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5802 (draft-ietf-sasl-scram-11)
--------------------------------------
Title               : Salted Challenge Response Authentication Mechanism 
(SCRAM) SASL and GSS-API Mechanisms
Publication Date    : July 2010
Author(s)           : C. Newman, A. Menon-Sen, A. Melnikov, N. Williams
Category            : PROPOSED STANDARD
Source              : Simple Authentication and Security Layer
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Chris Newman <[email-masked]>
Date: Wed, 01 Dec 2010 14:37:32 -0800

This is an incompatible change that I consider inappropriate to make via 
errata. I believe this should be rejected. I would not object to discussing 
this change in the context of a candidate change for a recycle of this RFC 
at proposed standard status.

		- Chris

--On December 1, 2010 10:34:27 -0500 Sean Turner <[email-masked]> wrote:

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

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 2 Dec 2010 23:00:41 +0900

Hi,

> at proposed standard status.

so it means we consider it acceptable to have empty base64 strings,
hence in particular that the generation of an empty string for salt is
acceptable in SCRAM?

Jehan

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Dec 2010 10:24:29 -0600

> hence in particular that the generation of an empty string for salt is

There's a subtle difference between rejecting a malformed message in
code generated from a syntax like ABNF and rejecting a message after
it's been parsed.  I don't think that would be a big difference here,
but I also see no reason to publish an erratum over this.  Note that the
size of the salt is not terribly important -- a server impersonator gets
to tell the client whatever salt it wants, and the size of the salt has
nothing to do with computational difficulty.

Nico
--

---

From: Tony Hansen <[email-masked]>
Date: Thu, 02 Dec 2010 11:27:34 -0500

On 12/2/2010 9:00 AM, Jehan Pagès wrote:
> On Thu, Dec 2, 2010 at 7:37 AM, Chris Newman<[email-masked]>  wrote:

IMO, it's stupid for production use, but occasionally useful in testing 
scenarios.

     Tony Hansen
     [email-masked]

---

From: Chris Newman <[email-masked]>
Date: Thu, 02 Dec 2010 07:42:46 -0800

--On December 2, 2010 23:00:41 +0900 Jehan Pagès 
<[email-masked]> wrote:
>> errata. I believe this should be rejected. I would not object to
>> discussing this change in the context of a candidate change for a
>> recycle of this RFC at proposed standard status.
>

I feel very strongly that it is acceptable. My base64 encoding and decoding 
library code absolutely accepts empty strings and I have no intention of 
changing that behavior.

> hence in particular that the generation of an empty string for salt is

I draw no such conclusion. An empty salt is a security error regardless of 
what the document says or does not say, but it is not a protocol error 
according to RFC 5802 as written. We could consider making that 
incompatible change to the protocol syntax in a future revision, but it is 
not an appropriate change for errata.

		- Chris

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Dec 2010 11:13:04 -0600

On Thu, Dec 02, 2010 at 07:42:46AM -0800, Chris Newman wrote:
> I feel very strongly that it is acceptable. My base64 encoding and
> decoding library code absolutely accepts empty strings and I have no
> intention of changing that behavior.

+1.

> I draw no such conclusion. An empty salt is a security error
> regardless of what the document says or does not say, but it is not
> a protocol error according to RFC 5802 as written. We could consider
> making that incompatible change to the protocol syntax in a future
> revision, but it is not an appropriate change for errata.

I would agree to an erratum that adds security considerations text
saying that one should not accept empty salts.  Also, I'm thinking it'd
have helped to make sure to add the client name to the salt...  (*sigh*)

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Thu, 02 Dec 2010 12:38:39 -0500

> have helped to make sure to add the client name to the salt...  (*sigh*)

Is it really a problem to use an empty salt, or is it only a problem to
use an empty salt every time?

Put another way, if I use the salt "fred" every time, is that any better
than using the salt "" every time?  If not, does it make sense for the
acceptor to police the sender's salt entropy based on one specific piece
of circumstantial evience, and not more comprehensively?

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 3 Dec 2010 02:39:21 +0900

Hi,

On Fri, Dec 3, 2010 at 2:13 AM, Nicolas Williams
<[email-masked]> wrote:
>> --On December 2, 2010 23:00:41 +0900 Jehan Pagčs
>> >

Of course, as I said, it is an acceptable base64 encoding, and an
empty string is an absolutely acceptable entry to a base64 function. I
never said the opposite, nor did I suggest to modify base64 (if so, I
would have proposed an erratum to the base64 RFC, not the SCRAM RFC).
I quote myself from the erratum:

"Though it may technically be an acceptable base64 encoded string, it
is not acceptable in our use as we use it for security features which
are not supposed to be empty"

What I said is just that an empty salt is not a wise idea and should
not be acceptable in SCRAM. Let's say that the base64 ABNF definition,
allowing empty base64 encoded salt, was just the consequence of the
possibility of having empty salt. But I probably explained this badly.

> have helped to make sure to add the client name to the salt...  (*sigh*)

This solution (an erratum about adding security considerations to
refuse empty salts) would be acceptable in my view, and in the end
equivalent to my proposed erratum (as for the goal I wrote it, which
is not to have empty salts).

Jehan

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 3 Dec 2010 02:49:30 +0900

Hi,

> of circumstantial evience, and not more comprehensively?

I see your point and I would say that there is no problem apparently
in an empty salt as long as it is the same probability to generate
this empty salt "", than "fred" or any other random string.

But on the other hand, the empty string is somehow particular. And if
some attacker makes tables of salted passwords, that one would begin
by using "special" salts, like the empty strings, or "fred"
(dictionary words), on the hypothesis that the implementation is bad
and uses non-random salt. So we cannot obviously forbid any kind of
common word as a salt, but at least, we can make a special case for
the empty string (which is like the most special of all special
cases).

Jehan

---

From: Chris Newman <[email-masked]>
Date: Thu, 02 Dec 2010 10:15:03 -0800

> have helped to make sure to add the client name to the salt...  (*sigh*)

Actually, adding the login name to the salt was one of the (many) design 
flaws in DIGEST-MD5. It makes it impossible to change a login name without 
also resetting the password in some way and that leads to complexity in 
provisioning systems and/or support calls (and these are deployment 
deterrents for the mechanism). The common reason for changing a login name 
is marriage or divorce and in both cases the end-user tends to be 
intolerant of problems (albeit for different reasons).

		- Chris

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Dec 2010 20:54:57 +0100

Chris Newman <[email-masked]> writes:

> This is an incompatible change that I consider inappropriate to make
> via errata. I believe this should be rejected. I would not object to

+1

The security considerations already state:

   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.

Unfortunately RFC 4086 is not referenced there, but the intention should
be clear.  The requirement to use random salt values could be added the
description of salt values to further re-inforce this.

FWIW, my implementation GNU SASL checks that salt is at least non-empty.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Dec 2010 14:09:45 -0600

On Thu, Dec 02, 2010 at 10:15:03AM -0800, Chris Newman wrote:
> Actually, adding the login name to the salt was one of the (many)
> design flaws in DIGEST-MD5. It makes it impossible to change a login
> name without also resetting the password in some way and that leads
> to complexity in provisioning systems and/or support calls (and
> these are deployment deterrents for the mechanism). The common
> reason for changing a login name is marriage or divorce and in both
> cases the end-user tends to be intolerant of problems (albeit for
> different reasons).

I know.  But that could have been handled somewhat differently (I
think).  I don't really want to re-open that issue, so I'll let it lie.

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 3 Dec 2010 09:54:52 +0900

Hi,

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

Simply my initial proposition to modify the base64's formal syntax for
this goal was probably inelegant and clumsy, because I was proposing
to modify the consequence instead of the source.  In this optic,
Nicolas Williams's proposition to add security considerations text (in
order to explicitly refuse empty salt) is a much nicer solution than
mine. And I think we should go this way.

Jehan

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 03 Dec 2010 07:15:39 +0100

> security reason. And this is exactly the point that I think is worth

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

---

From: Chris Newman <[email-masked]>
Date: Fri, 03 Dec 2010 10:27:05 -0800

> mine. And I think we should go this way.

I have no objection to that approach.

		- Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 06 Dec 2010 16:47:30 -0500

--On Wednesday, December 01, 2010 02:37:32 PM -0800 Chris Newman 
<[email-masked]> wrote:

> discussing this change in the context of a candidate change for a recycle
> of this RFC at proposed standard status.

It's also a layering violation.  If we want to require that salt strings be 
non-empty, then we should _say_ that salt strings are non-empty, rather 
than changing the ABNF for "base64" on the assumption that this restriction 
is appropriate for all current and future uses of that nonterminal.

-- Jeff