Subject: [precis] draft-ietf-precis-saslprepbis: byte or char ABNF; empty passwords

From: "Manger, James" <[email-masked]>
Date: Mon, 17 Nov 2014 13:25:59 +1100

A couple of comments on draft-ietf-precis-saslprepbis-09:

1. Is the ABNF in terms of bytes or Unicode code points?
<userpart> seems to be in bytes as it is 1 or more <idbyte>s.
<password> seems that it might be in code points as it is one or more <freepoint>s, where a <freepoint> is a UTF-8 encoded Unicode code point. But it mentions UTF-8 that would be unnecessary if it is in code points.
Byte-based rules don't seem to make much sense as UTF-8 requires bytes in a specific order.

I suggest writing the ABNF in terms of Unicode code points, and explicitly stating this.

2. The ABNF for <username> is:
  username   = userpart [1*(1*SP userpart)]
The 2nd term is an optional sequence of 1 or more things. Isn't that the same as 0 or more things?
I suggest simplifying the ABNF to:
  username   = userpart *(1*SP userpart)

3. Is there ABNF for <freepoint> and <idbyte>?
These 2 rules are used, but not defined. Perhaps the only definition is the comment that follow their use? If so, could that be stated a bit more explicitly so readers don't hunt through other precis docs and references looking for them.

4. Empty password.
An empty password is not secure, but a 1-char password isn't appreciably better. What is the reason for saying "a password MUST NOT be zero bytes in length"? I would drop this requirement.

--
James Manger

---

From: Alan DeKok <[email-masked]>
Date: Sun, 16 Nov 2014 23:11:19 -0500

> 1. Is the ABNF in terms of bytes or Unicode code points?

  I'd agree with the recommendation to use UTF-8.

> 4. Empty password.
> 
> An empty password is not secure, but a 1-char password isn’t appreciably
> better. What is the reason for saying “a password MUST NOT be zero bytes
> in length”? I would drop this requirement.

  RFC 2865 (RADIUS) contains prohibitions against zero-length secret
keys because I ran into them in practice.  Some equipment didn't allow
for the entry of a secret key.  I requested that such keys be forbidden
by the WG.

  1 byte passwords aren't much better than zero-length passwords.  But
zero-length passwords should be forbidden (IMHO).  Recommending a
minimum length is a SHOULD.

  Allowing zero-length passwords could be taken to mean that it is
permitted to *omit* the password entirely.  That should be forbidden in
no uncertain terms.

  Alan DeKok.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 19 Nov 2014 20:20:04 -0700

Hi James, thanks for the review. Comments inline.

On 11/16/14, 7:25 PM, Manger, James wrote:
> <password> seems that it might be in code points as it is one or more
> <freepoint>s, where a <freepoint> is a UTF-8 encoded Unicode code point.
 >
> But it mentions UTF-8 that would be unnecessary if it is in code points.
>
> Byte-based rules don’t seem to make much sense as UTF-8 requires bytes
> in a specific order.
>

We neglected to update password as we did username, which has:

       username   = userpart [1*(1*SP userpart)]
       userpart   = 1*(idbyte)
                    ;
                    ; an "idbyte" is a byte used to represent a
                    ; UTF-8 encoded Unicode code point that can be
                    ; contained in a string that conforms to the
                    ; PRECIS "IdentifierClass"
                    ;

The reason for this is similar to what we originally did in RFC 3920 for 
XMPP: we don't want to define length in terms of characters or code 
points because in the UTF-8 encoding some characters or code points 
might be encoded as more than one byte.

Thus I would argue that bytes or octets are the appropriate measure here 
(not characters or code points) and that the ABNF ought to be:

       password   = 1*(freebyte)
                    ;
                    ; a "freebyte" is a byte used to represent a
                    ; UTF-8 encoded Unicode code point that can be
                    ; contained in a string that conforms to the
                    ; PRECIS "FreefromClass"
                    ;

> The 2^nd term is an optional sequence of 1 or more things. Isn’t that
> the same as 0 or more things?
>

Works for me.

> These 2 rules are used, but not defined. Perhaps the only definition is
> the comment that follow their use? If so, could that be stated a bit
> more explicitly so readers don’t hunt through other precis docs and
> references looking for them.

I haven't figured out a way to define <freebyte> or <idbyte> in ABNF (it 
might be impossible because those rules include by reference everything 
in PRECIS).

> in length”? I would drop this requirement.

As Alan points out, this document does not provide any kind of security 
recommendation on password length or strength (which IMHO is out of 
scope here), but it does prohibit omitting the password entirely.

Peter

-- 
Peter Saint-Andre
https://andyet.com/