Subject: Re: [P2PSIP] RELOAD Base issue: stringprep of password

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 05 Dec 2012 06:58:26 -0800

SASLprep should be mandatory.

SASLprep is already mandatory for TURN (through RFC 5389), so it is not a big
deal for an implementer to use it also for the enrollment server.

On 11/14/2012 11:35 AM, Dean Willis wrote:
> Cullen, Ekr and I discussed this today, and Cullen solicited input from
> Peter Saint-Andre
> 
> 
> Peter says:
> 
> As to the charset issue, it seems safest to specify that the charset must
> be UTF-8 (we don't want to end up with something like charset=windows-1250
> as in Section 4.5 of RFC 2388).
> 
> As to preparation of usernames and passwords, it seems safest right now to 
> say that these strings shall be prepared in accordance with SASLprep (RFC 
> 4013) prior to comparison -- see RFC 4616 for text you could borrow.
> 
> [Eventually, perhaps even relatively soon in "RELOAD years", RFC 4013 will
> be obsoleted by draft-melnikov-precis-saslprepbis; however, you might
> prefer not to gate RELOAD on output from the PRECIS WG.]
> 
> 
> 
> On Nov 9, 2012, at 10:30 AM, Dean Willis wrote:
> 
>> 
>> AD comment:
>> 
>> Section 11.3: What character set is allowed for passwords? What if 
>> something is URL escaped - what's going to match? I'm sure you can copy 
>> from somewhere else, not quite sure what's best though.
>> 
>> 
>> Since we're doing passwords in a POST form, I don't know that URL
>> escaping is an issue. Do we have other stringprep issues? Is there
>> something we can crib from elsewhere for this spec?
>> 

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 5 Dec 2012 15:44:31 +0000

no one does it for TURN as far as I can tell and I am strongly against adding this.

On Dec 5, 2012, at 7:58 AM, Marc Petit-Huguenin <[email-masked]>
 wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJQv2EJAAoJECnERZXWan7Ex20QAMfEtVjEuLa/5/78bMZVNfCt
> W70aXrEji++RTlit97gRf088IGU0nT4BLRKOPrbFt5ID02dQ6cF9E2XiNXTWq5Iv
> zK9nGBWeik/wXF/5ifUgusOQdT12ifzoE5ydsZFmxzpvcqojfdG4px2c873K+x1f
> bKyNITAhv37L+ozFd78tBuk8s6cHa41PDaOE6h/AM0gDLks+V1NTxzfzcx6C7XSM
> SDL4VctSmQUQQsnskjzVhEB+Sti7uomh14UEcNSa72aVe4GIEAkUOSJqUkSamQJG
> VRgxNOKOXfPZ80QUZyVOCKLCDHm6JZb3QIrHZWavDBunAiu6luUvVaCj9xd4RLOp
> rIgDha+eLfz/MpktWf7Tbju5TJDvmQZe+FZg+5iIMQikkigCqCYNVbrxy/7OfBCs
> yPmV9BhN3KNKLmuBpaYJTG9QRUzxzLu62riaFPfnfCrcFli5FBeJwiK+mPRYZ/ET
> cNbTdBojsmX3Pe97lcnpglpTP6z53XRVMH7GRnjlPMmJQTeSnbEGJzfZW3MQFe54
> Ls/hjanTkqcZRQm6+NxB0mTxVydQma8Np1s0u3EOsG/YC3WhSDVQ+ov0DFdFkuLm
> /pv58kWawB3s45EEj7DWJzWS/sV7RUEKMpeqM1rxyex7noF0CK/R7gzjTaTMH93X
> 98Mg8s2O972VWgU1OQCY
> =nOOr
> -----END PGP SIGNATURE-----

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 05 Dec 2012 08:20:18 -0800

> no one does it for TURN as far as I can tell and I am strongly against 

The implementation I wrote during the development of TURN - AFAIK still
in use at 8x8 - implements SASLprep.  As is the one I developed after this.

> 
> On Dec 5, 2012, at 7:58 AM, Marc Petit-Huguenin <[email-masked]> wrote:
> 
> SASLprep is already mandatory for TURN (through RFC 5389), so it is not a 
> big deal for an implementer to use it also for the enrollment server.
> 
>>>> Cullen, Ekr and I discussed this today, and Cullen solicited input 
>>>> from Peter Saint-Andre
>>>> 
>>>> 
>>>> Peter says:
>>>> 
>>>> As to the charset issue, it seems safest to specify that the charset 
>>>> must be UTF-8 (we don't want to end up with something like 
>>>> charset=windows-1250 as in Section 4.5 of RFC 2388).
>>>> 
>>>> As to preparation of usernames and passwords, it seems safest right 
>>>> now to say that these strings shall be prepared in accordance with 
>>>> SASLprep (RFC 4013) prior to comparison -- see RFC 4616 for text you 
>>>> could borrow.
>>>> 
>>>> [Eventually, perhaps even relatively soon in "RELOAD years", RFC
>>>> 4013 will be obsoleted by draft-melnikov-precis-saslprepbis; however,
>>>> you might prefer not to gate RELOAD on output from the PRECIS WG.]
>>>> 
>>>> 
>>>> 
>>>>> something is URL escaped - what's going to match? I'm sure you can 
>>>>> copy from somewhere else, not quite sure what's best though.
>>>>> 
>>>>> 

- -- 
Marc Petit-Huguenin

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 5 Dec 2012 18:11:09 +0000

SASLprep is based on a 10 year old version of unicode and does not provide a reasonable forward compatible way to update the mapping tables for embedded devices. I'd rather not tie ourselves to an absolute version of Unicode. I'd rather not give people the false idea that unicode passwords were going to reliably work across implement ions because that seems pretty unlikely. Obviously there is ongoing work to fix this but the base protocol is a place were for now we can just use characters that are not a problem. 

On Dec 5, 2012, at 9:20 AM, Marc Petit-Huguenin <[email-masked]> wrote:

> iQIcBAEBCAAGBQJQv3RAAAoJECnERZXWan7EU4UQAIJopVNbJu7u3wQccUmIf3fP
> SnhC25bHNzE7rwANQjIcmy/dqKZMbvaqbaBa5MHeniHD6/V+tUMUg72mgfOI6LYz
> rmju/+bBENi+AkIm3EOzxN2yrGccJLW3XqNIVL4tDTItAWnwrrjPIkAfEOCmHmJR
> B16V41JYqNcC7NEUYDmh9B7GeIAHKoBzRfi0wOHQhtmh7MrhhszCP3aS1DgAVRWS
> 7uOtSTTVZQI/GAFAm2wPUIYX52/yfyKJY9p5+mJuxCzaEB/k3ABwB9f81AVtIYTw
> lY+3FQW+lnR+W8HtGdoBzdNAOeayRfHAkOEvvTe2eDz0hD7nppvn3psii+5bpOAq
> o6NRxlz9bXOITZOTSh/NE6LCO7rDam/n3ufbmuxOa453E4bn91zSe7NoLNKU+6pG
> Dj31aRVoNnRxgEdMuZ2rYgVBXntuB2GRYw0h8F9vXWhl8YO0NmYmCUTB6AFjJq4f
> YGE+CBMKEKDBH3QDlQuejDM/FHRYprC5lvIfkbIP2CfClRNNeVRCmxxns0uZbUbj
> mBn3pbZQmi9ZIZF8lMzTYk4ZwIb61BkU8k4OA7swkcXUAtFMKFkA2MOkelFUrlBw
> 1vwTaHdzFT0uG7H/GszPgj5RT4n4bSazuPj1yAwg8TXcoy2tikSPkYU3mnS50MPA
> EY17KAKZx8k5GeJSMYs+
> =jUqV
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Dean Willis <[email-masked]>
Date: Fri, 7 Dec 2012 21:55:03 -0600

> SASLprep is based on a 10 year old version of unicode and does not provide a reasonable forward compatible way to update the mapping tables for embedded devices. I'd rather not tie ourselves to an…

Ekr, Cullen and I discussed this one on a call today.

Our current proposal is to say that passwords are binary objects in RELOAD base, but that applications using RELOAD either MAY or SHOULD define string prep profiles appropriate to the application.

Can we live with some variation of that?

--
Dean