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

Clive D.W. Feather clive at demon.net
Wed Sep 1 08:49:55 PDT 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:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |



More information about the ietf-nntp mailing list