Username Interoperability
draft-saintandre-username-interop-00

Abstract

Various Internet protocols have defined constructs for usernames. This document describes a subset of characters to allow in usernames for maximal interoperability across Internet protocols. The subset might prove useful in cases where a provider offers multiple services using the same underlying identifier.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 10, 2013.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Subset
• 3. Security Considerations
• 4. IANA Considerations
• 5. Informative References
• Appendix A. Analysis
• Appendix B. Acknowledgements
• Author's Address

1. Introduction

Various Internet protocols have defined constructs for usernames. This document describes a subset of characters to allow in usernames for maximal interoperability across Internet protocols. The subset might prove useful in cases where a provider offers multiple services using the same underlying identifier.

2. Subset

The following definition, in Augmented Backus-Naur Form (ABNF) [RFC5234], describes an interoperable subset of characters for localparts / usernames:

   localpart    =  1*(interopchar)
   interopchar  =  ALPHA / DIGIT / "!" / "$" / "*" / "+" 
                   / "-" / "=" / "_" / "`" / "|" / "~"
        

The reasoning behind this subset is provided in Appendix A.

An internationalized version would add the 'ucschar' rule from [RFC3987]. However, note that allowing characters outside the ASCII range [RFC20] can introduce numerous complexities; such issues are discussed in [I-D.ietf-precis-framework] among other specifications.

3. Security Considerations

Deploying usernames that are interoperable across multiple protocols could potentially give malicious entities multiple ways to attack an account or user.

4. IANA Considerations

This document has no actions for the IANA.

5. Informative References

Appendix A. Analysis

This document takes the following username constructs into consideration:

• Email addresses [RFC5322]
• Kerberos Principal Names [RFC4120]
• Network Address Identifiers [RFC4282]
• SIP URIs [RFC3261]
• Instant messaging URIs [RFC3860] and presence URIs [RFC3856]
• XMPP addresses (a.k.a. Jabber Identifiers) [RFC6120]
• Account URIs [I-D.ietf-appsawg-acct-uri]

Each of those address formats defines something that can be used as the "local part" of an address.

The local part of an email address uses either the "local-part" or the "dot-atom-text" rule in [RFC5322]. Here we make the simplifying assumption that the "dot-atom-text" rule applies:

   dot-atom-text =  1*atext *("." 1*atext)
   atext         =  ALPHA / DIGIT /    ; Any character except 
                    "!" / "#" / "$" /  ; controls, SP, and 
                    "%" / "&" / "'" /  ; specials. Used for 
                    "*" / "+" / "-" /  ; atoms.
                    "/" / "=" / "?" /
                    "^" / "_" / "`" / 
                    "{" / "|" / "}" /
                    "~"
        

We make the same simplifying assumption for im: and pres: URIs (although their specifications reference [RFC2822]).

A Kerberos Principal Name is a sequence of strings of type KerberosString, where each KerberosString is a GeneralString that is constrained to contain only characters in IA5String.

   PrincipalName   ::= SEQUENCE {
           name-type       [0] Int32,
           name-string     [1] SEQUENCE OF KerberosString
   }
   KerberosString  ::= GeneralString (IA5String)
        

A Network Address Identifier inherits from [RFC821]. Here we care only about the "username" rule:

   username    =  dot-string
   dot-string  =  string
   dot-string  =/ dot-string "." string
   string      =  char
   string      =/ string char
   char        =  c
   char        =/ "\" x
   c           =  %x21    ; '!'              allowed
                          ; '"'              not allowed
   c           =/ %x23    ; '#'              allowed
   c           =/ %x24    ; '$'              allowed
   c           =/ %x25    ; '%'              allowed
   c           =/ %x26    ; '&'              allowed
   c           =/ %x27    ; '''              allowed
                          ; '(', ')'         not allowed
   c           =/ %x2A    ; '*'              allowed
   c           =/ %x2B    ; '+'              allowed
                          ; ','              not allowed
   c           =/ %x2D    ; '-'              allowed
                          ; '.'              not allowed
   c           =/ %x2F    ; '/'              allowed
   c           =/ %x30-39 ; '0'-'9'          allowed
                          ; ';', ':', '<'    not allowed
   c           =/ %x3D    ; '='              allowed
                          ; '>'              not allowed
   c           =/ %x3F    ; '?'              allowed
                          ; '@'              not allowed
   c           =/ %x41-5a ; 'A'-'Z'          allowed
                          ; '[', '\', ']'    not allowed
   c           =/ %x5E    ; '^'              allowed
   c           =/ %x5F    ; '_'              allowed
   c           =/ %x60    ; '`'              allowed
   c           =/ %x61-7A ; 'a'-'z'          allowed
   c           =/ %x7B    ; '{'              allowed
   c           =/ %x7C    ; '|'              allowed
   c           =/ %x7D    ; '}'              allowed
   c           =/ %x7E    ; '~'              allowed
                          ; DEL              not allowed
   c           =/ %x80-FF ; UTF-8-Octet      allowed
   x           =  %x00-FF ; all 128 ASCII characters
        

The local part of a sip:/sips: URI inherits from the "userinfo" rule in [RFC3986] with several changes; here we discuss the SIP "user" rule only:

   user             =  1*( unreserved / escaped / user-unreserved )
   user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
   unreserved       =  alphanum / mark
   mark             =  "-" / "_" / "." / "!" / "~" / "*" / "'"
                       / "(" / ")"
        

The local part of an XMPP address allows any ASCII character except space, controls, and the " & ' / : < > @ characters.

The 'acct' URI syntax borrows the 'host', 'pct-encoded', 'sub-delims', 'unreserved' rules from [RFC3986]:

acctURI      =  "acct" ":" userpart "@" host
userpart     =  unreserved / sub-delims
                0*( unreserved / pct-encoded / sub-delims )
          

To summarize the foregoing information, the following table lists the allowed and disallowed characters in the local part of identifiers for each protocol (aside from the alphanumeric, space, and control characters), in order by hexadecimal character number (where each "A" row shows the allowed characters and each "D" row shows the disallowed characters).

Table 1: Allowed and Disallowed Characters (Non-Alphanumeric)

+---+----------------------------------+
| EMAIL ADDRESSES, IM/PRES URIs        |
+---+----------------------------------+
| A | ! #$%&'  *+ - /   = ?    ^_`{|}~ |
| D |  "     ()  , . :;< > @[\]        |
+---+----------------------------------+
| KERBEROS PRINCIPAL NAMES             |
+---+----------------------------------+
| A | !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ |
| D |                                  |
+---+----------------------------------+
| NETWORK ADDRESS IDENTIFIERS          |
+---+----------------------------------+
| A | ! #$%&'  *+ - /   = ?    ^_`{|}~ |
| D |  "     ()  , . :;< > @[\]        |
+---+----------------------------------+
| SIP/SIPS URIs                        |
+---+----------------------------------+
| A | !  $ &'()*+,-./ ; = ?     _    ~ |
| D |  "# %          : < > @[\]^ `{|}  |
+---+----------------------------------+
| XMPP ADDRESSES                       |
+---+----------------------------------+
| A | ! #$%  ()*+,-.  ; = ? [\]^_`{|}~ |
| D |  "   &'       /: < > @           |
+---+----------------------------------+
| ACCT URIs                            |
+---+----------------------------------+
| A | !  $%&'()*+,-.  ; =    \ ^_`{|}~ |
| D |  "#           /: < >?@[ ]        |
+---+----------------------------------+
       

The interoperable subset allows only characters that are allows in all of the foregoing formats, as shown in the following table.

Table 2: Subset Characters (Non-Alphanumeric)

+---+----------------------------------+
| INTEROPERABLE SUBSET                 |
+---+----------------------------------+
| A | !  $     *+ -     =       _` | ~ |
| D |  "# %&'()  , ./:;< >?@[\]^  { }  |
+---+----------------------------------+
       

Appendix B. Acknowledgements

Thanks to Sean Turner for inspiring the work on this document.

Author's Address