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

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Jul 2013 13:56:52 -0600

On 5/3/13 1:39 PM, Nico Williams wrote:

> Please forgive my apparent apathy.  I lost track of this due to
> business travel.

And please forgive my delay in replying. It's good to know you're not
apathetic. And as you can tell, we're proceeding rather slowly with
this work. That doesn't mean it is unimportant. This recent example
from the blogosphere might of interest:

http://labs.spotify.com/2013/06/18/creative-usernames/

PRECIS might have helped those folks avoid some significant pain.

> I'm not sure where the case mapping requirement for usernames came 
> from.

Are you referring to global case mapping or local case mapping?

> I guess it has something to do with the Turkish I and such.

Yes, that is a nasty problem with even nastier consequences:

http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail

Just to be clear, that's an issue of what we're calling local case
mapping (where locale is taken into consideration).

> I can't say I'm excited about this case mapping requirement; if
> anything it strikes as silly.

In general, the opinion so far has been that, say, StPeter is treated
the same as stpeter when it comes to authentication and authorization
based on usernames. Do you disagree? If so, why? For example, would
you be inclined to leave this up to the protocol that uses SASL (say,
IMAP or XMPP) instead of specifying it in SASLprepbis?

> Why would we apply mappings to usernames (which are sent on the
> wire) that we don't apply to passwords (which servers generally
> don't get the plaintext of)?  We need mappings for passwords to
> make password entry reliable.  The same does NOT apply to
> usernames.

My naïve perspective is that the combination of username and password
is your credential (for password-based systems). If I provide StPeter
and AUrwyaxDQ6rH68OefESL as my username and password, IMHO we sure
want the password to be treated in a case-sensitive manner (since that
reduces the possibility of false positives), whereas we want the
username to be treated in a case-insensitive manner (since most
application protocols treat [email-masked] as the same account as
[email-masked]).

> Also, looking at SASLprep and PRECIS, I see no mention of query 
> strings vs. display vs. storage.  These distinctions matter.  But 
> maybe I'm just failing to search for the right terms.

Would you be so kind as to expand on that a bit? I'd like to make sure
I understand what you mean by each of those terms.

> Heck, we're not even told whether these rules should be applied by
> the client, the server, or both.

That is a very good point. This was something that bit us in RFC 3920
(for XMPP) and we've cleared that up in 6122bis:

http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-07#section-3

In my experience, we can *say* that the client needs to do this, but
the server will need to do it anyway since it can't trust the client
to do the right thing. However, for passwords (which, as you note, we
hope the server never sees in plaintext) the client would need to
enforce the rules.

> Anyways, I'm for applying as few transformations as possible to 
> usernames on the *client* side and leaving the server to apply 
> RECOMMENDED, and a few REQUIRED rules for matching.

I'd agree with that sentiment.

> I don't see room for case folding in general,

Even on the server side? Again, do you think it would be better to
leave that up to the application?

> but I do for specific cases (e.g., Turkish I handling).

Unfortunately, local case mapping might be difficult for the server to
perform because it doesn't necessarily have information about the
locale of the user. So this is something that might best be handled at
the client.

> If this review is too late to make a difference, well, c'est la
> vie. But do give the above some thought before rejecting my
> comments for being late.  Once more, I'm sorry I let this slip.

You are not too late and your comments are important!

Peter

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jul 2013 18:20:40 -0500

> http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail

!

But that can't apply here.  Or, if anything, case mappings makes it
more likely.  Let's say I'm logged in in some app and it shows the
username I typed in, but because of case mapping some typos are
tolerated, so the username shown could offend someone.  Whereas if I'm
required to type my username exactly one way (not including NF) then
that can't happen.  So if anything that link indicates we should not
have case mappings here...  :)

> IMAP or XMPP) instead of specifying it in SASLprepbis?

I think it'd be nice if *servers* got to choose whether to do this.
The principle here is that the server should make right when it comes
to the username.  This means that clients should be pretty much able
to send just about anything as a username and let the server figure it
out.

Whether it's a server application or the mechanisms (or SASL library)
that applies such rules is a different story, and one I don't think I
care much about here.

> application protocols treat [email-masked] as the same account as

It's not just false positives: many sites require multiple character
classes in password data, but case folding would nullify part of such
policies :)

If the user's password must survive with case intact then the user
must be able to enter it portably (i.e., on many devices).  Surely
asking the same of usernames is not an undue additional burden for the
user.

Still, I don't mind if some site wants to have case-insensitive
usernames.  I just don't want us to impose that policy on *all* sites.

Once again I'm thinking of online games, ones where people often
convey ideas (usually comical ones) via their usernames.  Providing
the most freedom possible here seems like the right thing to do;
requiring case-insensitivity is denying some freedom.

> I understand what you mean by each of those terms.

Sure.

Query string == a string entered by a user in some UI, to be matched
against some thing's name.

Display string == a thing's name, as displayed to users in UIs.

Storage string == a thing's name as stored, and usually this is the
canonical form of the thing's name.

For example, "nico" might be a query name for my Kerberos principal,
but the display name might be [email-masked], and the storage
string will be in some format we don't really care about here but
roughly equivalent to the display string form.

To continue the example, if my KDC was case-insensitive then "Nico"
would also work as a query string; what I get for the display string
might either match the query string or the storage string, and the
storage string could be any of the many case variants of "nico" (but
almost certainly would be case-folded in many implementations).

The relevance here is that we should apply as few transformations as
possible to *query* strings on the client-side and just send them.
What transformations a server applies then can be up to the server
and/or the mechanism (e.g., a federated mechanism might need to apply
transformations specified by it).

SASLprep-like stringpreps are very useful, especially for *passwords*
because passwords may need to be in canonical form because they are
used as inputs to client-side cryptographic functions (e.g., Digest).
But they are less relevant for usernames, unless they too are used as
inputs to client-side cryptographic functions (e.g., as salts), but
even then the username query string might still be sent as-is
separately to the server.

> (for XMPP) and we've cleared that up in 6122bis:

This is where the distinction between query, display, and storage (or
canonical) forms comes in.

> hope the server never sees in plaintext) the client would need to

Correct, as to the last part.  I don't think we need the client to
apply this to anything that isn't an input to a cryptograhic function
on the client-side -- just send the darned thing as is.

> I'd agree with that sentiment.

Great.

> leave that up to the application?

I'd leave it to the site/mechanism/app -- whatever's appropriate.

> locale of the user. So this is something that might best be handled at

Ah, well, if we're dealing in Unicode we could send a language tag in
the string.  That's a non-starter.

But note that the server probably has a username database anyways, so
it knows the relevant language at account-creation time (or should
anyways).

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Jul 2013 13:00:41 -0600

> that applies such rules is a different story, and one I don't think I

Ah, I see.

It seems to me that there are numerous layers here:

1. SASL (including preparation and comparison rules)

2. The application protocol that's using SASL (e.g., IMAP)

3. A software implementation of the application protocol, which likely
embeds or links to a SASL implementation (e.g., dovecot)

4. A deployment of said software implementation (e.g., example.net)

By "server" I think you mean a deployment. Correct?

Rather than legislating in saslprepbis that all application protocols
shall leave casemapping up to implementations or deployments, I think
that it would be reasonable for the specification of an application
protocol using SASL (e.g., draft-ietf-xmpp-6122bis) to recommend or
require casemapping behavior for all implementations or deployments of
that application protocol, or to leave such decisions up to the
implementation or deployment. For example, perhaps the XMPP spec would
say "all implementations shall perform case mapping, full stop" whereas
the IMAP spec might leave that up to implementations or deployments.

> classes in password data, but case folding would nullify part of such

Indeed!

> usernames.  I just don't want us to impose that policy on *all* sites.

I now agree that I don't want the SASLprepbis spec to impose that policy
on all sites, but I also don't think that I want the SASLprepbis spec to
impose deployment-layer policies on all application protocols. However,
I do think it's reasonable for the SASLprepbis spec to say
"specifications for application protocols that use SASLprepbis must
specify the casemapping policy for that application protocol; options
include but are not limited to legislating behavior for all
implementations or leaving casemapping up to particular deployments".

> requiring case-insensitivity is denying some freedom.

The SASLprepbis document is about comparison and what gets sent over the
wire. An application might preserve case for user interface purposes but
still lowercase "StPeter" to "stpeter" for comparison purposes during
authentication.

See also the nickname spec (what you're talking about sounds more like
a nickname or screen name than a username, but that might be a
distinction without a difference):

http://tools.ietf.org/id/draft-ietf-precis-nickname-05.txt

> separately to the server.

Thanks for clarifying.

> canonical) forms comes in.

Yes.

> I'd leave it to the site/mechanism/app -- whatever's appropriate.

OK, good. That's consistent with what I typed earlier in this message.

> it knows the relevant language at account-creation time (or should

Quite possible. In XMPP the client can tell the server its locale, but
that might not be supported yet in other application protocols...

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Jul 2013 14:49:23 -0600

Hi Nico, I've looked at this a bit further. Proposed text changes below...

On 7/10/13 1:00 PM, Peter Saint-Andre wrote:
>>>> Please forgive my apparent apathy.  I lost track of this due
>>>> to business travel.
>>> 
>>> And please forgive my delay in replying. It's good to know
>>> you're not apathetic. And as you can tell, we're proceeding
>>> rather slowly with this work. That doesn't mean it is
>>> unimportant. This recent example from the blogosphere might of
>>> interest:
>>> 
>>>> I'm not sure where the case mapping requirement for usernames
>>>> came from.
>>> 
!
>> 
>> But that can't apply here.  Or, if anything, case mappings makes
>> it more likely.  Let's say I'm logged in in some app and it shows
>> the username I typed in, but because of case mapping some typos
>> are tolerated, so the username shown could offend someone.
>> Whereas if I'm required to type my username exactly one way (not
>> including NF) then that can't happen.  So if anything that link
>> indicates we should not have case mappings here...  :)
>> 
>>> Just to be clear, that's an issue of what we're calling local
>>> case mapping (where locale is taken into consideration).
>>> 
>>>> I can't say I'm excited about this case mapping requirement;
>>>> if anything it strikes as silly.
>>> 
>>> In general, the opinion so far has been that, say, StPeter is
>>> treated the same as stpeter when it comes to authentication and
>>> authorization based on usernames. Do you disagree? If so, why?
>>> For example, would you be inclined to leave this up to the
>>> protocol that uses SASL (say, IMAP or XMPP) instead of
>>> specifying it in SASLprepbis?
>> 
>> I think it'd be nice if *servers* got to choose whether to do
>> this. The principle here is that the server should make right
>> when it comes to the username.  This means that clients should be
>> pretty much able to send just about anything as a username and
>> let the server figure it out.
>> 
>> Whether it's a server application or the mechanisms (or SASL
>> library) that applies such rules is a different story, and one I
>> don't think I care much about here.
> 
> Ah, I see.
> 
> 3. A software implementation of the application protocol, which
> likely embeds or links to a SASL implementation (e.g., dovecot)
> 
> Rather than legislating in saslprepbis that all application
> protocols shall leave casemapping up to implementations or
> deployments, I think that it would be reasonable for the
> specification of an application protocol using SASL (e.g.,
> draft-ietf-xmpp-6122bis) to recommend or require casemapping
> behavior for all implementations or deployments of that application
> protocol, or to leave such decisions up to the implementation or
> deployment. For example, perhaps the XMPP spec would say "all
> implementations shall perform case mapping, full stop" whereas the
> IMAP spec might leave that up to implementations or deployments.

Here is what I suggest in Section 2.2 of draft-ietf-precis-saslprepbis:

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

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

Then add the following sentence at the end of that section:

   Application protocols that use this profile MUST specify whether case
   mapping or additional mapping is to be applied by implementations or
   deployments of that protocol.

Does that seem acceptable?

Peter

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

---

From: Nico Williams <[email-masked]>
Date: Wed, 10 Jul 2013 16:20:16 -0500

> It seems to me that there are numerous layers here:

Yes.  Lots of layers.  Consider SASL/GS1 and SASL/GS2 as well.

> By "server" I think you mean a deployment. Correct?

Generally, yes.

> the IMAP spec might leave that up to implementations or deployments.

We could have:

 - apps specify whether to case fold
 - apps specify that the server can casefold if it wants

That's fine with me.

Note that the second comes naturally from speaking of
query/display/store syntaxes.  The client only deals in query and
display syntaxes for usernames, so the server can make right.

> implementations or leaving casemapping up to particular deployments".

No, not MUST, but MAY is fine, and I might go along with SHOULD.
First, we'd be informing authors of app protocol specs -- we can use
RFC2119 language for that, but it's hard to enforce -- this language
doesn't deal with interop.

> still lowercase "StPeter" to "stpeter" for comparison purposes during

The only party doing comparisons is the server, therefore the only
party that should have to apply any sort of normalization should also
be the server -- otherwise if the client also normalizes *prevents*
some names from being useful/usable.  Normalizations that preserve
equivalence can be OK on the client side (e.g., Unicode
normalization), but case folding loses information.

This principle, that the party doing comparisons/lookups (because the
server might be comparing hashes for all we know) is the party that
should normalize, is a very useful principle here.  It follows from
distinguishing types of name syntax.

If multiple parties have to do these comparisons/lookups *then* we may
need to say more about who normalizes and when (and why).

> distinction without a difference):

Remember that what I have in mind is a bevy of online games where
users are free to pick usernames we'd *never* consider valid in an
enterprise environment, like "Joe 6-pack (I'm the best)".

(For an example you can see for yourself, download bzflag and play for
a bit.  It's an open source game with user-contributed maps, user-run
servers, and so on.  Its users tend to have weird names -- these
aren't nicknames, they *are* the usernames, it's what you type in at
login time.)

> OK, good. That's consistent with what I typed earlier in this message.

Well, except I want to be able to leave it to the server if the app
protocol authors think that's fine.

I don't want to prescribe that app protocols must prescribe which
normalization the clients apply.  I don't mind if some app protocols
do.  But I want it to be possible that the client doesn't have to.  In
fact, I'd prefer if SASL clients *never* had to normalize usernames
*except* when they must use them for salting purposes (but still send
the unmodified original as the actual username) -- it's far simpler
and most flexible this way.

> that might not be supported yet in other application protocols...

Right, but I think the server still has enough context.  In the worst
case scenario it might have to try N different normalizations and
lookups, but I kinda doubt N will ever be larger than 1.

Nico
--

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 10 Jul 2013 18:07:37 -0400

>   deployments of that protocol.

I have a hard time thinking that, especially for credentials, app protocol 1 chooses no mapping and app protocol 2 chooses mapping and that both are using the SASL layer below.  Looks like looking for trouble here. no?

Marc.

> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Nico Williams <[email-masked]>
Date: Wed, 10 Jul 2013 17:37:04 -0500

>    3.  Uppercase and titlecase characters MAY be mapped to their

Do we need to give advice regarding the use of query strings for
cryptographic protocols?  E.g., usernames as salts.  I think we do.
Specifically, *mechanisms* must specify what normalizations (and let's
provide a nice one for them to all use) for such purposes.

Yes.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 10 Jul 2013 17:41:43 -0500

> I have a hard time thinking that, especially for credentials, app protocol 1 chooses no mapping and app protocol 2 chooses mapping and that both are using the SASL layer below.  Looks like looking…

The mechanism on the server side absolutely must apply whatever
normalization is appropriate for it.

The client should not have to.

The app protocol could specify whether the client does or does not
have to, I don't mind that.  But it'd be silly to specify something
that conflicts with whatever the mechanism will apply, so, that's a
good point.

All the more reason to have the app do nothing with usernames.  Just
pass them to the mechanism.  Let the mechanism work it out.

The mechanism on the client side should only normalize usernames for
the purposes of generating salts.

Also, the mechanism on the client side may want to apply Unicode
normalization if the client has an input mode that produces NFD (say)
when most servers happen to not implement a normalization (though they
should) and expect NFC (say, which mostly they do).

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 11 Jul 2013 08:44:59 +0100

Yes.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Jul 2013 11:49:09 -0600

>> Does that seem acceptable?

Thanks for the feedback. I was wondering last night whether we want to
add some guidance or recommendations on this topic, or truly just leave
it up to those who define application protocols. (For example, we could
say something about balancing interoperability and user expectations.)

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Jul 2013 13:27:49 -0600

On 7/10/13 4:07 PM, Marc Blanchet wrote:
>>>>>> Please forgive my apparent apathy.  I lost track of this
>>>>>> due to business travel.
>>>>> 
>>>>> unimportant. This recent example from the blogosphere might
>>>>> of interest:
>>>>> 
>>>>>> I'm not sure where the case mapping requirement for
>>>>>> usernames came from.
>>>>> 
!
>>>> 
>>>> But that can't apply here.  Or, if anything, case mappings
>>>> makes it more likely.  Let's say I'm logged in in some app and
>>>> it shows the username I typed in, but because of case mapping
>>>> some typos are tolerated, so the username shown could offend
>>>> someone. Whereas if I'm required to type my username exactly
>>>> one way (not including NF) then that can't happen.  So if
>>>> anything that link indicates we should not have case mappings
>>>> here...  :)
>>>> 
>>>>> Just to be clear, that's an issue of what we're calling
>>>>> local case mapping (where locale is taken into
>>>>> consideration).
>>>>> 
>>>>>> I can't say I'm excited about this case mapping
>>>>>> requirement; if anything it strikes as silly.
>>>>> 
>>>>> In general, the opinion so far has been that, say, StPeter
>>>>> is treated the same as stpeter when it comes to
>>>>> authentication and authorization based on usernames. Do you
>>>>> disagree? If so, why? For example, would you be inclined to
>>>>> leave this up to the protocol that uses SASL (say, IMAP or
>>>>> XMPP) instead of specifying it in SASLprepbis?
>>>> 
>>>> when it comes to the username.  This means that clients should
>>>> be pretty much able to send just about anything as a username
>>>> and let the server figure it out.
>>>> 
>>>> library) that applies such rules is a different story, and one
>>>> I don't think I care much about here.
>>> 
>>> Ah, I see.
>>> 
>>> behavior for all implementations or deployments of that
>>> application protocol, or to leave such decisions up to the
>>> implementation or deployment. For example, perhaps the XMPP spec
>>> would say "all implementations shall perform case mapping, full
>>> stop" whereas the IMAP spec might leave that up to
>>> implementations or deployments.
>> 
>> OLD 3.  Uppercase and titlecase characters MUST be mapped to their 
>> lowercase equivalents.
>> 
>> NEW 3.  Uppercase and titlecase characters MAY be mapped to their 
>> lowercase equivalents.
>> 
>> Application protocols that use this profile MUST specify whether
>> case mapping or additional mapping is to be applied by
>> implementations or deployments of that protocol.
> 
> I have a hard time thinking that, especially for credentials, app
> protocol 1 chooses no mapping and app protocol 2 chooses mapping and
> that both are using the SASL layer below.  Looks like looking for
> trouble here. no?

I see your point, although I agree with Nico and Jeff that for SASL
purposes these things will be mostly or completely determined by the
mechanism (not all mechanisms have a concept of a "simple user name" --
the ones I'm familiar with are CRAM-MD5, DIGEST-MD5, and SCRAM).
However, I think that this PRECIS profile might be used by
non-SASL-using application protocols, such as HTTP authentication (see
message from Yutaka Oiwa).

I will try to formulate some corrected text.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Jul 2013 13:45:56 -0600

> I will try to formulate some corrected text.

How's this?

OLD

NEW

   SASL mechanisms and application protocols that directly re-use this
   profile MUST specify whether case mapping or additional mapping is to
   be applied by implementations or deployments thereof.  Note that some
   application protocols themselves re-use SASL (examples include IMAP
   [RFC4616] and XMPP [RFC6120]); such protocols ought to apply the
   mapping rules defined for the relevant SASL mechanisms and not
   specify application-specific rules for that protocol's use of SASL or
   particular SASL mechanisms.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Jul 2013 14:04:40 -0600

On 7/11/13 8:55 AM, Jeffrey Hutzelman wrote:

[snipping lots of interesting material, since I'm focused on finding
appropriate text before the I-D deadline]

> Now, back to the original point...
> 
> 
>> case
> The key phrase is "Application protocols that use this profile".  Such a
> protocol can apply the profile, and rules about whether to do
> case-mapping, only to protocol elements that belong to it.  For example,
> an application might apply the profile to its SASL authorization names,
> or to some other protocol element that is not related to SASL at all.
> But it cannot apply the profile to protocol elements that a particular
> SASL mechanism depends on, because those belong to the mechanism and
> exist below the SASL abstraction, where the application protocol spec
> cannot even see them.

Agreed.

> That said, I think we need to be clear that the profile is _also_
> available for use by SASL _mechanisms_, since after all, that was no
> small part of the original purpose of SASLprep.  The same requirement
> applies -- a mechanism that uses the profile must specify whether to do
> case folding.

Right. We have two direct customers here: SASL mechanisms and
application protocols that don't use SASL (e.g., HTTP auth). What you're
terming "SASL application protocols" are indirect customers and IMHO we
don't want to encourage them to do interesting things with the strings
that they feed into SASL implementations.

> FWIW, I think both the "OLD" and "NEW" variants from Peter's message are
> wrong.  We should not say that case-folding MUST be done, because that
> mandates its use everywhere.  However, we should also not say that it
> MAY be done, because that looks like we are granting permission for
> implementations of the profile to do case-folding anytime they want,
> even if that's not what the protocol says.

Mostly agree.

The PRECIS framework specification says that any PRECIS "usage" (of
which so far we have nickname, username, password, XMPP localpart, and
XMPP resourcepart) must specify its rules for casemapping (among other
things).

> Instead, we should keep only the sentence Peter proposes adding at the
> end, or some variation thereof, which has the effect of leaving the
> case-folding question up to the protocol applying the profile.

Right. So we need to re-word the rule:

REALLY OLD

   2.  So-called additional mappings MAY be applied, such as those
       defined in [I-D.ietf-precis-mappings].
   3.  Uppercase and titlecase characters MUST be mapped to their
       lowercase equivalents.

MORE RECENT

   2.  So-called additional mappings MAY be applied, such as those
       defined in [I-D.ietf-precis-mappings].
   3.  Uppercase and titlecase characters MAY be mapped to their
       lowercase equivalents.

PROPOSED SOLUTION

   2.  SASL mechanisms and application protocols that directly
       use this profile MUST specify whether so-called additional
       mappings are to be applied, such as those defined in
       [I-D.ietf-precis-mappings].
   3.  SASL mechanisms and application protocols that directly
       use this profile MUST specify whether uppercase and titlecase
       characters are be mapped to their lowercase equivalents.

Then we'd have something like the follow-on paragraph I just posted:

   As noted, SASL mechanisms and application protocols that directly
   use this profile MUST specify whether case mapping and additional
   mappings are to be applied by implementations or deployments
   thereof.  Note that some application protocols themselves re-use
   SASL (examples include IMAP [RFC4616] and XMPP [RFC6120]); such
   protocols ought to apply the mapping rules defined for the relevant
   SASL mechanisms and not specify application-specific rules for that
   protocol's use of SASL or particular SASL mechanisms.

Peter

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 15:12:47 -0500

>    particular SASL mechanisms.

I don't really like the second sentence.  In all cases *only* the
application applies any stringprep to authorization IDs, and *only*
mechanisms apply any stringprep to authentication IDs.  (If a SASL
framework implementation allows an app to provide an authentication DB
for a mechanism then the app is providing a bit of mechanism
functionality but it should still be understood as properly a part of
the mechanism.  We don't usually go into that level of detail in the
core SASL RFC, and we shouldn't here.

NEW
   SASL mechanisms that directly re-use this profile MUST specify
   whether case mapping is to be applied to authentication IDs, and
   when.  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.

   SASL application protocols that directly re-use this profile MUST
   specify whether case mapping is to be applied to authorization IDs.
   SASL application protocols SHOULD delay any case mapping of
   authorization IDs to the last possible moment, which happens to
   necessarily be on the server side.

   Note that, in keeping with RFC4422, SASL applications must not apply
   this or any other profile to authentication IDs.

   Note that, in keeping with RFC4422, SASL mechanisms must not apply
   this or any other profile to authorization IDs.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Jul 2013 14:27:19 -0600

> cryptographic protocols?  E.g., usernames as salts.  I think we do.

It seems to me that rules for handling query strings in a cryptographic
protocol would be the responsibility of that protocol. Now, maybe you
are suggesting that such protocols would apply the PRECIS profile we're
defining here, if it provides what they need. Do you think that the
rules in draft-ietf-precis-saslprepbis are sufficient? I get the sense
you think more is needed, but I'm not yet sure exactly what.

> provide a nice one for them to all use) for such purposes.

When you say "mechanisms" do you mean "SASL mechanisms" and when you say
"normalizations" do you mean "Unicode normalization forms"? I ask
because I think we have those bases covered, but perhaps you're looking
for more...

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Jul 2013 14:30:19 -0600

>    this or any other profile to authorization IDs.

That is much more precise than what I had sketched out, and it looks
good to me.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Jul 2013 17:32:30 -0600

On 7/11/13 2:45 PM, Jeffrey Hutzelman wrote:
> On Thu, 2013-07-11 at 14:30 -0600, Peter Saint-Andre wrote:
> 
>>> NEW
> Me too

Great. If there are no objections from my co-author in the next 24 hours
or so, I'll submit a revised I-D. I'd really like to finish off all this
i18n stuff... :-)

Peter

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 11 Jul 2013 10:55:40 -0400

> pass them to the mechanism.  Let the mechanism work it out.

This is a key point.  SASL doesn't have usernames.  It has
authentication names and authorization names.  SASL application
protocols do not get a say in how authentication names are handled,
period.  It's just not up to them; these names are artifacts of the SASL
mechanism, and their handling is generally dictated by the underlying
authentication technology.

SASLprep is not and never was about setting down general rules for
handling authentication names or what SASL application protocols must
do.  It was about providing a profile for use by specific SASL
mechanisms that are in the position of defining "username" or password
elements that need one.

Applications do get a say about authorization names; in fact, they get
the _only_ say.  They are the application's "usernames", and SASL
doesn't get to say what they look like or what they mean.  That is the
purview of the application, which is entirely responsible for
authorization.  SASL is merely the authentication framework, and not
necessarily even the only one supported by any given application.

Of course, we can give advice to application protocol designers, but we
can't effectively impose requirements, and there's not really even any
reason to do so.  Further, any advice we do give would not be in any way
SASL-specific, so while it might be appropriate for PRECIS to do such a
thing, saslprep might not be the best place to do so.

> the purposes of generating salts.

This is almost right.  From what I've seen, in authentication,
filesystems, and other places, the right thing is almost always to apply
normalization or any other canonicalizations at the last possible
moment, and no later.  For example, if you're going to look up a name in
a database, normalize just before the lookup and not before.  Or, better
yet, don't normalize keys that go into the database, and do
normalization-insensitive comparison instead.  This can be a bit tricky
depending on the nature of the database, but not impossible.

The case you mention is an interesting one, though stated slightly too
narrowly.  Any string that is going to be used as a salt, or to derive
keying material, or as input to a cryptographic hash, will need to be
normalized before doing that.  But, _only if the string itself will not
be sent_.  If the string is being sent, then send and use the
un-normalized form, and the far end can use a normalization-insensitive
comparison to decide if it got what it was expecting, or it can
normalize (as late as possible!) and do whatever database lookup is
needed.

Note again that there is nothing about this advice that's specific to
SASL or SASL mechanisms or SASL application protocols.  However, it does
apply to protocol designs, not implementations -- if a protocol says to
normalize at a particular point, an implementation cannot decide to
instead follow the "as late as possible" rule, or interoperability will
suffer.  I think that means we need to be careful about anything we
specify here; we can offer advice to protocol designers, but we cannot
impose requirements directly on implementations about whether or when to
normalize or case-convert.  Otherwise, we risk hindering
interoperability instead of helping it.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 11 Jul 2013 16:45:53 -0400

Me too

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 14 Jul 2013 12:31:21 -0400

Le 2013-07-11 à 19:32, Peter Saint-Andre <[email-masked]> a écrit :

> or so,

you're ok ... ;-)

Marc.

> I'll submit a revised I-D. I'd really like to finish off all this
> i18n stuff... :-)
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/