Re: [precis] [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt

[Peter Saint-Andre <[e-mail]>]

On 10/4/13 6:46 AM, Alexey Melnikov wrote:
> On 24/09/2013 22:17, Simon Josefsson wrote:
>> You wrote:
>>>>>>>> "Simon" == Simon Josefsson <[e-mail]> writes:
>>>      Simon> like HTTP, FTP, SMTP, SSH, etc could be revised.  I don't
>>>      Simon> believe any of that will happen, so we'll have to live with
>>>      Simon> case sensitive usernames, and my take is that I18N
>>>      Simon> documents should permit that.
>>>
>>> I'm not sure any of the above hase case sensitive usernames.
>>> They permit usernames to be case sensitive.
>>> However a lot of implementations treat the username as case
>>> insensitive.
>>>
>>> I do think this is an appropriate issue for an IETF an document, but I
>>> do think considering the impact on legacy systems is important.
>>> I don't think we need to require there be no impact, simply understand
>>> an accept it.
>> Agreed, but the devil is in the detail.  For example, I would say that
>> any I18N effort that changes how ASCII usernames ([A-Za-z0-9...])
>> behave have gone too far down the road that causes damage to legacy
>> systems.
> Case folding for usernames in draft-ietf-precis-saslprepbis-04.txt is a
> SHOULD, so I think you are Ok. I.e. compatibility with a legacy system
> is a good enough reason to violate the SHOULD.

Correct.

Here is proposed text for Section 4 on usernames. I've provided proposed
text for the entire section so that folks on both the PRECIS and KITTEN
lists have the complete context.

Please review this proposed text and provide comments.

###

4.  Usernames

4.1.  Definition

   This document specifies that a username is a string of Unicode code
   points [UNICODE], encoded using UTF-8 [RFC3629], and structured
   either as an ordered sequence of "userparts" (where the complete
   username can consist of a single userpart or a space-separated
   sequence of userparts) or as a userpart@domainpart (where the
   domainpart is an IP literal, an IPv4 address, or a fully-qualified
   domain name).

   The syntax for a username is defined as follows using the Augmented
   Backus-Naur Form (ABNF) [RFC5234].

      username   = userpart [1*(1*SP userpart)]
                   / userpart '@' domainpart
      userpart   = 1*(idpoint)
                   ;
                   ; an "idpoint" is a UTF-8 encoded Unicode code point
                   ; that conforms to the PRECIS "IdentifierClass"
                   ;
      domainpart = IP-literal / IPv4address / ifqdn
                   ;
                   ; the "IPv4address" and "IP-literal" rules are
                   ; defined in RFC 3986, and the first-match-wins
                   ; (a.k.a. "greedy") algorithm described in RFC 3986
                   ; applies
                   ;
                   ; reuse of the IP-literal rule from RFC 3986 implies
                   ; that IPv6 addresses are enclosed in square brackets
                   ; (i.e., beginning with '[' and ending with ']')
                   ;
      ifqdn      = 1*1023(domainpoint)
                   ;
                   ; a "domainpoint" is a UTF-8 encoded Unicode code
                   ; point that conforms to RFC 5890
                   ;

   All code points and blocks not explicitly allowed in the PRECIS
   IdentifierClass are disallowed; this includes private use characters,
   surrogate code points, and the other code points and blocks that were
   defined as "Prohibited Output" in [RFC4013].  In addition, common
   constructions such as "[e-mail]" are allowed as usernames
   under this specification, as they were under [RFC4013].

4.2.  Preparation

   Each userpart of a username MUST conform to the
   "UsernameIdentifierClass" profile of the PRECIS IdentifierClass,
   which is defined as follows:

   1.  The base string class is the "IdentifierClass" specified in
       [I-D.ietf-precis-framework].
   2.  Fullwidth and halfwidth characters MUST be mapped to their
       decomposition equivalents.
   3.  So-called additional mappings MAY be applied, such as those
       defined in [I-D.ietf-precis-mappings].
   4.  Uppercase and titlecase characters might be mapped to their
       lowercase equivalents (see Section 4.2.1 below).
   5.  Unicode Normalization Form C (NFC) MUST be applied to all
       characters.

   With regard to directionality, the "Bidi Rule" provided in [RFC5893]
   applies.

   A username MUST NOT be zero bytes in length.  This rule is to be
   enforced after any normalization and mapping of code points.

   In protocols that provide usernames as input to a cryptographic
   algorithm such as a hash function, the client will need to perform
   proper preparation of the username before applying the algorithm.

4.2.1.  Case Mapping

   Case mapping is a matter for the application protocol, protocol
   implementation, or end deployment.  In general, this document
   suggests that it is preferable to perform case mapping, since not
   doing so can lead to false positives during authentication and
   authorization (as described in [RFC6943]) and can result in confusion
   among end users given the prevalence of case mapping in many existing
   protocols and applications.  However, there can be good reasons to
   not perform case mapping, such as backward compatibility with
   deployed infrastructure.

   In particular:

   o  SASL mechanisms that directly re-use this profile MUST specify
      whether and when case mapping is to be applied to authentication
      identifiers.  SASL mechanisms SHOULD delay any case mapping to the
      last possible moment, such as when doing a lookup by username,
      username comparisons, or generating a cryptographic salt from a
      username.  In keeping with RFC4422, SASL mechanisms are not to
      apply this or any other profile to authorization identifiers.
   o  Application protocols that use SASL (such as IMAP [RFC3501] and
      XMPP [RFC6120]) and that directly re-use this profile MUST specify
      whether case mapping is to be applied to authorization
      identifiers.  Such "SASL application protocols" SHOULD delay any
      case mapping of authorization identifiers to the last possible
      moment, which happens to necessarily be on the server side.  In
      keeping with RFC4422, SASL application protocols are not to apply
      this or any other profile to authentication identifiers.
   o  Application protocols that do not use SASL (such as HTTP
      authentication with the Basic and Digest schemes [RFC2617]) MUST
      specify whether and when case mapping is to be applied to
      authentication identifiers and authorization identifiers.  Such
      "non-SASL application protocols" SHOULD delay any case mapping to
      the last possible moment, such as when doing a lookup by username,
      username comparisons, or generating a cryptographic salt from a
      username.

   If the specification for a SASL mechanism, SASL application protocol,
   or non-SASL application protocol specifies the handling of case
   mapping for strings that conform to the UsernameIdentifierClass, it
   MUST clearly describe whether case mapping is required, recommended,
   or optional at the level of the protocol itself, implementations
   thereof, or service deployments.

###

Peter

-- 
Peter Saint-Andre
https://stpeter.im/