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

Marc Petit-Huguenin <petithug@acm.org> Wed, 05 December 2012 16:20 UTC

Return-Path: <petithug@acm.org>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5321B21F8CB2 for <p2psip@ietfa.amsl.com>; Wed, 5 Dec 2012 08:20:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWT0n9yCWH9u for <p2psip@ietfa.amsl.com>; Wed, 5 Dec 2012 08:20:16 -0800 (PST)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6013721F8CBC for <p2psip@ietf.org>; Wed, 5 Dec 2012 08:20:16 -0800 (PST)
Received: from [IPv6:2601:9:4b80:32:9da0:5002:170d:49cb] (unknown [IPv6:2601:9:4b80:32:9da0:5002:170d:49cb]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6518D20451; Wed, 5 Dec 2012 16:20:14 +0000 (UTC)
Message-ID: <50BF7442.4010103@acm.org>
Date: Wed, 05 Dec 2012 08:20:18 -0800
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
References: <5AF341E0-FFB9-44DA-A9A5-FBF004F5F4E4@softarmor.com> <7FBFACAB-BEC8-471B-8CDB-76E6483F4575@softarmor.com> <50BF6112.60008@acm.org> <C5E08FE080ACFD4DAE31E4BDBF944EB11327BBBB@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB11327BBBB@xmb-aln-x02.cisco.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "<p2psip@ietf.org>" <p2psip@ietf.org>, Dean Willis <dean.willis@softarmor.com>
Subject: Re: [P2PSIP] RELOAD Base issue: stringprep of password
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Dec 2012 16:20:21 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/05/2012 07:44 AM, Cullen Jennings (fluffy) wrote:
> 
> no one does it for TURN as far as I can tell and I am strongly against 
> adding this.

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 <petithug@acm.org> wrote:
> 
> 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: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

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
-----END PGP SIGNATURE-----