Re: Textual/non-textual passwords and SASLprep

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:09 PM 11/9/2003, Hallvard B Furuseth wrote:
>> For this reason, I revise my suggestion:
>>         The simple form of an AuthenticationChoice specifies a
>>         simple password to be used for authentication.  Passwords
>>         consisting of character data (text passwords) SHALL be
>>        transferred as [UTF-8] encoded [Unicode].  Prior to transfer,
>>        clients SHOULD prepare text passwords by applying the
>>        [SASLprep] profile of the [Stringprep] algorithm.  Passwords
>>         consisting of other data (such as random octets) MUST NOT
>>         be altered.
>>
>> (...)
>
>This text now appears in [Protocol] version 18.
>
>However, RFC 2277 also says:
>
>   Where protocol elements look like text tokens, such as in many IETF
>   application layer protocols, protocols MUST specify which parts are
>   protocol and which are text. [WR 2.2.1.1]
>
>yet the above text means that whether a password is text or not is
>decided outside the protocol, which seems just as much in violation of
>RFC 2277 as textual passwords without a specified charset.

The password element of the protocol is an octet string which
may, at times, contain character data.  The protocol relies on
the client implementation to distinguish when the data is text
or non-text.  When text, the client is to "prepare" the text for
transfer as specified.  When non-text, the client is to transfer
the data "as is".   This, IMO, addresses the Internationalization
requirements placed upon password element by BCP 18 (RFC 2277).

>For that matter, RFC 2277 goes on to say:
>
>   Protocols that transfer text MUST provide for carrying information
>   about the language of that text.
>
>which LDAP doesn't do for passwords, and probably doesn't fit anyone's
>idea of what one does with passwords in any case.
>So if we go by RFC 2277, we must either specify that passwords are UTF-8
>text, and probably also modify the userPassword syntax to only accept
>UTF-8, or that passwords are not text, but MAY be translated to UTF-8
>and prepared by [SASLprep] in some cases anyway.  Or we could ignore
>rfc2277 for this issue (or maybe that means to ask for an exception to
>be made), like at least the IRC protocol has done for backwards
>compatibility.

To the wire and the server, whether the password element is text or
not and, if so, what language that text is in is irrelevant to the
wire and server.  The server is obligated to treat the password as
an octet string.  Hence, the quoted requirement doesn't apply.

In reading the remainder of your comments, I find no new arguments.
To avoid repeating prior discussions, I'll won't respond to them.

Kurt