Subject: [precis] draft evaluation of RFC 5034 (POP3 Authentication), RFC 4954 (SMTP Authentication) and RFC 5804 (ManageSieve Authentication)

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Dec 2010 13:25:41 +0000

This message evaluates the SMTP/POP3/ManageSieve related uses of stringprep in
accordance with the template established by the PRECIS WG:

http://trac.tools.ietf.org/wg/precis/trac/wiki/StringprepReviewTemplate

1)

Specification:

   RFC 4954/RFC 5034/RFC 5804

Brief Description:

   - Authorization identity (user identifier) exchanged during SASL authentication: AUTH (SMTP/POP3) or AUTHENTICATE (ManageSieve) command.

How It's Used:

   - Used for proxy authorization, e.g. to [lawfully] impersonate a particular user after a privileged authentication

Who Generates It:

   - Typically generated by email system administrators using some tools/conventions, sometimes from some backend database
   - In some setups human users can register own usernames (e.g. webmail self registration)

User Input Methods:

   - Typed by user / selected from a list
   - Copy-and-paste
   - Perhaps voice input
   - Can also be specified in configuration files or on a command line

Enforcement:

   - Rules enforced by server / add-on service (e.g., gateway
     service) on registration of account

Comparison Method:

   "Type 1" (byte-for-byte) or "type 2" (compare by a common algorithm that everyone agrees on (e.g., normalize and then compare the result byte-by-byte))

   (see http://tools.ietf.org/html/draft-ietf-precis-problem-statement )

Case Folding, Sensitivity, Preservation:

   - Most likely case sensitive. Exact requirements on case-sensitivity/case-preservation depend on a specific implementation, e.g. an implementation might treat all user identifiers as case insensitive (or case insensitive for US-ASCII subset only).

Impact of Comparison:

   False positives:
     - an unauthorized user is allowed email service access (login)
   False negatives:
     - an authorized user is denied email service access

Normalization:

   NFKC (as per RFC 4013)

Mapping:

   (see Section 2 of RFC 4013 for the full list):
   Non ASCII spaces are mapped to space, etc.

Disallowed Characters:

   (see Section 2 of RFC 4013 for the full list):
   Unicode Control characters, etc.

String Classes:

   - simple username. See Section 2 of RFC 4013 for details on restrictions. Note that some implementations allow spaces in these.

While implementations are not required to use a specific format, an authorization identity frequently has the same format as an email address (and EAI email address in the future), or as a left hand side of an email address.

Note: whatever is recommended for SMTP/POP/ManageSieve authorization identity should also be used for IMAP authorization identities, as IMAP/POP3/SMTP/ManageSieve are frequently implemented together.

Internal Structure:

   None

User Output:

   - text of email messages
   - web page / directory
   - business card / side of the bus -- Unlikely, but possible. For example, if it is the same as an email address.

Operations:

  - Sometimes concatenated with other data and then
    used as input to a cryptographic hash function

Community Considerations:

   how much tolerance for change from existing stringprep approach?

Not sure.

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

In RFC 5034, when describing the POP3 AUTH command:

>The authorization identity generated by the SASL exchange is a
>         simple username, and SHOULD use the SASLprep profile (see
>         [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to
>         prepare these names for matching.  If preparation of the
>         authorization identity fails or results in an empty string
>         (unless it was transmitted as the empty string), the server
>         MUST fail the authentication.
>
In RFC 4954, when describing the SMTP AUTH command:

>         The authorization identity generated by this [SASL] exchange
>          is a "simple username" (in the sense defined in [SASLprep]),
>          and both client and server SHOULD (*) use the [SASLprep]
>          profile of the [StringPrep] algorithm to prepare these names
>          for transmission or comparison.  If preparation of the
>          authorization identity fails or results in an empty string
>          (unless it was transmitted as the empty string), the server
>          MUST fail the authentication.
>
>      (*) Note: Future revision of this specification may change this
>      requirement to MUST.  Currently, the SHOULD is used in order to
>      avoid breaking the majority of existing implementations.
>
In RFC 5804, when describing the ManageSieve AUTHENTICATE command:

>   The authorization identity generated by this [SASL] exchange is a
>   "simple username" (in the sense defined in [SASLprep]), and both
>   client and server MUST use the [SASLprep] profile of the [StringPrep]
>   algorithm to prepare these names for transmission or comparison.  If
>   preparation of the authorization identity fails or results in an
>   empty string (unless it was transmitted as the empty string), the
>   server MUST fail the authentication.
>