Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.txt

From: [email-masked]
Date: Wed, 13 Feb 2013 20:24:43 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF.

	Title           : Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords
	Author(s)       : Peter Saint-Andre
                          Alexey Melnikov
	Filename        : draft-ietf-precis-saslprepbis-00.txt
	Pages           : 12
	Date            : 2013-02-13

Abstract:
   This document describes how to handle Unicode strings representing
   simple user names and passwords, primarily for purposes of
   comparison.  This profile is intended to be used by Simple
   Authentication and Security Layer (SASL) mechanisms (such as PLAIN
   and SCRAM-SHA-1), as well as other protocols that exchange simple
   user names or passwords.  This document obsoletes RFC 4013.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Feb 2013 14:20:25 -0700

[ + [email-masked] ]

On 2/18/13 11:04 AM, Chris Newman wrote:
> --On February 14, 2013 14:24:17 -0700 Peter Saint-Andre 
> <[email-masked]> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 2/14/13 2:12 PM, Peter Saint-Andre wrote:
>>> Hi Chris, thank you for the review.
>>> 
>>> On 2/14/13 12:37 PM, Chris Newman wrote:
>>>> A common construction for user names on the Internet is the
>>>> form "[email-masked]", specifically, a subset of
>>>> email-address syntax with an embedded domain name is commonly
>>>> used for login identity strings (although theses login
>>>> identity strings may or may not be usable as actual email
>>>> addresses).
>>> 
>>>> As a result, the character class used for user names used
>>>> for authentication needs to be a superset of the character
>>>> class used for domain names. I was not able to tell from the 
>>>> specification if that was the case. If it isn't, I believe
>>>> that should be fixed.
>>> 
>>> It is the case, because all characters in the ASCII range are 
>>> grandfathered into the PRECIS NameClass. Thus some examples
>>> are definitely in order! We'll add those to the next version.
>> 
>> I propose adding the second paragraph shown below to the end of 
>> Section 2.1, which defines the handling of simple user names:
>> 
>> Note well that all code points and blocks not explicitly allowed
>> in the PRECIS NameClass are disallowed; this includes private
>> use characters, surrogate code points, and the other code points
>> and blocks defined as "Prohibited Output" in Section 2.3 of RFC
>> 4013.
>> 
>> However, all characters in the ASCII range are "grandfathered"
>> into the PRECIS NameClass.  As a result, common constructions
>> such as "[email-masked]" are allowed as simple user names when
>> using software that conforms to this specification, as they were
>> under [RFC4013].
> 
> I don't see this as a necessary addition. It was quite clear from
> the specifications that the ASCII range was grandfathered in
> NameClass. It appears I was unclear in stating my concern, let me
> try again to explain my concern.

Yes, I did misconstrue your question.

> My concern is that login identities should be able to contain a
> valid IDNA U-label. It is not clear to me if NameClass permits all
> valid U-labels. If it does not, then I believe using NameClass for
> login identities is a mistake. The [email-masked] form for login
> identities will continue to be useful as the infrastructure is
> expanded to allow UTF-8 characters in both the "user" part and the
> "example.com" part of that form. If we disallow valid U-labels in
> login identities then we break the multi-domain model for lots of
> software out there and will force that software to change its
> architecture when it adopts this technology or to choose not to
> adopt this technology. If valid IDNA U-labels are permitted in
> login identities then implementers can keep their current
> architecture and adopt saslprepbis.

Ah, I see. You raise a good question. The intent was that any code
point allowed in IDNs would be allowed in the PRECIS NameClass, but
looking closely at draft-ietf-precis-framework I realize that the
intent might not be reflected in the spec right now. I will
investigate further and post again when I have something definitive to
report.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Feb 2013 22:05:37 -0700

On 2/18/13 2:20 PM, Peter Saint-Andre wrote:
>>>>> A common construction for user names on the Internet is
>>>>> the form "[email-masked]", specifically, a subset of 
>>>>> email-address syntax with an embedded domain name is
>>>>> commonly used for login identity strings (although theses
>>>>> login identity strings may or may not be usable as actual
>>>>> email addresses).
>>>> 
>>>>> class used for domain names. I was not able to tell from
>>>>> the specification if that was the case. If it isn't, I
>>>>> believe that should be fixed.
>>>> 
>>> Note well that all code points and blocks not explicitly
>>> allowed in the PRECIS NameClass are disallowed; this includes
>>> private use characters, surrogate code points, and the other
>>> code points and blocks defined as "Prohibited Output" in
>>> Section 2.3 of RFC 4013.
>>> 
>>> such as "[email-masked]" are allowed as simple user names
>>> when using software that conforms to this specification, as
>>> they were under [RFC4013].
> 
>> I don't see this as a necessary addition. It was quite clear
>> from the specifications that the ASCII range was grandfathered
>> in NameClass. It appears I was unclear in stating my concern, let
>> me try again to explain my concern.
> 
>> valid IDNA U-label. It is not clear to me if NameClass permits
>> all valid U-labels. If it does not, then I believe using
>> NameClass for login identities is a mistake. The [email-masked]
>> form for login identities will continue to be useful as the
>> infrastructure is expanded to allow UTF-8 characters in both the
>> "user" part and the "example.com" part of that form. If we
>> disallow valid U-labels in login identities then we break the
>> multi-domain model for lots of software out there and will force
>> that software to change its architecture when it adopts this
>> technology or to choose not to adopt this technology. If valid
>> IDNA U-labels are permitted in login identities then implementers
>> can keep their current architecture and adopt saslprepbis.
> 
> point allowed in IDNs would be allowed in the PRECIS NameClass,
> but looking closely at draft-ietf-precis-framework I realize that
> the intent might not be reflected in the spec right now. I will 
> investigate further and post again when I have something definitive
> to report.

Hi Chris, I've been thinking about this further...

IMHO this is similar to the previous discussion about naming needing
to include space characters (after all, your name is "Chris Newman",
not "ChrisNewman"). After much discussion, participants in the PRECIS
WG concluded that it would be safer to disallow space characters in
the NameClass, and that application protocols would need to define
their constructs as a space-separated series of NameClass instances.
And in fact that's what we've done in draft-ietf-precis-saslprepbis:

   simpleusername = simplepart [1*(1*SP simplepart)]
   simplepart     = 1*(namepoint)
                    ;
                    ; a "namepoint" is a UTF-8 encoded
                    ; Unicode code point that conforms to
                    ; the "NameClass" string class defined
                    ; in draft-ietf-precis-framework
                    ;

Here I see something similar: in order to allow strings like
[email-masked], an application protocol would need to define its
constucts along these lines:

   userathost   = userpart '@' domainpart
   userpart   = 1*(namepoint)
                    ;
                    ; a "namepoint" is a UTF-8 encoded
                    ; Unicode code point that conforms to
                    ; the "NameClass" string class defined
                    ; in draft-ietf-precis-framework
                    ;
      domainpart    = IP-literal / IPv4address / ifqdn
      ifqdn         = 1*64(domainpoint)
                      ;
                      ; a "domainpoint" is a UTF-8 encoded
                      ; Unicode code point that conforms to
                      ; RFC 5890
                      ;

Or, naturally, we could allow both styles (and others).

That said, we might want to allow some characters into the NameClass
that are outside LetterDigits ("A") in RFC 5892. I'm thinking
especially of some of the code points in Exceptions ("F"). This sounds
like an appropriate topic for discussion in Orlando...

Peter

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Feb 2013 16:46:29 -0600

> And in fact that's what we've done in draft-ietf-precis-saslprepbis:

I think this is a mistake.  There are plenty of online games where
users are allowed to have fairly arbitrary names.  E.g., bzflag
(although in recent years I think additional restrictions have been
added on the registration side).  Online gaming is probably a desired
customer for SASL -- why not?

I think restrictions on user naming should be imposed primarily by the
registrar, not by the client or server software.  We might well advise
against allowing whitespace in usernames, and we might need to map
different whitespace codepoints to just one, and so on, but not
prohibit.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Feb 2013 19:30:51 -0700

On 2/19/13 3:46 PM, Nico Williams wrote:
>> IMHO this is similar to the previous discussion about naming 
>> needing to include space characters (after all, your name is 
>> "Chris Newman", not "ChrisNewman"). After much discussion, 
>> participants in the PRECIS WG concluded that it would be safer
>> to disallow space characters in the NameClass, and that
>> application protocols would need to define their constructs as a 
>> space-separated series of NameClass instances. And in fact
>> that's what we've done in draft-ietf-precis-saslprepbis:
> 
>  added on the registration side).  Online gaming is probably a
> desired customer for SASL -- why not?
> 
> I think restrictions on user naming should be imposed primarily by
>  the registrar, not by the client or server software.  We might
> well advise against allowing whitespace in usernames, and we might
> need to map different whitespace codepoints to just one, and so on,
> but not prohibit.

Hi Nico, please (re-)read Section 4.3 of draft-ietf-precis-framework
before concluding that the participants in the PRECIS WG are utterly
misguided on the issue of whitespace. :-)

Peter

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Feb 2013 21:16:35 -0600

> misguided on the issue of whitespace. :-)

I said what now?  :)

But OK, I read that, and I remain unconvinced.  What am I missing?  If
they did have a clue then they didn't write text that I find
convincing.  Who cares if some devices produce whitespace other than
ASCII space?  That's what mappings are for.  Or maybe I'm missing
something.  Assume I'm partly ignorant here.  What am I missing?

Nico
--

---

From: Chris Newman <[email-masked]>
Date: Tue, 19 Feb 2013 21:47:33 -0800

> constucts along these lines:

Historically, Internet login identities have been freeform ASCII or UTF-8 
strings. Widely deployed implementations have sometimes used other charsets 
such as ISO-8859-1 even when it violates the standards. This shows need for 
both UTF-8 support and validity enforcement in login identities.

Identity systems can impose additional structure as needed. A site's 
identity system works best if it can span multiple protocols (e.g., IMAP, 
POP, SMTP, XMPP, web form logins, etc). Architecturally, I think identity 
systems are best viewed as independent of the consuming protocols even if a 
lot of software is not implemented that way today. So I'd prefer to avoid 
having application protocols imposing unnecessary constraints on identity 
systems.

So we're balancing a need for validity enforcement for interoperability 
(which is the intent behind NameClass) with a need for application 
protocols to avoid breaking existing identity system models so it is 
possible for this standard to deploy. This looks like a good engineering 
problem to me. :-)

> like an appropriate topic for discussion in Orlando...

Yes, I think that would be a good discussion to have. I would propose that 
all the PVALID and CONTEXT characters from Exceptions (F) be added to 
NameClass and state that implementations MAY enforce the CONTEXT 
restrictions from RFC 5892.

		- Chris