Subject: [NNTP] Spaces in usernames and passwords (was: authinfo-02 changes)

From: clive at demon.net (Clive D.W. Feather)
Date: Wed Sep 1 08:50:02 2004

Russ Allbery said:
> I'm happy to let servers do the work of supporting arbitrary whitespace in
> the AUTHINFO arguments if they really want to, but I don't want to require
> it.  In practice, it frequently won't work, and I don't expect people to
> put effort into their old AUTHINFO implementations to make it work.
> 
> I think Ken's ABNF is cleaner in that it lets one more easily talk about
> how some servers will parse the argument as words and some won't, and
> Clive's ABNF makes it look like all servers will parse the arguments as
> words, so it seems easier to get to both possible behaviors from Ken's
> approach than from Clive's.  But I do think we need to make it very clear
> that servers may parse the AUTHINFO arguments like any other NNTP command.
> 
> As for the parsing ambiguity, my inclination would be to resolve it in
> Ken's grammar by having USER or PASS be followed by one and only one
> whitespace character, with everything following that being part of the
> username or password if an implementation should care to parse it that
> way.

Okay, here's a proposal.

Change the last paragraph of 2.1.2 from:

    Note that usernames and passwords containing whitespace are
    allowed, but may not work correctly with servers which blindly
    split command arguments at whitespace.  A client may wish to scan
    the username and password for whitespace, and if detected, warn the
    user of the likelihood of problems.  The SASL PLAIN [PLAIN] mecha-
    nism is recommended as an alternative, as it is more robust with
    regard to character set.

to:

    Note that a server MAY, but is not required to, allow white space
    characters in usernames and passwords. A server implementation MAY
    blindly split command arguments at white space and therefore not
    preserve the exact sequence of white space characters in the username
    or password.  Therefore a client SHOULD scan the username and password
    for whitespace, and if detected, warn the user of the likelihood of
    problems.  The SASL PLAIN [PLAIN] mecha nism is recommended as an
    alternative as it does not suffer from these issues.

In 3.1, append "; see below" to the definitions of "username" and
"password". Then append to this section:

    Note: this grammar is ambiguous: if the first or last character of
    a "username" or "password" is a SP or TAB, this could instead be
    parsed as part of the WS preceding the item or the EOL following
    every command. Furthermore, these two items do not conform to the
    definition of "x-argument" in section 9.1 of [NNTP].

    The purpose of this ambiguity is to express the fact that a server
    implementation MAY either:
    - parse all commands as a sequence of words separated by white space,
      ignoring the exact form of that white space, before determining
      which command is being invoked; or
    - parse AUTHINFO USER and AUTHINFO PASS specially, which MAY involve
      giving significance to the exact form of white space within and at
      the start and end of the username or password.

    A server MAY also act as if the above definitions were replaced by:

        username = 1*P-CHAR
        password = 1*P-CHAR

    (which removes the ambiguity by forbidding white space characters
    in usernames and passwords).

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: rra at stanford.edu (Russ Allbery)
Date: Wed Sep 1 12:26:48 2004

> Okay, here's a proposal.

This proposal looks good to me.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: ken at oceana.com (Ken Murchison)
Date: Thu Sep 2 11:51:08 2004

> This proposal looks good to me.

I'm fine with this as well.  I'll also propose this as a possible 
simpler and less-wordy alternative:

username = 1*(user-pass-char)
password = 1*(user-pass-char)
user-pass-char = P-CHAR

Note: A server implementation MAY parse AUTHINFO USER and AUTHINFO PASS 
specially as to allow white space to be used within the username or 
password.  Such implementations typically treat everything between the 
first whitespace character following "USER"/"PASS" and EOL as the 
username/password.  In this case, "user-pass-char" is extended as such:

user-pass-char =/ SP / TAB

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: rra at stanford.edu (Russ Allbery)
Date: Thu Sep 2 12:05:56 2004

> user-pass-char =/ SP / TAB

This also works for me.  I think we still want the 2.1.2 change.

---

From: ken at oceana.com (Ken Murchison)
Date: Thu Sep 2 12:07:13 2004

> This also works for me.  I think we still want the 2.1.2 change.

Yes, those changes are already in the source.

---

From: chl at clerew.man.ac.uk (Charles Lindsey)
Date: Thu Sep 2 19:12:44 2004

>    in usernames and passwords).

If it MAY do that, then why not say it SHOULD/MUST do that, and the whole
problem goes away? Yes, that might conflict with normal SASL usage, but is
there particular merit in avoiding such conflict for this particular
protocol?

Possible answer is that it would upset people who have such a
username/password pair that they use with SASL for other protocols (SMTP
perhaps) and they want to use the same one. But if servers MAY restrict as
suggested, then such people have a problem anyway, and either have to
change their username/password or use some other server.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: rra at stanford.edu (Russ Allbery)
Date: Thu Sep 2 19:18:25 2004

Charles Lindsey <[email-masked]> writes:

> If it MAY do that, then why not say it SHOULD/MUST do that, and the
> whole problem goes away?

It's actually a commonly-requested feature.  The goal is primarily to
document existing practice, and existing practice is mixed.  Both
approaches have merits and neither is obviously better than the other,
plus this mechanism is going to be replaced by SASL PLAIN anyway
eventually.

> Yes, that might conflict with normal SASL usage,

It doesn't have anything whatsoever to do with SASL.  That's the reason
why we're not investing any effort in changing it.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Tue Sep 7 07:01:07 2004

> password = 1*(user-pass-char)

The parentheses aren't needed.

> username/password.

Not EOL, because that includes trailing white space. Say CRLF instead.

> In this case, "user-pass-char" is extended as such:
> 

Better, I think, is:

    Such implementations accept the additional syntax:

    (note that this makes the overall grammar ambiguous and also makes
    these commands incompatible with "x-command").

---

From: ken at oceana.com (Ken Murchison)
Date: Tue Sep 7 07:05:32 2004

> Not EOL, because that includes trailing white space. Say CRLF instead.

Right.  Good catch.

>     these commands incompatible with "x-command").

OK.  I'll push a -03 draft out today.