Subject: [sasl] Implementing SCRAM (4)

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Sep 2009 13:32:49 +0200

The nonce description text says:

   o  r: This attribute specifies a sequence of random printable
      characters excluding ',' which forms the nonce used as input to
      the hash function.

However the ABNF for nonce is:

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

     c-nonce         = value

     s-nonce         = value
...
     value           = 1*value-char

     value-safe-char = %x01-2B / %x2D-3C / %x3E-7F /
                       UTF8-2 / UTF8-3 / UTF8-4
                       ;; UTF8-char except NUL, "=", and ",".

     value-char      = value-safe-char / "="

The ABNF implies that a string containing ASCII control characters 1-31
are permitted, and those values are not printable.

To resolve the inconsistency, I propose to modify the ABNF to only
permit printable ASCII characters (except for ',') in nonce fields:

OLD:
     c-nonce         = value

     s-nonce         = value

NEW:
     c-nonce         = printable

     s-nonce         = printable

     printable       = %x21-2B / %x2D-7F
                       ;; Printable ASCII except ",".
/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Sep 2009 12:58:04 +0100

>                       ;; Printable ASCII except ",".
That would be Ok with me. This also disallowes multibyte UTF-8 
sequences, which is a good thing.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 10 Sep 2009 13:33:10 -0400

--On Thursday, September 10, 2009 12:58:04 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

> That would be Ok with me. This also disallowes multibyte UTF-8 sequences,
> which is a good thing.

I'm not sure why that's a "good thing", as opposed to merely neutral. 
However, even if you omit ASCII control characters below 0x20, what was 
there before admitted various other control characters, including 
0x80..0x9f and a variety of control characters elsewhere in unicode.  Since 
this is a random string and not meaningful, I see no reason not to restrict 
it to ASCII printables.

Note that 0x20 (space) is technically printable, while 0x7f is definitely a 
control.

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Sep 2009 21:26:27 +0100

> I'm not sure why that's a "good thing", as opposed to merely neutral. 

I was thinking about disallowing invalid UTF-8 sequences, but aparently 
this wasn't a problem with the ABNF. So never mind that.

> However, even if you omit ASCII control characters below 0x20, what 
> was there before admitted various other control characters, including 
> 0x80..0x9f and a variety of control characters elsewhere in unicode.  
> Since this is a random string and not meaningful, I see no reason not 
> to restrict it to ASCII printables.
>
> Note that 0x20 (space) is technically printable, while 0x7f is 
> definitely a control.

Ok, I will exclude 0x7f.

I don't have strong feelings about SP. If left it as is for now.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Sep 2009 15:31:47 -0500

...

These are nonces.  They should be random, yes, but preferably printable
and valid characters, so that humans can actually inspect SCRAM messages
(that was the whole point of using textual encodings).

Therefore it seems perfectly reasonable to me to restrict the nonces to
the subset of ASCII needed for base64 encoding.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Sep 2009 23:08:24 +0200

> the subset of ASCII needed for base64 encoding.

The above covers the ASCII subset needed for base64, but does not
restrict nonces to be valid base64 data.  I think that is a good
tradeoff -- implementers can use base64 encoding of random data to
generate a nonces but could also use something separate that isn't as
complex as base64.  Noone should interpret (e.g., base64 decode) nonce
fields.

(My implementations uses base64 on random bytes to generate the SCRAM
nonce fields, and takes care to chose lengths so that base64 padding
characters are not present.)

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Sep 2009 22:14:50 +0100

>complex as base64.  Noone should interpret (e.g., base64 decode) nonce
+1

>characters are not present.)
Same here.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 10 Sep 2009 13:02:12 +0100

>                        ;; Printable ASCII except ",".

This seems reasonable, but you've allowed '=', previously this was  
explicitly not allowed.

Was this intentional?

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: Fri, 11 Sep 2009 13:23:53 +0100

> This seems reasonable, but you've allowed '=', previously this was  

No. I will fix.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Sep 2009 14:39:13 +0200

>> This seems reasonable, but you've allowed '=', previously this was

I'm not sure about that, '=' was permitted in the old syntax:

     c-nonce         = value

     s-nonce         = value

     value           = 1*value-char

There is no reason why the nonce cannot contain '='.

Especially if people use base64 encoded random binary to generate
nonces, preventing '=' in the string may aggravate implementers.

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Sep 2009 14:10:40 +0100

> There is no reason why the nonce cannot contain '='.
I'm not arguing for or against '=', I just thought there was a change.

> nonces, preventing '=' in the string may aggravate implementers.

If '=' were prohibited, it's very easy to simply trim off the '=',  
which in base64 is only used for padding, after all, and is entirely  
redundant.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Sep 2009 14:17:59 +0100

>nonces, preventing '=' in the string may aggravate implementers.
Right.

No change then.