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

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

-------- Original Message --------
Subject: [Technical Errata Reported] RFC5802 (2651)
Date: Tue, 30 Nov 2010 10:32:27 -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=2651

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

Section: 7

Original Text
-------------
    nonce           = "r=" c-nonce [s-nonce]
                      ;; Second part provided by server.

    c-nonce         = printable

    s-nonce         = printable

Corrected Text
--------------
    nonce           = "r=" c-nonce [s-nonce]
                      ;; Second part provided by server.

    c-nonce         = 1*(printable)

    s-nonce         = 1*(printable)

Notes
-----
"printable" is defined this way:
    printable       = %x21-2B / %x2D-7E
                      ;; Printable ASCII except ",".
                      ;; Note that any "printable" is also
                      ;; a valid "value".

Hence a "printable" is a single printable character (except ','). But a 
nonce is a "a sequence of random printable ASCII characters excluding 
','" (section 5.1), as can also be seen by the examples (and common 
sense for a security feature using randomness).

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:33:30 -0800

I believe this should be verified.

		- Chris

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

> ','" (section 5.1), as can also be seen by the examples (and common sense
> for a security feature using randomness).
>
> Instructions:
> -------------
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Martin Rex <[email-masked]>
Date: Thu, 2 Dec 2010 00:30:11 +0100 (MET)

> I believe this should be verified.

After looking up the ABNF syntax here:

  http://tools.ietf.org/html/rfc5234#section-3.6

I'm wondering what kind of "verification" you're looking for.

There appears to be a defect in the ABNF syntax for c-nonce and s-nonce
in RFC5802, and the proposed change appears to be the correct fix for it.

-Martin

> > Reported by: Jehan PagÃ¨s <[email-masked]>
> >
> > Section: 7
> >
> > Original Text
> > -------------

---

From: Martin Rex <[email-masked]>
Date: Thu, 2 Dec 2010 00:53:43 +0100 (MET)

> in RFC5802, and the proposed change appears to be the correct fix for it.

More specifically:

The existing ABNF definition for (c-nonce) and (s-nonce) limits them both
to one single printable character, which amounts to ~6.55 bits of 
nonce entropy.  What is missing is the variable repetition with a
minimum length of one.   The parentheses around (printable) are
not necessary, they create a sequence group with a single element.
But they don't hurt either.  The last sentence of section 3.5:

    http://tools.ietf.org/html/rfc5234#page-9

in my reading says that it is OK to use grouping parentheses for
visual clarity.

-Martin

---

From: Dave Cridland <[email-masked]>
Date: Thu, 02 Dec 2010 09:07:06 +0000

> I'm wondering what kind of "verification" you're looking for.

I think Chris is suggesting that this should be accepted by the  
verifying party (the IESG), rather than questioning whether this is  
correct.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 02 Dec 2010 09:25:34 +0000

> I believe this should be verified.

I concur.

>> sense

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 2 Dec 2010 22:50:48 +0900

Hi,

> in my reading says that it is OK to use grouping parentheses for

Yes I guess I added grouping parentheses around (printable) because I
saw this somewhere else in the spec. Checking again, I see that
(reserverd-mext) is defined this way with a grouping parenthese on a
single element:

reserved-mext  = "m=" 1*(value-char)

[ Note that (value) is already defined this way:
value           = 1*value-char
Maybe it would have been better/simpler to define reserved-mext like:
reserved-mext = "m=" value
But that would be an editorial change and in the end this is not a bug
anyway (plus, this is off-topic here). ]

So I added these parentheses out of clarity, but removing them is as
good as keeping them. As long as the actual bug is fixed. :-)

Jehan

---

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

I meant the status should be changed from "reported" to "verified". In 
other words, I find the fix necessary and correct.

		- Chris

--On December 2, 2010 0:30:11 +0100 Martin Rex <[email-masked]> wrote:

>> > Title               : Salted Challenge Response Authentication
>> > Mechanism (SCRAM) SASL and GSS-API Mechanisms