Subject: [precis] spaces at end of nickname

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Nov 2012 08:41:55 -0600

In the context of groupchat rooms, most applications show a room
roster of the participants. One way to spoof nicknames is to simply
add one or more space characters at the end, because the spaces don't
show up in the interface (thus "stpeter", "stpeter " with one space at
the end, and "stpeter  " with two spaces at the end would all appear
to be the same person). This seems like an obvious hole that we can
plug by disallowing trailing (and perhaps leading) spaces in
nicknames. I'll forward this message to the SIMPLE WG and XMPP WG for
their feedback, and also raise this issue during the PRECIS WG session
next week.

Peter

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

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 1 Nov 2012 15:08:33 +0000

On Nov 1, 2012, at 8:41 AM, Peter Saint-Andre <[email-masked]>
 wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

+1 to disallowing leading and trailing whitespace.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 01 Nov 2012 15:22:23 +0000

> +1 to disallowing leading and trailing whitespace.
+1 (both leading and trailing whitespaces are already disallowed in 
usernames).

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 1 Nov 2012 15:27:08 +0000

>+1 (both leading and trailing whitespaces are already disallowed in

 +1 

-- 
Joe Hildebrand

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 1 Nov 2012 16:28:15 +0100

+1

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Nov 2012 16:44:14 -0600

On 11/1/12 9:28 AM, Salvatore Loreto wrote:
>>> +1 (both leading and trailing whitespaces are already
>>> disallowed in usernames).
>> +1
>> 
> +1

OK, I propose adding the following rules to Section 2:

   4.  Leading and trailing whitespace (i.e., one or more instances of
       the ASCII space character at the beginning or end of a nickname)
       MUST be removed.

   5.  Interior sequences of more than one ASCII space character MUST be
       mapped to a single ASCII space character.

Peter

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 02 Nov 2012 08:45:30 +0900

What about other spaces? With just ASCII spaces being removed, couldn't 
I spoof a nickname with e.g. a full-width space (U+3000)? Or is this 
already taken care by mapping or removing these?

Regards,   Martin.

On 2012/11/02 7:44, Peter Saint-Andre wrote:
>>> On 11/1/12 9:22 AM, "Alexey Melnikov"<[email-masked]>
>>> wrote:
>>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlCS+z4ACgkQNL8k5A2w/vwkOwCgvvM4/KQVKuCCdDKuWt7HkSzm
> 6K4AoO3KBCuNSAGO62aUWIVQQ924Tp/E
> =rrvp
> -----END PGP SIGNATURE-----
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Nov 2012 18:27:47 -0600

On 11/1/12 5:45 PM, "Martin J. Dürst" wrote:
> What about other spaces? With just ASCII spaces being removed,
> couldn't I spoof a nickname with e.g. a full-width space (U+3000)?
> Or is this already taken care by mapping or removing these?

Rule 3 in that section is:

   3.  Non-ASCII space characters from the "N" category defined under
       Section 6.14 of [I-D.ietf-precis-framework] MUST be mapped to
       U+0020 SPACE.

The rules are applied in order, so non-ASCII space character will have
already been mapped to ASCII space by the time the new rules I
proposed are applied.

Peter

> 
> Regards,   Martin.
> 
> On 2012/11/02 7:44, Peter Saint-Andre wrote: On 11/1/12 9:28 AM,
> Salvatore Loreto wrote:
>>>>> On 11/1/12 9:22 AM, "Alexey
>>>>> Melnikov"<[email-masked]> wrote:
>>>>> 
> 4.  Leading and trailing whitespace (i.e., one or more instances
> of the ASCII space character at the beginning or end of a
> nickname) MUST be removed.
> 
> 5.  Interior sequences of more than one ASCII space character MUST
> be mapped to a single ASCII space character.
> 
> Peter
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 2 Nov 2012 14:37:39 +0000

>       mapped to a single ASCII space character.

I think that's ok.  I'd need to see it in the context of the other rules to be sure.

- m&m

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 02 Nov 2012 20:05:35 -0600

On 11/2/12 8:37 AM, Matt Miller (mamille2) wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> 5.  Interior sequences of more than one ASCII space character
>> MUST be mapped to a single ASCII space character.
>> 
> 

Ask, and ye shall receive.

###

   For comparison purposes (e.g., when a chatroom server determines if
   two nicknames are in conflict during the authorization process), an
   application MUST treat a nickname as follows, where the operations
   specified MUST be completed in the order shown (in particular,
   normalization MUST be performed before all other mapping steps and
   validity checks, consistent with [I-D.ietf-precis-framework]):

   1.  The string MUST be normalized using Unicode Normalization Form KC
       (NFKC).  Because NFKC is more "aggressive" in finding matches
       than other normalization forms (in the terminology of Unicode, it
       performs both canonical and compatibility decomposition before
       recomposing code points), this rule helps to reduce the
       possibility of confusion by increasing the number of characters
       that would match (e.g., U+2163 ROMAN NUMERAL FOUR would match the
       combination of U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN
       CAPITAL LETTER V).

   2.  Uppercase and titlecase characters MUST be mapped to their
       lowercase equivalents.  In applications that prohibit conflicting
       nicknames, this rule helps to reduce the possibility of confusion
       by ensuring that nicknames differing only by case (e.g.,
       "stpeter" vs. "StPeter") would not be allowed in a chatroom at
       the same time.

   4.  Leading and trailing whitespace (i.e., one or more instances of
       the ASCII space character at the beginning or end of a nickname)
       MUST be removed (e.g., "stpeter " is mapped to "stpeter").

   5.  Interior sequences of more than one ASCII space character MUST be
       mapped to a single ASCII space character (e.g., "St  Peter" is
       mapped to "St Peter").

   6.  Other mappings MAY be applied, such as those defined in
       [I-D.yoneya-precis-mappings].  (Note that mapping of fullwidth
       and halfwidth characters to their decomposition mappings is not
       necessary, since those mappings are performed as part of
       normalization using NFKC.)

###

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 6 Nov 2012 11:51:49 +0000

>       normalization using NFKC.)

I think we should also add the confusable mapping (see:
http://www.unicode.org/reports/tr39/#Confusable_Detection) here.

This brings up another point, however.  I think that things that are
acting as registries (such as a chat server ensuring that there aren't two
people using the same nickname) MUST NOT transmit these
liberally-normalized names.  That means they probably have to keep at
least two (and maybe three) versions around:

- The précis-mapped version for equality checking
- The confusable-mapped version for uniqueness checking
- The original version (maybe, if the précis-mapped version is losing
information)

This way, the spaces would still exist, but they aren't an attack vector.

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Nov 2012 23:48:51 -0500

On 11/6/12 6:51 AM, Joe Hildebrand (jhildebr) wrote:
>> For comparison purposes (e.g., when a chatroom server determines
>> if two nicknames are in conflict during the authorization
>> process), an application MUST treat a nickname as follows, where
>> the operations specified MUST be completed in the order shown (in
>> particular, normalization MUST be performed before all other
>> mapping steps and validity checks, consistent with
>> [I-D.ietf-precis-framework]):
>> 
>> 1.  The string MUST be normalized using Unicode Normalization
>> Form KC (NFKC).  Because NFKC is more "aggressive" in finding
>> matches than other normalization forms (in the terminology of
>> Unicode, it performs both canonical and compatibility
>> decomposition before recomposing code points), this rule helps to
>> reduce the possibility of confusion by increasing the number of
>> characters that would match (e.g., U+2163 ROMAN NUMERAL FOUR
>> would match the combination of U+0049 LATIN CAPITAL LETTER I and
>> U+0056 LATIN CAPITAL LETTER V).
>> 
>> lowercase equivalents.  In applications that prohibit
>> conflicting nicknames, this rule helps to reduce the possibility
>> of confusion by ensuring that nicknames differing only by case
>> (e.g., "stpeter" vs. "StPeter") would not be allowed in a
>> chatroom at the same time.
>> 
>> 3.  Non-ASCII space characters from the "N" category defined
>> under Section 6.14 of [I-D.ietf-precis-framework] MUST be mapped
>> to U+0020 SPACE.
>> 
>> nickname) MUST be removed (e.g., "stpeter " is mapped to
>> "stpeter").
>> 
>> MUST be mapped to a single ASCII space character (e.g., "St
>> Peter" is mapped to "St Peter").
>> 

Based on discussion during the WG session today, I'd say we didn't
have agreement to go down that path, at least not for this specification.

Peter

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