Subject: [precis] Draft evaluation of how RFC 4505 (Anonymous SASL Mechanism) uses StringPrep

From: Alexey Melnikov <[email-masked]>
Date: Sat, 20 Nov 2010 09:06:01 +0000

RFC 4505 defines a "trace" field:

> 1) Boxes
> 3 types of identifiers used by precis customers:
>  a) compare byte-by-byte
>  b) compare by a common algorithm that everyone agrees on

I don't think this field is intended for comparison (only used for logging).

But maybe a) is appropriate if somebody wants to find it.

>  c) No single common comparison algorithm for everyone (Specifically, 
> everyone might want the comparison to be tailored for their locale, 
> for some definition of locale)
>   c1) No single common comparison algorithm for everyone, but within 
> one or more constrained subsets of users/uses there may be an agreed 
> on comparison algorithm. E.g., US-ASCII users might agree on a 
> comparison algorithm but US-ASCII vs Turkish users may not, for a 
> given type of identifier.
>
> 2) Case folding; case sensitivity, preserve case

No case folding/case sensitive.

> 3) User input
>
> a. Do users input the strings directly?

Yes. Possibly entered in configuration UIs, or on a command line. Can
also be stored in configuration files.
The value can also be automatically generated by clients (e.g. a fixed 
string is used, or a user's email address).

> b. If so, how? (keyboard, stylus, voice, copy-paste, etc.)

Keyboard/voice, stylus (pick from a list). Copy-paste - possibly.

> c. Where do we place the dividing line between user interface and 
> protocol? (see RFC 5895)
>
> 4) Normalization

None.

Control characters are disallowed. (See Section 3 of RFC 4505)

> 5) Classes
> a. Which other strings or identifiers are these most similar to?

RFC 4505 says that the trace "should take one of two forms: an Internet
email address, or an opaque string that does not contain the '@'
U+0040) character and that can be interpreted by the system
administrator of the client's domain."

In practice I think this is a freeform text, so it belongs to a 
different class from "email address" or "username".

> b. Are these strings or identifiers sometimes the same as strings or 
> identifiers from other protocols (e.g., does an IM system sometimes 
> use the same credentials database for authentication as an email system)?

Yes: see 5a) above. However there is no strong need to keep them 
consistent in the future.

> 6) User exposed to; published/seen
>
> How are users exposed to these strings, how are they published? (vCard,

No (unless email address format is used)

> web directory,

No.

> business card,

No.

> side of the bus,

No.

The value can be seen in server logs.

> etc.)
>
> 7) Impacts of false positives and false negatives
> e.g. security/authentication decisions

False positive: a user can be confused with another user
False negative: two distinct users are treated as the same user

But note that the trace field is not authenticated, so it can be easily 
falsified.

> 8) Tolerance of changes in the community
> And also perhaps "desire for something better / more sustainable / 
> more agilew.r.t. Unicode versions".

I think in this case the community would be flexible.

> 9). Delimiters such as "." (is there any internal structure?)

No internal structure, but see comments above about frequent use of
email addresses.

--------------------------------------------------------------
Background information:

> 2.  The Anonymous Mechanism
> 
>    The mechanism consists of a single message from the client to the
>    server.  The client may include in this message trace information in
>    the form of a string of [UTF-8]-encoded [Unicode] characters prepared
>    in accordance with [StringPrep] and the "trace" stringprep profile
>    defined in Section 3 of this document.  The trace information, which
>    has no semantical value, should take one of two forms: an Internet
>    email address, or an opaque string that does not contain the '@'
>    (U+0040) character and that can be interpreted by the system
>    administrator of the client's domain.  For privacy reasons, an
>    Internet email address or other information identifying the user
>    should only be used with permission from the user. 
> 
> 3.  The "trace" Profile of "Stringprep"
> 
>    This section defines the "trace" profile of [StringPrep].  This
>    profile is designed for use with the SASL ANONYMOUS Mechanism.
>    Specifically, the client is to prepare the <message> production in
>    accordance with this profile.
> 
>    The character repertoire of this profile is Unicode 3.2 [Unicode].
> 
>    No mapping is required by this profile.
> 
>    No Unicode normalization is required by this profile.
> 
>    The list of unassigned code points for this profile is that provided
>    in Appendix A of [StringPrep].  Unassigned code points are not
>    prohibited.
> 
>    Characters from the following tables of [StringPrep] are prohibited:
> 
>       - C.2.1 (ASCII control characters)
>       - C.2.2 (Non-ASCII control characters)
>       - C.3 (Private use characters)
>       - C.4 (Non-character code points)
>       - C.5 (Surrogate codes)
>       - C.6 (Inappropriate for plain text)
>       - C.8 (Change display properties are deprecated)
>       - C.9 (Tagging characters)
> 
>    No additional characters are prohibited.
> 
>    This profile requires bidirectional character checking per Section 6
>    of [StringPrep].