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

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Sep 2013 17:42:21 -0600

FYI, I finally remembered to ping the KITTEN WG about an issue that
was raised in Berlin...

Peter

- -------- Original Message --------
Subject: Re: [kitten] Fwd: Re: [precis] I-D Action:
draft-ietf-precis-saslprepbis-04.txt
Date: Mon, 09 Sep 2013 17:41:30 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked] <[email-masked]>

Dear KITTEN WG,

Your feedback would be appreciated on this I-D. This version
incorporates the input that Alexey and I received from folks here, as
well as discussion at the PRECIS WG session in Berlin:

http://www.ietf.org/proceedings/87/minutes/minutes-87-precis

One question in particular regarding preparation of usernames,
especially for Nico since he suggested the original text...

Version -03 said:

   3.  Uppercase and titlecase characters MAY be mapped to their
       lowercase equivalents.

In version -04, based on PRECIS WG discussion, we changed that to:

   3.  Uppercase and titlecase characters SHOULD be mapped to their
       lowercase equivalents (not doing so can lead to false positives
       during authentication and authorization, as described in
       [RFC6943]).

The rationale was that we really don't want to give people a gun to
shoot themselves with. Some folks in the PRECIS WG session leaned even
to "MUST" here, but SHOULD with an explanation of the consequences was
a compromise position. In any case, the original MAY seemed way too
weak to folks in the PRECIS WG. Please let us know if you have grave
concerns about the text in -04.

Thanks!

Peter

On 8/12/13 10:38 AM, Peter Saint-Andre wrote:
> FYI.
> 
> 
> -------- Original Message -------- Subject: Re: [precis] I-D 
> Action: draft-ietf-precis-saslprepbis-04.txt Date: Sun, 04 Aug
> 2013 18:06:49 -0600 From: Peter Saint-Andre <[email-masked]>
> To: [email-masked]
> 
> Changes to address discussion in the WG session on Friday. I did 
> this work in airports and on planes today, so I would not be 
> surprised if the text isn't perfect...
> 
> On 8/4/13 6:04 PM, [email-masked] wrote:
>> 
>> 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 Usernames and Passwords
>> Author(s)       : Peter Saint-Andre Alexey Melnikov Filename
>> : draft-ietf-precis-saslprepbis-04.txt Pages           : 14 Date 
>> : 2013-08-04
>> 
>> Abstract: This document describes how to handle Unicode strings 
>> representing usernames and passwords.  This profile is intended 
>> to be used by protocols that exchange or otherwise make use of 
>> usernames and 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-04
>> 
>> A diff from the previous version is available at: 
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-04
>>
>>
>>
>>
Please
note that it may take a couple of minutes from the time of
submission
>> until the htmlized version and diff are available at 
>> tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at: 
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________ precis mailing 
>> list [email-masked] 
>> https://www.ietf.org/mailman/listinfo/precis
>>

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Sep 2013 09:06:20 -0500

On Monday, September 9, 2013, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear KITTEN WG,
>

This is the third time, I think, that I've had to voice my vehement
objections to this.  I thought we were done the second time.  I believe
SASL applications and mechanisms MUST NOT do the above, not on the client
side, and that the server should be allowed to do what it wishes.  The only
exception is for password (and salt) processing in DIGEST/SCRAM-like
mechanisms where keys are derived from passwords on the client- (and
server-) sides, therefore canonical password representations are desirable,
and even then, case folding would be nothing short of -- and I must be
utterly frank here-- stupid, as it means dropping entropy needlessly.

The argument I made before was that we need to distinguish between query,
display, and storage strings.  If a username must be canonicalized then
this should be done where it must be used as a databased/directory lookup
key or as a cryptographic salt (where roughly the same considerations as
for passwords used to derive keys apply).  We should delay canonicalization
as much as possible so as to support the server operator's choice of
canonicalization.  I've mentioned before that many online games allow all
sorts of username forms that we'd consider silly in an enterprise
environment, but in online gaming they are quite desirable as a form of
styling.  Let's not put a straightjacket on users of this string
preparation -- let each operator pick their poison as much as possible.

The RFC6943 reference should be more specific.  What specific confusion
cases are we worried about?

Please have this argument on the KITTEN WG list.  I'm cc'ing
[email-masked] this once, and I will not subscribe to it.  We've
had at least two
debates on SASLprep-bis at KITTEN.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Sep 2013 10:38:48 -0700

Nico Williams <[email-masked]> writes:

> side, and that the server should be allowed to do what it wishes.

If the text above would have any bearing on SASL implementations (which
isn't clear to me), I would strongly agree with you that the text above
is a Bad Idea.

Generally, I believe the use-case of I18N of username & password have
special requirements that have been ignored by the PRECIS WG because the
username/password requirements are sometimes conflicting with other
goals of PRECIS and there doesn't seem to be enough interest to cater to
both communities at the same time.  Perhaps that is fine (I understand
PRECIS wants to publish), but then it should be made clear that PRECIS
will have no immediate bearing on SASLprepNG.

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Sep 2013 12:04:06 -0600

On 9/10/13 8:06 AM, Nico Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> 
> Dear KITTEN WG,
> 
> incorporates the input that Alexey and I received from folks here,
> as well as discussion at the PRECIS WG session in Berlin:
> 
> The rationale was that we really don't want to give people a gun
> to shoot themselves with. Some folks in the PRECIS WG session
> leaned even to "MUST" here, but SHOULD with an explanation of the
> consequences was a compromise position. In any case, the original
> MAY seemed way too weak to folks in the PRECIS WG. Please let us
> know if you have grave concerns about the text in -04.
> 
> 
> This is the third time, I think, that I've had to voice my
> vehement objections to this.  I thought we were done the second
> time.

Hi Nico, I don't think vehemence is needed. We have some different
perspectives, and we're trying to find common ground.

Would you perhaps have time to listen to the recording of the PRECIS
WG session in Berlin?

Also, would you be available for a phone conference on this topic so
that we can work through it in closer to real time? Or might you be
coming to the IETF meeting in Vancouver?

I'm out of time for the moment but I will reply at greater length soon.

(I include the rest of your message below because I have not yet seen
it arrive on the PRECIS list....)

> I believe SASL applications and mechanisms MUST NOT do the above,
> not on the client side, and that the server should be allowed to do
> what it wishes. The only exception is for password (and salt)
> processing in DIGEST/SCRAM-like mechanisms where keys are derived
> from passwords on the client- (and server-) sides, therefore
> canonical password representations are desirable, and even then,
> case folding would be nothing short of -- and I must be utterly
> frank here-- stupid, as it means dropping entropy needlessly.
> 
> The argument I made before was that we need to distinguish between 
> query, display, and storage strings.  If a username must be 
> canonicalized then this should be done where it must be used as a 
> databased/directory lookup key or as a cryptographic salt (where
> roughly the same considerations as for passwords used to derive
> keys apply).  We should delay canonicalization as much as possible
> so as to support the server operator's choice of canonicalization.
> I've mentioned before that many online games allow all sorts of
> username forms that we'd consider silly in an enterprise
> environment, but in online gaming they are quite desirable as a
> form of styling.  Let's not put a straightjacket on users of this
> string preparation -- let each operator pick their poison as much
> as possible.
> 
> The RFC6943 reference should be more specific.  What specific
> confusion cases are we worried about?
> 
> [email-masked] <mailto:[email-masked]> just this once, and I will
> not subscribe to it.  We've had at least two debates on
> SASLprep-bis at KITTEN.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Sep 2013 12:07:33 -0600

On 9/11/13 11:38 AM, Simon Josefsson wrote:
>>> 3.  Uppercase and titlecase characters SHOULD be mapped to
>>> their lowercase equivalents (not doing so can lead to false
>>> positives during authentication and authorization, as described
>>> in [RFC6943]).
>>> 
>> 
>> time.  I believe SASL applications and mechanisms MUST NOT do the
>> above, not on the client side, and that the server should be
>> allowed to do what it wishes.
> 
> If the text above would have any bearing on SASL implementations
> (which isn't clear to me), I would strongly agree with you that the
> text above is a Bad Idea.
> 
> Generally, I believe the use-case of I18N of username & password
> have special requirements that have been ignored by the PRECIS WG
> because the username/password requirements are sometimes
> conflicting with other goals of PRECIS and there doesn't seem to be
> enough interest to cater to both communities at the same time.
> Perhaps that is fine (I understand PRECIS wants to publish), but
> then it should be made clear that PRECIS will have no immediate
> bearing on SASLprepNG.

Hi Simon,

Actually that text comes from draft-ietf-precis-saslprepbis:

http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-04#section-4.2

As I noted to Nico, we need to get this right and we need to take the
time to do so. Alexey and I are committed to doing that, and we'll
find a way to make it happen.

Peter

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

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 11 Sep 2013 20:17:23 +0200

Am 10.09.2013 16:06, schrieb Nico Williams:
> SASL applications and mechanisms MUST NOT do the above, not on the
> client side, and that the server should be allowed to do what it wishes.
>  The only exception is for password (and salt) processing in
> DIGEST/SCRAM-like mechanisms where keys are derived from passwords on
> the client- (and server-) sides, therefore canonical password
> representations are desirable, and even then, case folding would be
> nothing short of -- and I must be utterly frank here-- stupid, as it
> means dropping entropy needlessly.
> 
> databased/directory lookup key or as a cryptographic salt (where roughly
> the same considerations as for passwords used to derive keys apply).  We
> should delay canonicalization as much as possible so as to support the
> server operator's choice of canonicalization.  I've mentioned before
> that many online games allow all sorts of username forms that we'd
> consider silly in an enterprise environment, but in online gaming they
> are quite desirable as a form of styling.  Let's not put a
> straightjacket on users of this string preparation -- let each operator
> pick their poison as much as possible.
> 

I'm a bit confused. My impression is that the draft already contains
text very much in that spirit:
«
   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.
»

While online games might not always want case folded strings, I doubt
having two usernames that differ only in case is ever desirable.

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Sep 2013 23:02:21 -0500

> perspectives, and we're trying to find common ground.

I misread anyways, then overreacted.  Sorry about that.

I have no objection to telling people that they should (not must)
treat usernames case-insensitively.  They should be told to preserve
case as much as possible though, if they allow mixed-case usernames at
all.  Also, if this is a recommendation for people *deploying* or
people designing mechanisms, then the recommendation shouldn't use
RFC2119 language (since it's not a recommendation as to what an
implementation should do.  Finally, if the only goal is to prevent
confusion (thinking that two usernames are equivalent when they are
not), shouldn't the prescription be to check for case-insensitive
collisions at *enrollment* time?  I would think so -- then the
recommendation would not apply to, say, mechanism implementors (since
SASL doesn't deal with enrollment) but to system integrators --
recommendations and requirements about enrollment could be stated in
RFC2119 language.

So, there's some subtle things here to get right.

Also, if the goal is to be case-insensitive then that should be
stated.  As should be case-preservation.  I'm not sure that specifying
the nitty gritty of how case-insensitivity is obtained matters much
here.

> Would you perhaps have time to listen to the recording of the PRECIS

Sure.  I'll take a listen.

> coming to the IETF meeting in Vancouver?

I'm thinking I have to go to Vancouver, but as usual it probably won't
be for the whole week.  My primary interests now lie in KITTEN and
HTTPauth WGs.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Sep 2013 12:01:03 +0200

> having two usernames that differ only in case is ever desirable.

I have accounts in systems were that is used -- for example, in one I
have a lower-case username 'jas' for the ordinary user and an uppercase
variant 'JAS' as a personalized admin account.

In general, I believe that any I18N solution that disallow reasonable
semantics of how username and passwords are interpreted will be
completely ignored.  What can (and should) be discussed is what
"reasonable semantics" means.  But forcing uppercase and lowercase
characters to be regarded as the same is to me so completely and
obviously unreasonable that I believe there is a disconnect between
requirements and solution.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Sep 2013 10:17:57 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Florian Zeitz <[email-masked]> writes:
    >> While online games might not always want case folded strings, I
    >> doubt having two usernames that differ only in case is ever
    >> desirable.

    Simon> I have accounts in systems were that is used -- for example,
    Simon> in one I have a lower-case username 'jas' for the ordinary
    Simon> user and an uppercase variant 'JAS' as a personalized admin
    Simon> account.

    Simon> In general, I believe that any I18N solution that disallow
    Simon> reasonable semantics of how username and passwords are
    Simon> interpreted will be completely ignored.  What can (and
    Simon> should) be discussed is what "reasonable semantics" means.
    Simon> But forcing uppercase and lowercase characters to be regarded
    Simon> as the same is to me so completely and obviously unreasonable
    Simon> that I believe there is a disconnect between requirements and
    Simon> solution.

For myself, I've viewed a lot of systems, some of which case fold
usernames and some of which do not.

I think there's a lot of evidence that  systems like AD that case-fold
usernames are easier to use.
In my mind sufficient evidence to try and move the internet in that
direction.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Sep 2013 22:27:01 +0200

> In my mind sufficient evidence to try and move the internet in that

I disagree that an I18N document is the appropriate way to move the
Internet to case-insensitive usernames.

If case-sensitive usernames is a significant problem, then it should be
possible to publish a BCP recommending against that.  Then existing
protocols with case-sensitive usernames like HTTP, FTP, SMTP, SSH, etc
could be revised.  I don't believe any of that will happen, so we'll
have to live with case sensitive usernames, and my take is that I18N
documents should permit that.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Sep 2013 16:44:03 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> 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 documents
    Simon> 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.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Sep 2013 23:17:46 +0200

You wrote:

>     Simon> case sensitive usernames, and my take is that I18N
>     Simon> documents should permit that.
> 

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.  For passwords, there are also security aspects, since case
folding reduces entropy.  Maybe in some of these details we can find
were we agree and disagree.

/Simon

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 25 Sep 2013 16:06:04 -0700

> Internet to case-insensitive usernames.

+1

The arguments re case sensitivity are legitimate concerns, and should be dealt with in the appropriate documents.  
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]