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

Hi,

On Thu, Dec 2, 2010 at 7:37 AM, Chris Newman <chris.newman <at> oracle.com> wrote:
> 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.
>

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

>                - Chris
>
> --On December 1, 2010 10:34:27 -0500 Sean Turner <turners <at> ieca.com> wrote:
>
>> -------- Original Message --------
>> Subject: [Technical Errata Reported] RFC5802 (2652)
>> Date: Tue, 30 Nov 2010 10:58:12 -0800 (PST)
>> From: RFC Errata System <rfc-editor <at> rfc-editor.org>
>> To: chris.newman <at> oracle.com, ams <at> toroid.org, Alexey.Melnikov <at> isode.com,
>> Nicolas.Williams <at> oracle.com, turners <at> ieca.com, tim.polk <at> nist.gov,
>> tlyu <at> mit.edu, kurt.zeilenga <at> isode.com
>> CC: jehan <at> zemarmot.net, sasl <at> ietf.org, rfc-editor <at> rfc-editor.org
>>
>>
>> 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 <jehan <at> zemarmot.net>
>>
>> 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
>>
>> _______________________________________________
>> Kitten mailing list
>> Kitten <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/kitten
>>
>
>
>
>
> _______________________________________________
> Kitten mailing list
> Kitten <at> ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>