Subject: [precis] draft evaluation of RFC 5738 (IMAP I18N of the LOGIN command) and RFC 4314 (IMAP ACL)

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

This message evaluates the IMAP related uses of stringprep in accordance with the template established by the PRECIS WG:

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

These documents have 2 types of strings (usernames and passwords), so I included 2 separate templates.

1)

Specification:

   RFC 5738/RFC 4314

Brief Description:

   - "username" parameter to the IMAP LOGIN command, identifiers in IMAP ACL commands. Note that any valid username is also an IMAP ACL identifier, but IMAP ACL identifiers can include other things like name of group of users.

How It's Used:

   - Used for authentication (Usernames), or in IMAP Access Control Lists (Usernames or Group names)

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 IMAP access (login)
     - improperly grant privileges (e.g., access to a specific mailbox, ability to manage ACLs for a mailbox)

   False negatives:
     - an authorized user is denied IMAP access
     - unable to use granted privileges (e.g., access to a specific mailbox, ability to manage ACLs for a mailbox)

Normalization:

   NFKC (as per RFC 4013)

Mapping:

   (see Section 2 of RFC 4013 for the full list):
   non ASCII spaces are mapped to space

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 IMAP implementations are not required to use a specific format, an IMAP username 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 IMAP username should also be used for ManageSieve, POP3 and SMTP 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.
   - access control lists (e.g. in IMAP ACL extension), both when managing membership and listing membership of existing access control lists.
   - often show up as mailbox names (under Other Users IMAP namespace)

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. Non-ASCII IMAP usernames are currently prohibited by IMAP (RFC 3501). However they are allowed when used in IMAP ACL extension.

--------------------------------------------------------------
2)

Specification:

   RFC 5738

Brief Description:

   - "Password" parameter to the IMAP LOGIN command

How It's Used:

   - Used for authentication (Passwords)

Who Generates It:

   - Either generated by email system administrators using some tools/conventions, or specified by the human user.

User Input Methods:

   - Typed by user
   - 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 or backend databse) on registration of account

Comparison Method:

   "Type 1" (byte-for-byte)

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

Case Folding, Sensitivity, Preservation:

   - Most likely case sensitive.

Impact of Comparison:

   False positives:
     - an unauthorized user is allowed IMAP access (login)

   False negatives:
     - an authorized user is denied IMAP 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

Disallowed Characters:

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

String Classes:

   - Currently defined as "simple username" (see Section 2 of RFC 4013 for details on restrictions.), however this is likely to be a different class from usernames. Note that some implementations allow spaces in these.

Password in all email related protocols should be treated in the same way. Same passwords are frequently shared with web, IM, etc. applications.

Internal Structure:

   None

User Output:

   - text of email messages (e.g. in "you forgot your password" email messages)
   - web page / directory
   - side of the bus / in ads -- possible

Operations:

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

  - Frequently stored as is, or hashed.

Community Considerations:

   how much tolerance for change from existing stringprep approach?

Not sure. Non-ASCII IMAP passwords are currently prohibited by IMAP (RFC 3501), however 
they are likely to be in widespread use.

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

RFC 5738 (IMAP I18N):

>5.  UTF8=USER Capability
>
>   If the "UTF8=USER" capability is advertised, that indicates the
>   server accepts UTF-8 user names and passwords and applies SASLprep
>   [RFC4013] to both arguments of the LOGIN command.  The server MUST
>   reject UTF-8 that fails to comply with the formal syntax in RFC 3629
>   [RFC3629] or if it encounters Unicode characters listed in Section
>   2.3 of SASLprep RFC 4013 [RFC4013].
>

RFC 4314 (IMAP4 Access Control List (ACL) Extension):

>3.  Access control management commands and responses
>
>   Servers, when processing a command that has an identifier as a
>   parameter (i.e., any of SETACL, DELETEACL, and LISTRIGHTS commands),
>   SHOULD first prepare the received identifier using "SASLprep" profile
>   [SASLprep] of the "stringprep" algorithm [Stringprep].  If the
>   preparation of the identifier fails or results in an empty string,
>   the server MUST refuse to perform the command with a BAD response.
>   Note that Section 6 recommends additional identifier's verification
>   steps.
>
and in Section 6:

>   This document relies on [SASLprep] to describe steps required to
>   perform identifier canonicalization (preparation).  The preparation
>   algorithm in SASLprep was specifically designed such that its output
>   is canonical, and it is well-formed.  However, due to an anomaly
>   [PR29] in the specification of Unicode normalization, canonical
>   equivalence is not guaranteed for a select few character sequences.
>   Identifiers prepared with SASLprep can be stored and returned by an
>   ACL server.  The anomaly affects ACL manipulation and evaluation of
>   identifiers containing the selected character sequences.  These
>   sequences, however, do not appear in well-formed text.  In order to
>   address this problem, an ACL server MAY reject identifiers containing
>   sequences described in [PR29] by sending the tagged BAD response.
>   This is in addition to the requirement to reject identifiers that
>   fail SASLprep preparation as described in Section 3.
>