From petithug@acm.org Wed Dec 5 06:58:26 2012 Return-Path: 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 3CFD021F8C14 for ; Wed, 5 Dec 2012 06:58:26 -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 R1-oehykgep0 for ; Wed, 5 Dec 2012 06:58:25 -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 3337A21F8C13 for ; Wed, 5 Dec 2012 06:58:24 -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 079B3200D1; Wed, 5 Dec 2012 14:58:22 +0000 (UTC) Message-ID: <50BF6112.60008@acm.org> Date: Wed, 05 Dec 2012 06:58:26 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 To: Dean Willis References: <5AF341E0-FFB9-44DA-A9A5-FBF004F5F4E4@softarmor.com> <7FBFACAB-BEC8-471B-8CDB-76E6483F4575@softarmor.com> In-Reply-To: <7FBFACAB-BEC8-471B-8CDB-76E6483F4575@softarmor.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , p2psip@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 14:58:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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) 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 fluffy@cisco.com Wed Dec 5 07:44:34 2012 Return-Path: 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 23F7421F8CC2 for ; Wed, 5 Dec 2012 07:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 np3wG73FpWiJ for ; Wed, 5 Dec 2012 07:44:32 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 189EE21F8CBF for ; Wed, 5 Dec 2012 07:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2898; q=dns/txt; s=iport; t=1354722272; x=1355931872; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=C+Ry43VpOKT/XiTNCcLbv20U3UgUV/B1CJr7fWLu3ZU=; b=TiyJgtDUreYX/VVdB/zKMbVOdmJofD2ovemXZcrrfEQd+7YB6bsQHMfS 1zPhhymDLvoiiJDdSdmup+sW94qUYYKIgdHoxQxRgVKpXZDqonfE/kqDg gRAvPfTW+GTn9l9TxUoj4xippL0WAeVAhZ0MJS9eF9V9dfVsh4hLHTW6l A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG5rv1CtJXG9/2dsb2JhbABEvisWc4IeAQEBBDo/EAIBCBgKDgYQMiUCBA4FCIgIDMI2jDcLgRGCRGEDlx+PK4JygWw1 X-IronPort-AV: E=McAfee;i="5400,1158,6916"; a="149668205" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 05 Dec 2012 15:44:31 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB5FiVss030941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 15:44:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 09:44:31 -0600 From: "Cullen Jennings (fluffy)" To: Marc Petit-Huguenin Thread-Topic: [P2PSIP] RELOAD Base issue: stringprep of password Thread-Index: AQHN0vj5slwmpFKtnUCtd7ui5FfaupgKvXcA Date: Wed, 5 Dec 2012 15:44:31 +0000 Message-ID: References: <5AF341E0-FFB9-44DA-A9A5-FBF004F5F4E4@softarmor.com> <7FBFACAB-BEC8-471B-8CDB-76E6483F4575@softarmor.com> <50BF6112.60008@acm.org> In-Reply-To: <50BF6112.60008@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Dean Willis 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 15:44:34 -0000 no one does it for TURN as far as I can tell and I am strongly against addi= ng this. On Dec 5, 2012, at 7:58 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > SASLprep should be mandatory. >=20 > 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. >=20 > 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 >>=20 >>=20 >> Peter says: >>=20 >> As to the charset issue, it seems safest to specify that the charset mus= t >> be UTF-8 (we don't want to end up with something like charset=3Dwindows-= 1250 >> as in Section 4.5 of RFC 2388). >>=20 >> As to preparation of usernames and passwords, it seems safest right now = to=20 >> say that these strings shall be prepared in accordance with SASLprep (RF= C=20 >> 4013) prior to comparison -- see RFC 4616 for text you could borrow. >>=20 >> [Eventually, perhaps even relatively soon in "RELOAD years", RFC 4013 wi= ll >> be obsoleted by draft-melnikov-precis-saslprepbis; however, you might >> prefer not to gate RELOAD on output from the PRECIS WG.] >>=20 >>=20 >>=20 >> On Nov 9, 2012, at 10:30 AM, Dean Willis wrote: >>=20 >>>=20 >>> AD comment: >>>=20 >>> Section 11.3: What character set is allowed for passwords? What if=20 >>> something is URL escaped - what's going to match? I'm sure you can copy= =20 >>> from somewhere else, not quite sure what's best though. >>>=20 >>>=20 >>> 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? >>>=20 >=20 > - --=20 > 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) >=20 > 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 > =3DnOOr > -----END PGP SIGNATURE----- From petithug@acm.org Wed Dec 5 08:20:21 2012 Return-Path: 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 ; 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 ; 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 ; 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 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)" References: <5AF341E0-FFB9-44DA-A9A5-FBF004F5F4E4@softarmor.com> <7FBFACAB-BEC8-471B-8CDB-76E6483F4575@softarmor.com> <50BF6112.60008@acm.org> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" , Dean Willis 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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----- From petithug@acm.org Wed Dec 5 08:22:51 2012 Return-Path: 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 CB7C821F8C04 for ; Wed, 5 Dec 2012 08:22:50 -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 asbDl+0BYfhN for ; Wed, 5 Dec 2012 08:22:48 -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 8CFDA21F880C for ; Wed, 5 Dec 2012 08:22:48 -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 0047420451; Wed, 5 Dec 2012 16:22:46 +0000 (UTC) Message-ID: <50BF74DB.5070004@acm.org> Date: Wed, 05 Dec 2012 08:22:51 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 To: Dean Willis References: <8E9109CB-EC93-4788-9172-8767C1AA9DB5@softarmor.com> <800552DE-B535-4C7C-9945-F421D3779C9A@softarmor.com> In-Reply-To: <800552DE-B535-4C7C-9945-F421D3779C9A@softarmor.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , p2psip@ietf.org Subject: Re: [P2PSIP] RELOAD Base: Question on certificate renewal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:22:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/14/2012 02:44 PM, Dean Willis wrote: > > On Nov 9, 2012, at 10:37 AM, Dean Willis wrote: > >> AD asks: >> >> How is node key rollover done? Do I loose all stored data? I think you >> need to make all those clear. >> >> >> >> So, what I think we're talking about is what happens to my data when my >> certificate expires. >> >> Does my NodeID change? >> >> Is there a way to re-cert my stored data? >> >> What exactly is the process for refreshing the data I have stored? >> >> -- Dean >> > > > I met with Cullen and EKR today, and here's what I think we have: > > If the NodeID cert expires, you lose all data stored with that NodeID. If > we want to invent a "recertification" technique (Marc suggested that the CA > can issue a new cert with the same NodeID) we can do that in a separate > document. > > We will need to add a clarifying sentence to the draft. > My suggestion was not about "recertification" - I think that the current mechanism, which is to resend the data signed with the new certificate is OK for now. What I was talking about is the unfinished discussion from Vancouver, on how to renew a certificate so the Node-ID(s) previously allocated do not change when the certificate is renewed. The spec currently uses a server side mechanism to "remember" the Node-IDs (which can be storage based or, as EKR suggested in Vancouver, hash based). The problem I see with this is the requirement that there is only one certificate per account, which can make things difficult for example if a user has multiple devices (with a device possibly hosting multiple nodes) but only one account. The user can request a multiple Node-ID certificate, but has to find a way to know which Node-ID(s) goes into which devices. My proposal was to use the previous certificate instead of the CSR when requesting a renewal. Because requesting a certificate with a CSR would return a different set of Node-IDs each time, a single account can be used on multiple devices. IMO that makes things easier for the client (can manage multiple devices from the same account) and for the server (no need to "remember" anything). - -- 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) iQIcBAEBCAAGBQJQv3TZAAoJECnERZXWan7EvKQP/Rku7EgsBa1eqt+HVY/Pda0c 9+IWpvkcsP8c/78TzKMBLBlcnSWMxOLAFODTGJdItr1y+SriQgtY3KWf+kUksDi8 7WRvGHlez6QpXth1VvZZf2XKXKhIqtSezAXw8S7Q+uqaBMOST+GKgeIflqqxp1HU t61SJBDYbJSL6nbb8F9rVT/D2Mg++LVFmp75tCJQWesnSmbzAY8w5mAJZz5zERiK DiHBBm4+KDgjra+cLqv7WWOtp+smNoIKFk3tcakn0y99ACX3dZM1Whh4wtwvnAy4 YaF/V4iMkKy7oIOiP8e+zHM/Wojh4aSGAZoq9H0MiT+m8UpSfwMwOHBXSyBPrekt djPOuybWbCL9abZlW5/8OLgIdYmusgAepTMUg+/1hTDUizDX8sBFGdi9a1Ubj+aq XTCf3+kBAlFxvG13dYbSzs+apMLAADu+TVhWLEQHIVZQEh7zj+/0w70OIpawWEyb SGCXlSWO1YJdqza/TJmSQDCo75xqAyPP4PStC4OmV18S+m9h+9K++HjZWDZk1Xrq mXCACPYUQFU8M0jCrtoDgMTwKfQNo7m2Cl05AC70qCS29pv65F4OamdLqzoONTqT DezePwdVnjgq/LLGsQWXzcQryh9z2nmn+T8tw7FvIWD5R+t9MfvQgBqhvIKFZPWn UO55eSvLqH5iN8Yk4rCT =brcP -----END PGP SIGNATURE----- From petithug@acm.org Wed Dec 5 08:42:31 2012 Return-Path: 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 2A33421F885A for ; Wed, 5 Dec 2012 08:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 47DjSBAMEpvd for ; Wed, 5 Dec 2012 08:42:27 -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 DAD4021F87D7 for ; Wed, 5 Dec 2012 08:42:26 -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 8DAF620451; Wed, 5 Dec 2012 16:42:25 +0000 (UTC) Message-ID: <50BF7975.1080407@acm.org> Date: Wed, 05 Dec 2012 08:42:29 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 To: Dean Willis References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , p2psip@ietf.org Subject: Re: [P2PSIP] RELOAD Base: Reference to Certificates X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 16:42:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/16/2012 11:41 AM, Dean Willis wrote: > > AD asks: > > (12) section 7: I don't see how to send a reference to a certificate - > 5.3.4 doesn't seem to allow for that now - wouldn't you need a new > CertificateType for that? > > By a reference you mean, e.g., a URL? > > Yeah a URL could be an example. The text says you can send a reference to > the cert but I don't see a field where I can put e.g. a URL "thus avoiding > the need to send a certificate" as it says. > > Ekr noted: This appears to be a real defect. I think it's a version skew > problem. The certificate indicators are hashes, so how does this work? > > EKR responded 6/8/12 > https://www.ietf.org/mail-archive/web/p2psip/current/msg06225.html > > In principle the SecurityBlock structure is designed to work with > certificates which are stored in the overlay and then retrieved at > verification time. In practice, however, the certificates are indexed into > the security block by Hash(cert) but stored in the overlay under subject, > so you can't retrieve them from the overlay. > > There seem to be two fixes for this: (1) Modify(add to?) the certificate > store usage to store certs under the fingerprint so they can be retrieved. > (2) Stop claiming that you can fetch the certs and just say that for this > version you must send the certs with the message. > > Is anyone interested in not sending all the certs with the message? If so, > we should do (1). Otherwise, we should do (2). > > > Okay folks? Which do we do? I support (2) - -- 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) iQIcBAEBCAAGBQJQv3lwAAoJECnERZXWan7E/gwQAISM7x7hXU2eBUUCDATGvPyA LTOdaLGL0TaFOwJd0zC9cc50QQPAJNhkMmLMtUbfLntxIodqALbg8YR+VPUxQM91 ejJ6F1kvPw7qvwSkponqntGvwNDtpzSniHxCuXvBtkfV367qx0nradeeiVsWf/ob We42NR7sbEp8Y9PdNQR1KY5l2Ke20Gvj3mZR4c3qpboN3gBaHUbSWMazYiECubl4 xmuJvhxD24VFeiBL9Tl4MNwjX/wtYsFcUDLoFtBKcn7d4vAB1D9XSMmRyADJ4tVU oNyJ6Kdry8OvdPb8iDA7nQKYexUy3Lnk9hW0ws92aOGtUboUyD1sP0+rhO3lOmKC 6wx5/k8ku5mAn66cf3FnL+x4ehsqVcobGKKLF7OkrQXaqRJZWYOBN1rKBJ6+NqFo ik5c0syhGC7C/gwQtCDiaQBf3MNiCJ22Humg/vlFzPIJuR9cEOj9aFWJcouOHBEF NkhpJZHve0Q4vAx7mKk2NHh/eN5GlZSWOt5VacvlCGyBOK+NJQqP+pJn6VDN8BVn 4zpb6qSwyfTChSPbcKa8DDH57N8iJOOtspoyL+9HW0SBGxOBKkBAuZUD3xp7Q3LF QNF4qgZyLVlR4bPLoqnzDtI1iXIB0Q5ePjf5YpNsHcmY60EVjBBN1hMHHznRSO6i g19EdXM11iE10ZlAdfuu =ZNUM -----END PGP SIGNATURE----- From fluffy@cisco.com Wed Dec 5 10:11:11 2012 Return-Path: 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 E7CF021F8BA9 for ; Wed, 5 Dec 2012 10:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 UPPte1zw723z for ; Wed, 5 Dec 2012 10:11:10 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 515FF21F8BA6 for ; Wed, 5 Dec 2012 10:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4053; q=dns/txt; s=iport; t=1354731070; x=1355940670; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=or9OkkTit8iiY+1vn/EIWsZ7SI5EjYrMSxlJJuByFPg=; b=gKE6OsPm3W6zK+GegeO3UFXwFcvJs9HVE1tQXqPcVsE/fFoxnfQk3VxW PlA5LMdogok/oQL1ISRT6wrlvIL8SZvZbC7Q6wI2DyFSnxf65tUxY2he9 sDHeES9O+yc1GKnh3KIyFs6HRKoi55Qu3v+L1E/a5uKQ6mVoVZLl58L0r g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALaNv1CtJV2a/2dsb2JhbABEviQWc4IeAQEBBAEBATc0CxACAQgYCg4GECcLJQIEDgUIiAgMwlOMNwuBEYJEYQOXH48rgnKBbDU X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149774643" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 05 Dec 2012 18:11:09 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB5IB9St005540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 18:11:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 12:11:09 -0600 From: "Cullen Jennings (fluffy)" To: Marc Petit-Huguenin Thread-Topic: [P2PSIP] RELOAD Base issue: stringprep of password Thread-Index: AQHN0xPmHYjnPEX4CEGfyLCkvv5VEQ== Date: Wed, 5 Dec 2012 18:11:09 +0000 Message-ID: References: <5AF341E0-FFB9-44DA-A9A5-FBF004F5F4E4@softarmor.com> <7FBFACAB-BEC8-471B-8CDB-76E6483F4575@softarmor.com> <50BF6112.60008@acm.org> <50BF7442.4010103@acm.org> In-Reply-To: <50BF7442.4010103@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] Content-Type: text/plain; charset="us-ascii" Content-ID: <14B09BE5236EF14AB976E7BB9446ED02@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Dean Willis 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 18:11:12 -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 embedd= ed 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 goin= g 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 pl= ace were for now we can just use characters that are not a problem.=20 On Dec 5, 2012, at 9:20 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 12/05/2012 07:44 AM, Cullen Jennings (fluffy) wrote: >>=20 >> no one does it for TURN as far as I can tell and I am strongly against=20 >> adding this. >=20 > The implementation I wrote during the development of TURN - AFAIK still > in use at 8x8 - implements SASLprep. As is the one I developed after thi= s. >=20 >>=20 >> On Dec 5, 2012, at 7:58 AM, Marc Petit-Huguenin wrote= : >>=20 >> SASLprep should be mandatory. >>=20 >> SASLprep is already mandatory for TURN (through RFC 5389), so it is not = a=20 >> big deal for an implementer to use it also for the enrollment server. >>=20 >> On 11/14/2012 11:35 AM, Dean Willis wrote: >>>>> Cullen, Ekr and I discussed this today, and Cullen solicited input=20 >>>>> from Peter Saint-Andre >>>>>=20 >>>>>=20 >>>>> Peter says: >>>>>=20 >>>>> As to the charset issue, it seems safest to specify that the charset= =20 >>>>> must be UTF-8 (we don't want to end up with something like=20 >>>>> charset=3Dwindows-1250 as in Section 4.5 of RFC 2388). >>>>>=20 >>>>> As to preparation of usernames and passwords, it seems safest right=20 >>>>> now to say that these strings shall be prepared in accordance with=20 >>>>> SASLprep (RFC 4013) prior to comparison -- see RFC 4616 for text you= =20 >>>>> could borrow. >>>>>=20 >>>>> [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.] >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Nov 9, 2012, at 10:30 AM, Dean Willis wrote: >>>>>=20 >>>>>>=20 >>>>>> AD comment: >>>>>>=20 >>>>>> Section 11.3: What character set is allowed for passwords? What if=20 >>>>>> something is URL escaped - what's going to match? I'm sure you can=20 >>>>>> copy from somewhere else, not quite sure what's best though. >>>>>>=20 >>>>>>=20 >>>>>> Since we're doing passwords in a POST form, I don't know that URL=20 >>>>>> escaping is an issue. Do we have other stringprep issues? Is there >>>>>> something we can crib from elsewhere for this spec? >>>>>>=20 >>=20 >>=20 >=20 > - --=20 > 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) >=20 > 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+ > =3DjUqV > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From dean.willis@softarmor.com Fri Dec 7 19:52:20 2012 Return-Path: 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 4030721F87C8 for ; Fri, 7 Dec 2012 19:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 6VbM68GileyP for ; Fri, 7 Dec 2012 19:52:19 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66ABC21F876B for ; Fri, 7 Dec 2012 19:52:19 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id r14so220459yen.31 for ; Fri, 07 Dec 2012 19:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=a8y7bTsC76CTpICvqpUNAqAAuBFFmS+mOD4TVpEtUg8=; b=Mj4csZu96IqSZI3Jrfy9b2Uah3Gm9lq6xHmtpxuUKqb9Fn3C/efX30hSTKYkV4/gEK BFVdqPRTDVWM5XXiIwo0jNEFzAPTQewPDH4LF5UbAdJ4iKUyRNqQzzn/DlL7waGaWuN4 wKW3K8g91+HGyYsHiSXp7EWpdXNiiWyuJ39as= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=a8y7bTsC76CTpICvqpUNAqAAuBFFmS+mOD4TVpEtUg8=; b=JyEDkAyHVj/pLF1vqrQQ9pSZBAyvvbOdLVnfdR4+jpLCjzyOW4hHJXcz3nTMHENGNM 4l8HWCeYIPhtcAA5tJxzciUM+sxmKptG5ivWH0T4Thw5z+nmyez7fb3fgPjjhETcOEeW IjtIaJYkURlM8WMmlSgX9jgJPO5ptL+FG+vlYSR3GodoN/fc5Awi22urv3mzEjVT2jo/ KLMYq0YjfHiimmRaCU0HJb9O82R15FX3OapHYZxZts8UENj71qDW2C3nPdDq/MUVD29f +bUgTWF/ZHyM+FQG2M6vMiNYi7P8pWKmNhswIkUgleLiREORrqPbG+A52wlVEmeNrpLu ZazA== Received: by 10.236.91.6 with SMTP id g6mr11116182yhf.67.1354938738504; Fri, 07 Dec 2012 19:52:18 -0800 (PST) Received: from [192.168.2.114] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPS id s19sm15031292anl.22.2012.12.07.19.52.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Dec 2012 19:52:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dean Willis In-Reply-To: <50BF74DB.5070004@acm.org> Date: Fri, 7 Dec 2012 21:52:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <003DCE50-5D27-44F7-BDCF-CF688DB974E9@softarmor.com> References: <8E9109CB-EC93-4788-9172-8767C1AA9DB5@softarmor.com> <800552DE-B535-4C7C-9945-F421D3779C9A@softarmor.com> <50BF74DB.5070004@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkXdGNIwF0c/UZp/FBYLH2Cie+7E35tMz+dRPYE6HqladORPmSOAdwDvsbDeNywQI7EE4RJ Cc: Cullen Jennings , p2psip@ietf.org Subject: Re: [P2PSIP] RELOAD Base: Question on certificate renewal X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 03:52:20 -0000 On Dec 5, 2012, at 10:22 AM, Marc Petit-Huguenin = wrote: >=20 > My suggestion was not about "recertification" - I think that the = current > mechanism, which is to resend the data signed with the new certificate = is OK > for now. What I was talking about is the unfinished discussion from > Vancouver, on how to renew a certificate so the Node-ID(s) previously > allocated do not change when the certificate is renewed. >=20 Well, that's what I was calling "recertification"; new vert, same = Node-ID. One could call it "certificate replacement", I suppose. > The spec currently uses a server side mechanism to "remember" the = Node-IDs > (which can be storage based or, as EKR suggested in Vancouver, hash = based). > The problem I see with this is the requirement that there is only one > certificate per account, which can make things difficult for example = if a user > has multiple devices (with a device possibly hosting multiple nodes) = but only > one account. The user can request a multiple Node-ID certificate, but = has to > find a way to know which Node-ID(s) goes into which devices. Maybe we should expand this discussion with some use cases. When would a = user need multiple devices? I personally only have a half-dozen or so = smartphone/tablet devices, three laptops, and a couple of server boxes. = Are those different users or different devices with one user? Jabber has = some disambiguation; each user-device binding gets a sub-name in the = space of the username. > My proposal was to use the previous certificate instead of the CSR = when > requesting a renewal. Because requesting a certificate with a CSR = would > return a different set of Node-IDs each time, a single account can be = used on > multiple devices. IMO that makes things easier for the client (can = manage > multiple devices from the same account) and for the server (no need to > "remember" anything). Logically, that seems ok to me as long as the previous cert hasn't yet = expired or been revoked. So it seems feasible to get a new cert for the = same node-IDs preemptively, but if you're offline and your cert expires, = you have to re-store everything with the new cert. That seems like an = acceptable limitation. An active peer node keeps its data from churning, = and a disconnected node churns more. Of course, a "disconnected but = connectable" client node could wake up, re-cert, and then go back to = sleep periodically without churning. But I'm not sure how to run OpenSSL's CA in such as way as to get a new = cert based on an old cert, without an intermediate CSR. How does that = work? -- Dean From dean.willis@softarmor.com Fri Dec 7 19:55:06 2012 Return-Path: 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 415DB21F88D9 for ; Fri, 7 Dec 2012 19:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ZvpFpiTnY7Km for ; Fri, 7 Dec 2012 19:55:05 -0800 (PST) Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB2921F88C6 for ; Fri, 7 Dec 2012 19:55:05 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id s35so245586yhf.27 for ; Fri, 07 Dec 2012 19:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Tmj82ywmEtu7v1W+j834A9FwBB7qWEHO84H9m4K9eD8=; b=TmKHQwvPelGW8Wf8qlKP6qzE88F0XlTLl/u485gkitA13dlafVkp6wSqpVuVqIC39U eGwI6+lSBa1m07PTIOIYhKC8gxKUH873+6HMFwtkuVJDkzhzqPWfZXy8Z//Cgc6Tr0Pk rwHiNH35Jr6VXxsXX1fzeWAYEysYqmsYmj6go= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Tmj82ywmEtu7v1W+j834A9FwBB7qWEHO84H9m4K9eD8=; b=A+MNSLCM8zGUZHtG6MBXs8X5iyUE7wy6mDX2GgJu9POWaksRh0lxAnBwhUQO824Xhj a8j5psxmf/RbdxZ4CCFEX+3z6YFP9fiz5moYjX1GcDPn5on7UTBqgdum5Ngx/0mLBm+i XiEWktQijTy5WeA01DYCtGWl4rgSK+dXikRZWSnb8cGxhGctIEll51Rj6NlhJzmzHCJ1 JcXQ2BxD2OIePMyrTvdtjrC7bcl26U0We375g3lDXfsAFO+GiMz4MVlnAJ3F0JdTcTXN 8lJPf+WOcrKVxLr8TRuQKKfd892yXBUPdWzevVUbcZ93h9SuhGwsVinQQ14JrFAMUxzu RD5w== Received: by 10.236.131.69 with SMTP id l45mr11160397yhi.46.1354938905081; Fri, 07 Dec 2012 19:55:05 -0800 (PST) Received: from [192.168.2.114] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPS id u22sm16274230yhl.2.2012.12.07.19.55.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Dec 2012 19:55:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dean Willis In-Reply-To: Date: Fri, 7 Dec 2012 21:55:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5AF341E0-FFB9-44DA-A9A5-FBF004F5F4E4@softarmor.com> <7FBFACAB-BEC8-471B-8CDB-76E6483F4575@softarmor.com> <50BF6112.60008@acm.org> <50BF7442.4010103@acm.org> To: "p2psip@ietf.org" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlEds8j15eiHYYr63nqWAlMmetziwnf6fEHq8xYrXFM3G9Ngk6RuUTQHkHSYyf/jjXhA20L Cc: "Cullen Jennings \(fluffy\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 03:55:06 -0000 On Dec 5, 2012, at 12:11 PM, Cullen Jennings (fluffy) = wrote: >=20 > 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.=20 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 From adamsobieski@hotmail.com Thu Dec 13 09:12:48 2012 Return-Path: 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 ABE2E21F85EA for ; Thu, 13 Dec 2012 09:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753] 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 smVGEfexhxjK for ; Thu, 13 Dec 2012 09:12:48 -0800 (PST) Received: from snt0-omc2-s32.snt0.hotmail.com (snt0-omc2-s32.snt0.hotmail.com [65.55.90.107]) by ietfa.amsl.com (Postfix) with ESMTP id D135321F855C for ; Thu, 13 Dec 2012 09:12:47 -0800 (PST) Received: from SNT002-W172 ([65.55.90.73]) by snt0-omc2-s32.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Dec 2012 09:12:47 -0800 X-Originating-IP: [174.100.43.136] X-EIP: [kGfiIjxPvjEo4ZEjpNKCO8D3SU6egpb6] X-Originating-Email: [adamsobieski@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_93cec164-5f11-4e29-b59c-0298d920a0f9_" From: Adam Sobieski To: "p2psip@ietf.org" Date: Thu, 13 Dec 2012 17:12:47 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 Dec 2012 17:12:47.0509 (UTC) FILETIME=[12D63C50:01CDD955] Subject: [P2PSIP] =?windows-1256?q?Peer-to-Peer_Multimedia_Answering_Machi?= =?windows-1256?q?ne_Technology=FE?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:12:48 -0000 --_93cec164-5f11-4e29-b59c-0298d920a0f9_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: base64 SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSwNClBlZXItdG8tUGVlciBTZXNzaW9uIElu aXRpYXRpb24gUHJvdG9jb2wgV29ya2luZyBHcm91cCwNCiANCkdyZWV0aW5ncy4gV2ViUlRDIGlz IGEgY29udGVtcG9yYXJ5IHRlY2hub2xvZ3kgYW5kIHBlcnRhaW5zIHRvIHZpZGVvIGNhbGxzLCBj b25mZXJlbmNlcywgYW5kIHBvdGVudGlhbGx5IHRvIHZpZGVvIGZvcnVtcy4gV2ViUlRDIGRvZXMg aW5jbHVkZSBQMlAgdGVjaG5vbG9naWVzIGFuZCBJIHdvdWxkIGxpa2UgdG8gZGVzY3JpYmUgYSBz Y2VuYXJpbyB3aXRoIHJlZ2FyZCB0byB0aGUgUDJQIGRpc3RyaWJ1dGVkIHN0b3JhZ2Ugb2YgaHlw ZXJ0ZXh0LCBhdWRpbyBhbmQgdmlkZW8gbWVzc2FnZXMsIHdpdGggZmVhdHVyZXMgYW5kIGZ1bmN0 aW9uYWxpdHkgZmFjaWxpdGF0aW5nIFAyUCBtdWx0aW1lZGlhIGFuc3dlcmluZyBtYWNoaW5lIHRl Y2hub2xvZ3kuDQoNClNjZW5hcmlvOg0KIA0KUGVyc29uIEEgY2FsbHMgUGVyc29uIEIuIFBlcnNv biBBIG1pZ2h0IGtub3cgd2hldGhlciBQZXJzb24gQiB3YXMgb25saW5lIG9yIG9mZmxpbmUgYmVm b3JlIHRoZXkgY29tbWVuY2VkIGEgY29tbXVuaWNhdGlvbiBhY3Rpdml0eS4gSWYgUGVyc29uIEIg aXMgb25saW5lLCB0aGUgZGF0YSBtb3Rpb24gaXMgYXMgcGVyIFdlYlJUQy4gSWYgUGVyc29uIEIg aXMgb2ZmbGluZSwgdGhleSBjb3VsZCBoYXZlIGFuIGFuc3dlcmluZyBtYWNoaW5lIG11bHRpbWVk aWEgY2xpcCBhdmFpbGFibGUgb24gYSBncm91cCBvZiBub2RlcyB3aGljaCB0aGV5IGhhdmUgZGVz aWduYXRlZCwgZm9yIGV4YW1wbGUgcGVyIGEgc29jaWFsIG5ldHdvcmsgZ3JhcGguDQoNClBlcnNv biBBIGNhbiB3YXRjaCBQZXJzb24gQidzIHN0cmVhbWluZyBhbnN3ZXJpbmcgbWFjaGluZSBjbGlw IG9yIHNraXAgdG8gbGVhdmluZyBhIG1lc3NhZ2UuIElmIFBlcnNvbiBBIGxlYXZlcyBhIG1lc3Nh Z2UsIHRoYXQgc3RyZWFtaW5nIHZpZGVvIG1lc3NhZ2UgaXMgc3RvcmVkIG9uIGEgZ3JvdXAgb2Yg bm9kZXMsIHBvc3NpYmx5IHRoZSB1bmlvbiBvZiB0aGUgdHdvIGdyb3VwcyBvZiBub2RlcyBkZXNp Z25hdGVkIGJ5IGJvdGggUGVyc29uIEEgYW5kIFBlcnNvbiBCLiBXaGVuIFBlcnNvbiBCIGNvbWVz IG9ubGluZSwgd2l0aGluIGEgc3lzdGVtLXNwZWNpZmljIGR1cmF0aW9uIG9mIHRpbWUsIGUuZy4g OTAgZGF5cyBvciAxIHllYXIsIHRoZSBwb3J0aW9ucyBvZiBkYXRhIGFyZSBkb3dubG9hZGVkIGJ5 IHRoZW0sIHNlZ21lbnRlZCBkb3dubG9hZGluZywgYW5kIHBvc3NpYmx5IHdpdGggc29tZXRoaW5n IGxpa2UgYSBCSVRTIDQuMCsgdGVjaG5vbG9neS4NCiANCklmIFBlcnNvbiBCIGNob29zZXMgdG8g dmlldyBhbnkgb2YgdGhlIHN0cmVhbWFibGUgbWVkaWEgZHVyaW5nIHRoYXQgaW5pdGlhbCBwaGFz ZSwgd2hpY2ggbWlnaHQgbm90IGJlIHVuY29tbW9uLCBhIGxvZyBvbiBhbmQgY2hlY2sgbWVzc2Fn ZXMgcGF0dGVybiwgdGhlIHNlZ21lbnRlZCBkb3dubG9hZGluZyBjYW4gdG9nZ2xlIHRvIGEgc3Ry ZWFtaW5nIHZhcmlldHkgb2YgZG93bmxvYWQsIGluY2x1ZGluZyB2YXJpYWJsZSBiaXRyYXRlIHN0 cmVhbWluZy4gRXZlbiBhZnRlciBQZXJzb24gQiBtaWdodCB3YXRjaCByZWFsLXRpbWUgc2VnbWVu dGVkIGRvd25sb2FkcyBvZiB2YXJpYWJsZS1iaXRyYXRlIHN0cmVhbWluZyBtdWx0aW1lZGlhLCB0 aGUgZW50aXJldHkgb2YgdGhlaXIgaGlnaC1iaXRyYXRlIG1lc3NhZ2VzIGNvdWxkIGJlIGRvd25s b2FkZWQgYW5kIHN0b3JlZCBieSBQZXJzb24gQiB1bmxlc3Mgb3IgdW50aWwgUGVyc29uIEIgaW5k aWNhdGVkIG90aGVyd2lzZS4NCg0KDQpWaWRlbyBjYWxsaW5nIGFuZCB2aWRlbyBjb25mZXJlbmNp bmcgaGF2ZSBiZWVuIGlsbHVzdHJhdGVkIHdpdGggV2ViUlRDIHRlY2hub2xvZ2llcywgdmlkZW8g Zm9ydW1zIG1heSBiZSByZWFsaXplZCB1cGNvbWluZywgYW5kIHdlIGNhbiBlbnZpc2lvbiwgcmVz ZWFyY2ggYW5kIGRldmVsb3AgZmVhdHVyZXMgZm9yIFAyUCB2aWRlbyBjb21tdW5pY2F0aW9uIHN5 c3RlbXMsIFAyUCBoeXBlcnRleHQsIGF1ZGlvIGFuZCB2aWRlbyBzeXN0ZW1zLCBtdWx0aW1lZGlh IHN5c3RlbXMsIGluY2x1ZGluZyBQMlAgYW5zd2VyaW5nIG1hY2hpbmUgdGVjaG5vbG9naWVzIGFz IGRlc2NyaWJlZC4NCg0KDQoNCktpbmQgcmVnYXJkcywNCg0KQWRhbSBTb2JpZXNraSAJCSAJICAg CQkgIA== --_93cec164-5f11-4e29-b59c-0298d920a0f9_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSw8 YnIvPg0KUGVlci10by1QZWVyIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCBXb3JraW5nIEdy b3VwLDxici8+DQo8YnIvPiANCkdyZWV0aW5ncy4gV2ViUlRDIGlzIGEgY29udGVtcG9yYXJ5IHRl Y2hub2xvZ3kgYW5kIHBlcnRhaW5zIHRvIHZpZGVvIGNhbGxzLCBjb25mZXJlbmNlcywgYW5kIHBv dGVudGlhbGx5IHRvIHZpZGVvIGZvcnVtcy4gV2ViUlRDIGRvZXMgaW5jbHVkZSBQMlAgdGVjaG5v bG9naWVzIGFuZCBJIHdvdWxkIGxpa2UgdG8gZGVzY3JpYmUgYSBzY2VuYXJpbyB3aXRoIHJlZ2Fy ZCB0byB0aGUgUDJQIGRpc3RyaWJ1dGVkIHN0b3JhZ2Ugb2YgaHlwZXJ0ZXh0LCBhdWRpbyBhbmQg dmlkZW8gbWVzc2FnZXMsIHdpdGggZmVhdHVyZXMgYW5kIGZ1bmN0aW9uYWxpdHkgZmFjaWxpdGF0 aW5nIFAyUCBtdWx0aW1lZGlhIGFuc3dlcmluZyBtYWNoaW5lIHRlY2hub2xvZ3kuPEJSPg0KPGJy Lz4NClNjZW5hcmlvOjxCUj4NCjxici8+IA0KUGVyc29uIEEgY2FsbHMgUGVyc29uIEIuIFBlcnNv biBBIG1pZ2h0IGtub3cgd2hldGhlciBQZXJzb24gQiB3YXMgb25saW5lIG9yIG9mZmxpbmUgYmVm b3JlIHRoZXkgY29tbWVuY2VkIGEgY29tbXVuaWNhdGlvbiBhY3Rpdml0eS4gSWYgUGVyc29uIEIg aXMgb25saW5lLCB0aGUgZGF0YSBtb3Rpb24gaXMgYXMgcGVyIFdlYlJUQy4gSWYgUGVyc29uIEIg aXMgb2ZmbGluZSwgdGhleSBjb3VsZCBoYXZlIGFuIGFuc3dlcmluZyBtYWNoaW5lIG11bHRpbWVk aWEgY2xpcCBhdmFpbGFibGUgb24gYSBncm91cCBvZiBub2RlcyB3aGljaCB0aGV5IGhhdmUgZGVz aWduYXRlZCwgZm9yIGV4YW1wbGUgcGVyIGEgc29jaWFsIG5ldHdvcmsgZ3JhcGguPEJSPg0KPGJy Lz4NClBlcnNvbiBBIGNhbiB3YXRjaCBQZXJzb24gQidzIHN0cmVhbWluZyBhbnN3ZXJpbmcgbWFj aGluZSBjbGlwIG9yIHNraXAgdG8gbGVhdmluZyBhIG1lc3NhZ2UuIElmIFBlcnNvbiBBIGxlYXZl cyBhIG1lc3NhZ2UsIHRoYXQgc3RyZWFtaW5nIHZpZGVvIG1lc3NhZ2UgaXMgc3RvcmVkIG9uIGEg Z3JvdXAgb2Ygbm9kZXMsIHBvc3NpYmx5IHRoZSB1bmlvbiBvZiB0aGUgdHdvIGdyb3VwcyBvZiBu b2RlcyBkZXNpZ25hdGVkIGJ5IGJvdGggUGVyc29uIEEgYW5kIFBlcnNvbiBCLiBXaGVuIFBlcnNv biBCIGNvbWVzIG9ubGluZSwgd2l0aGluIGEgc3lzdGVtLXNwZWNpZmljIGR1cmF0aW9uIG9mIHRp bWUsIGUuZy4gOTAgZGF5cyBvciAxIHllYXIsIHRoZSBwb3J0aW9ucyBvZiBkYXRhIGFyZSBkb3du bG9hZGVkIGJ5IHRoZW0sIHNlZ21lbnRlZCBkb3dubG9hZGluZywgYW5kIHBvc3NpYmx5IHdpdGgg c29tZXRoaW5nIGxpa2UgYSBCSVRTIDQuMCsgdGVjaG5vbG9neS48QlI+DQo8YnIvPiANCklmIFBl cnNvbiBCIGNob29zZXMgdG8gdmlldyBhbnkgb2YgdGhlIHN0cmVhbWFibGUgbWVkaWEgZHVyaW5n IHRoYXQgaW5pdGlhbCBwaGFzZSwgd2hpY2ggbWlnaHQgbm90IGJlIHVuY29tbW9uLCBhIGxvZyBv biBhbmQgY2hlY2sgbWVzc2FnZXMgcGF0dGVybiwgdGhlIHNlZ21lbnRlZCBkb3dubG9hZGluZyBj YW4gdG9nZ2xlIHRvIGEgc3RyZWFtaW5nIHZhcmlldHkgb2YgZG93bmxvYWQsIGluY2x1ZGluZyB2 YXJpYWJsZSBiaXRyYXRlIHN0cmVhbWluZy4gRXZlbiBhZnRlciBQZXJzb24gQiBtaWdodCB3YXRj aCByZWFsLXRpbWUgc2VnbWVudGVkIGRvd25sb2FkcyBvZiB2YXJpYWJsZS1iaXRyYXRlIHN0cmVh bWluZyBtdWx0aW1lZGlhLCB0aGUgZW50aXJldHkgb2YgdGhlaXIgaGlnaC1iaXRyYXRlIG1lc3Nh Z2VzIGNvdWxkIGJlIGRvd25sb2FkZWQgYW5kIHN0b3JlZCBieSBQZXJzb24gQiB1bmxlc3Mgb3Ig dW50aWwgUGVyc29uIEIgaW5kaWNhdGVkIG90aGVyd2lzZS48QlI+DQo8YnIvPg0KPGJyLz4NClZp ZGVvIGNhbGxpbmcgYW5kIHZpZGVvIGNvbmZlcmVuY2luZyBoYXZlIGJlZW4gaWxsdXN0cmF0ZWQg d2l0aCBXZWJSVEMgdGVjaG5vbG9naWVzLCB2aWRlbyBmb3J1bXMgbWF5IGJlIHJlYWxpemVkIHVw Y29taW5nLCBhbmQgd2UgY2FuIGVudmlzaW9uLCByZXNlYXJjaCBhbmQgZGV2ZWxvcCBmZWF0dXJl cyBmb3IgUDJQIHZpZGVvIGNvbW11bmljYXRpb24gc3lzdGVtcywgUDJQIGh5cGVydGV4dCwgYXVk aW8gYW5kIHZpZGVvIHN5c3RlbXMsIG11bHRpbWVkaWEgc3lzdGVtcywgaW5jbHVkaW5nIFAyUCBh bnN3ZXJpbmcgbWFjaGluZSB0ZWNobm9sb2dpZXMgYXMgZGVzY3JpYmVkLjxCUj4NCjxici8+DQo8 YnIvPg0KPGJyLz4NCktpbmQgcmVnYXJkcyw8YnIvPg0KPGJyLz4NCkFkYW0gU29iaWVza2kgCQkg CSAgIAkJICA8L2Rpdj48L2JvZHk+DQo8L2h0bWw+ --_93cec164-5f11-4e29-b59c-0298d920a0f9_-- From j.schneider@hs-mannheim.de Thu Dec 20 07:44:29 2012 Return-Path: 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 905EF21F8839 for ; Thu, 20 Dec 2012 07:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 iwJeIBfW4Tg3 for ; Thu, 20 Dec 2012 07:44:27 -0800 (PST) Received: from hs-mannheim.de (mailnode.rz.fh-mannheim.de [141.19.1.96]) by ietfa.amsl.com (Postfix) with ESMTP id AA66821F8830 for ; Thu, 20 Dec 2012 07:44:25 -0800 (PST) Received: from [141.19.96.81] (account schneiderj@hs-mannheim.de [141.19.96.81] verified) by hs-mannheim.de (CommuniGate Pro SMTP 5.3.15) with ESMTPSA id 18408327 for p2psip@ietf.org; Thu, 20 Dec 2012 16:42:55 +0100 Message-ID: <50D33258.1030802@hs-mannheim.de> Date: Thu, 20 Dec 2012 16:44:24 +0100 From: Joscha Schneider User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "p2psip@ietf.org" Content-Type: multipart/alternative; boundary="------------030103070306000500090205" Subject: [P2PSIP] RELOAD Prototype X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 15:44:29 -0000 This is a multi-part message in MIME format. --------------030103070306000500090205 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hello all, Just before Christmas we are pleased to announce a prototype RELOAD stack called RELOAD.NET available as open source. The stack originated from T-Systems in Darmstadt, Germany and has been extended by University of Applied Sciences in Hamburg and University of Applied Sciences in Mannheim. First and foremost, the stack is slightly behind the actual draft, some important features are missing and the further development depends on potential developers willing to put effort into the stack. The implementation is written in C# based on the .NET framework version 4.0. The source code is compiled to a library that allows using the stack as a C# assembly. RELOAD.NET is hosted on GitHub at: https://github.com/RELOAD-NET/RELOAD.NET The RELOAD.NET library implements all the layers as defined by the RELOAD architecture. This includes the Usage Layer allowing the implementation of further Usages and the Message Transport, which relies on the Chord algorithm that is implemented within the Topology Plugin. The Storage Layer has the ability to store all three mandatory data types (value, array, and dictionary). Further, the Forward and Link Management Layer uses the commercial Eldos Secure Black Box (SBB) library to realize the transport using TLS. Also, the SBB is used for the certificate handling. Although RELOAD.NET represents a rather advanced implementation, some requirements specified by the draft are missing. In particular, the implementation of the ICE connection establishment is missing. Also, the implemented message fragmentation isn't compliant to the draft. So far the documentation is lacking. For the basics we have set up a Wiki on GitHub: 1)Getting Started gives an overview how to set up the RELOAD.NET project using Visual Studio. https://github.com/RELOAD-NET/RELOAD.NET/wiki/Getting-Started 2)Running the Stack explains briefly how the stack is configured and a RELOAD peer started. https://github.com/RELOAD-NET/RELOAD.NET/wiki/Running-the-Stack 3)Open Topics will be used to list potential topics for further development. So far most important is the elimination of the proprietary SBB component. https://github.com/RELOAD-NET/RELOAD.NET/wiki/Open-Topics The stack's future depends highly on voluntary developers. We are aware of some constraints that aren't ideal for an open source project but we hope that enthusiastic developers might contribute to expedite the implementation. To set up a configuration and enrollment server we refer to the service of Marc Petit Huguenin: http://blog.marc.petit-huguenin.org/2012/08/a-configuration-and-enrollment-service.html For further information including GitHub push permissions please don't hesitate to contact me. Kind regards and Happy Holidays, Joscha Schneider University of Applied Sciences Mannheim Institute for Software Engineering and Computer Networks j.schneider@hs-mannheim.de --------------030103070306000500090205 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit

Hello all,

Just before Christmas we are pleased to announce a prototype RELOAD stack called RELOAD.NET available as open source.  The stack originated from T-Systems in Darmstadt, Germany and has been extended by University of Applied Sciences in Hamburg and University of Applied Sciences in Mannheim.

First and foremost, the stack is slightly behind the actual draft, some important features are missing and the further development depends on potential developers willing to put effort into the stack.

The implementation is written in C# based on the .NET framework version 4.0. The source code is compiled to a library that allows using the stack as a C# assembly.

RELOAD.NET is hosted on GitHub at:

https://github.com/RELOAD-NET/RELOAD.NET

The RELOAD.NET library implements all the layers as defined by the RELOAD architecture. This includes the Usage Layer allowing the implementation of further Usages and the Message Transport, which relies on the Chord algorithm that is implemented within the Topology Plugin. The Storage Layer has the ability to store all three mandatory data types (value, array, and dictionary). Further, the Forward and Link Management Layer uses the commercial Eldos Secure Black Box (SBB) library to realize the transport using TLS. Also, the SBB is used for the certificate handling.

Although RELOAD.NET represents a rather advanced implementation, some requirements specified by the draft are missing. In particular, the implementation of the ICE connection establishment is missing. Also, the implemented message fragmentation isn’t compliant to the draft.

So far the documentation is lacking. For the basics we have set up a Wiki on GitHub:

1)      Getting Started gives an overview how to set up the RELOAD.NET project using Visual Studio.

https://github.com/RELOAD-NET/RELOAD.NET/wiki/Getting-Started

2)      Running the Stack explains briefly how the stack is configured and a RELOAD peer started.

https://github.com/RELOAD-NET/RELOAD.NET/wiki/Running-the-Stack

3)      Open Topics will be used to list potential topics for further development. So far most important is the elimination of the proprietary SBB component.

https://github.com/RELOAD-NET/RELOAD.NET/wiki/Open-Topics

The stack’s future depends highly on voluntary developers. We are aware of some constraints that aren’t ideal for an open source project but we hope that enthusiastic developers might contribute to expedite the implementation.

To set up a configuration and enrollment server we refer to the service of Marc Petit Huguenin:

http://blog.marc.petit-huguenin.org/2012/08/a-configuration-and-enrollment-service.html

For further information including GitHub push permissions please don’t hesitate to contact me.

Kind regards and Happy Holidays,

Joscha Schneider

University of Applied Sciences Mannheim

Institute for Software Engineering and Computer Networks

j.schneider@hs-mannheim.de

--------------030103070306000500090205-- From petithug@acm.org Tue Dec 25 07:23:19 2012 Return-Path: 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 A763021F86E8 for ; Tue, 25 Dec 2012 07:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 G1DFom0E4wwm for ; Tue, 25 Dec 2012 07:23:14 -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 40F0721F86CC for ; Tue, 25 Dec 2012 07:23:14 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:1802:b2d6:ae:fa46] (unknown [IPv6:2601:9:4b80:32:1802:b2d6:ae:fa46]) (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 7764B20419; Tue, 25 Dec 2012 15:23:12 +0000 (UTC) Message-ID: <50D9C4E8.3020108@acm.org> Date: Tue, 25 Dec 2012 07:23:20 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 To: Joscha Schneider References: <50D33258.1030802@hs-mannheim.de> In-Reply-To: <50D33258.1030802@hs-mannheim.de> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] RELOAD Prototype X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 15:23:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Joscha, Congratulations on releasing this source code. I believe that, even more than for other Internet protocols, code diversity for RELOAD is an important foundation for resilient deployments. May I suggest that you repost this in the RELOAD implementers[1] mailing-list? I have some questions on your implementation that are probably off-topic here. Thanks. [1] http://implementers.org/mailman/listinfo/reload On 12/20/2012 07:44 AM, Joscha Schneider wrote: > Hello all, > > Just before Christmas we are pleased to announce a prototype RELOAD stack > called RELOAD.NET available as open source. The stack originated from > T-Systems in Darmstadt, Germany and has been extended by University of > Applied Sciences in Hamburg and University of Applied Sciences in > Mannheim. > > First and foremost, the stack is slightly behind the actual draft, some > important features are missing and the further development depends on > potential developers willing to put effort into the stack. > > The implementation is written in C# based on the .NET framework version > 4.0. The source code is compiled to a library that allows using the stack > as a C# assembly. > > RELOAD.NET is hosted on GitHub at: > > https://github.com/RELOAD-NET/RELOAD.NET > > The RELOAD.NET library implements all the layers as defined by the RELOAD > architecture. This includes the Usage Layer allowing the implementation of > further Usages and the Message Transport, which relies on the Chord > algorithm that is implemented within the Topology Plugin. The Storage Layer > has the ability to store all three mandatory data types (value, array, and > dictionary). Further, the Forward and Link Management Layer uses the > commercial Eldos Secure Black Box (SBB) library to realize the transport > using TLS. Also, the SBB is used for the certificate handling. > > Although RELOAD.NET represents a rather advanced implementation, some > requirements specified by the draft are missing. In particular, the > implementation of the ICE connection establishment is missing. Also, the > implemented message fragmentation isn’t compliant to the draft. > > So far the documentation is lacking. For the basics we have set up a Wiki > on GitHub: > > 1) Getting Started gives an overview how to set up the RELOAD.NET > project using Visual Studio. > > https://github.com/RELOAD-NET/RELOAD.NET/wiki/Getting-Started > > 2) Running the Stack explains briefly how the stack is configured and > a RELOAD peer started. > > https://github.com/RELOAD-NET/RELOAD.NET/wiki/Running-the-Stack > > 3) Open Topics will be used to list potential topics for further > development. So far most important is the elimination of the proprietary > SBB component. > > https://github.com/RELOAD-NET/RELOAD.NET/wiki/Open-Topics > > The stack’s future depends highly on voluntary developers. We are aware of > some constraints that aren’t ideal for an open source project but we hope > that enthusiastic developers might contribute to expedite the > implementation. > > To set up a configuration and enrollment server we refer to the service of > Marc Petit Huguenin: > > http://blog.marc.petit-huguenin.org/2012/08/a-configuration-and-enrollment-service.html > > > > For further information including GitHub push permissions please don’t > hesitate to contact me. > > Kind regards and Happy Holidays, > > Joscha Schneider > > University of Applied Sciences Mannheim > > Institute for Software Engineering and Computer Networks > > j.schneider@hs-mannheim.de > > - -- 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) iQIcBAEBCAAGBQJQ2cTkAAoJECnERZXWan7EXxsQAOGqxgSQD1E9MzhPvpmKIdSw Ob6+gowtIokdKNqzgaixJLeWaMvtMwa31YAfxxz7gIC3mc3ZnSrmVEax5moGWiys EHCgwNN3KUgM1o+esxYeibNMfCz4UuyxHlq1oCXG4Gj9gqtq6eeugKptHqUYubLH n9ypOZshl+5mz1ZuAWDMo21ZGqd9x048dI6FRutPJCRpmEgMl6wu4hMVxd5SY4xG AiFRn1Z6aS36TYn5VOmOuAAe8m5PhNLoCqf0B3MOzIQpc/xucUq63/iE/E+5keV5 jY1kpssov8bvzjwTW2IJQpbZu2DcJKUULo5mEDlzzRrLOm+gE8gL8Lc1GSdc9WqW Prj5mo/k+GjrCkLoXQRKeBKiJoch2iMTvkHzAg2QgkQv59e/Zil/q+jAmiKT4SoZ +sX0NI7ViWGggZPj4jxyNrE+lc5UG26yzJ/I+fEjUwNGMw6a7jfl/o6IOwvbrpk7 V5/hQKOoBAuhGOZgitiiGDw/QlcovMeB7PHssXPh1AunTzXrIaWjjmxxkugWyDVx 9TSAQOoyNNxAtM0oUzjq8gG4EfOTFvKepJtDVuCAmq77zNYlPZWV63jnrsJuGuRG KY0UopdyARZbOKiVfo27mCB582W6lRo7jkQOUZhVgstmh2C/00m2QnOkN1hfWUiO PQrnTA0nIwKAMgZuo8xF =J+8j -----END PGP SIGNATURE----- From petithug@acm.org Fri Dec 28 09:21:19 2012 Return-Path: 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 D1DD221F8D22 for ; Fri, 28 Dec 2012 09:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, 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 0tAlUA6vK+f3 for ; Fri, 28 Dec 2012 09:21:12 -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 8BC9721F88A9 for ; Fri, 28 Dec 2012 09:21:10 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:e9d8:779d:3493:4d8a] (unknown [IPv6:2601:9:4b80:32:e9d8:779d:3493:4d8a]) (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 DE44B20419; Fri, 28 Dec 2012 17:21:08 +0000 (UTC) Message-ID: <50DDD50D.2070703@acm.org> Date: Fri, 28 Dec 2012 09:21:17 -0800 From: Marc Petit-Huguenin 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 , Eric Rescorla X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "p2psip@ietf.org" , Dean Willis Subject: [P2PSIP] Invalid vs reserved in draft-ietf-p2psip-base-23 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 17:21:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, In base-23, the value "0" in most registries is assigned the label "invalid", but in the text itself the same value is assigned the label "reserved" or a label derived from "reserved". Now "reserved" and "invalid" are not synonymous. "reserved" carries the idea that this may be redefined in the future (for example to extend the size), where "invalid" has a more definitive connotation. It does not matter for interoperability purpose yet, but it would be nice if the two definitions would match. So, which label is the correct one for values 0? "invalid" or "reserved"? Thanks. - -- 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) iQIcBAEBCAAGBQJQ3dT9AAoJECnERZXWan7EXz8QAM9+JIFljevZSv6EnMI91AyZ GUO1gtPk2VdMcbok9enTRnX4W90vql9dF2V+TK6z2EdOO/Hb2Zn4n5ClM0uPZ5V+ 0cpBaV8BJ5AncDRZdgcsgZHkr9IR7F60CQ6mNFSFLG/ZIiDD3JJ/JfQLZxv9aI4R hFAzSdivseuLDKPAO92k8hCcalBYC55IGBpxQeXwi3Eduva8XMUfRVxK2U1uftUZ +JFvODhGdYNhtuzDwHpBBjZ9JBjUFfY0b7jwry3bDGFK2FofJpkXJ3YU5B1LJRrU LCOaaLSonn4URbL20bJUKN+iSbc0beQw7I56UN+8eUcoV+kkgYNTC7eOQS2Jyjki Eif+5opV/Nvn7FlcSPVwdCgGmYQJNJLCAXJXVqbuzhW1fPDh6wE2xXQ/lTphG/Vx UUaI3daLm28kNLKP2rd9uFMo6+o2IaBbXIH3V6AKdXHxlGq12bxKYPvAbmNEIy3N Hg7azleq6kEM07SylnjahHgBmxAr/hSl52REj/OshW+W71bMlPjU2oZHLZsuYX7C +WAJLOEX7ZAo9UwrQJc8ATLkKHm09xN+pXwO99AfbwfZQF/rFdVNVYYKsCaHJY0i SSRgJO1cxsEgkOwgQ+QF+fe9FpMWhhxjfoz9uttZE7DhuopDpA9ebLFlYlyAj3bU n7I2TthSAJvJluPdufIq =Hos6 -----END PGP SIGNATURE----- From internet-drafts@ietf.org Sun Dec 30 02:59:28 2012 Return-Path: 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 D28ED21F894C; Sun, 30 Dec 2012 02:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, 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 yBubMqQPajNS; Sun, 30 Dec 2012 02:59:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2159D21F8947; Sun, 30 Dec 2012 02:59:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121230105928.32328.50295.idtracker@ietfa.amsl.com> Date: Sun, 30 Dec 2012 02:59:28 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-sip-08.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 10:59:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Protocol = Working Group of the IETF. Title : A SIP Usage for RELOAD Author(s) : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Thomas C. Schmidt Filename : draft-ietf-p2psip-sip-08.txt Pages : 17 Date : 2012-12-30 Abstract: This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service for Address of Records (AoRs) stored in the overlay. It also defines Globally Routable User Agent Uris (GRUUs) that allow the registrations to map an AoR to a specific node reachable through the overlay. After such initial contact of a peer, the AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-sip-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-sip-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=70465e669=schmidt@informatik.haw-hamburg.de Sun Dec 30 05:08:59 2012 Return-Path: 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 A217E21F8980 for ; Sun, 30 Dec 2012 05:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 5r4qnHCxzAgV for ; Sun, 30 Dec 2012 05:08:58 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 31FDD21F897E for ; Sun, 30 Dec 2012 05:08:57 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 30 Dec 2012 14:08:52 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 0DD791064E02 for ; Sun, 30 Dec 2012 14:08:52 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14392-06 for ; Sun, 30 Dec 2012 14:08:51 +0100 (CET) Received: from [192.168.178.36] (e178063203.adsl.alicedsl.de [85.178.63.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 834971064E01 for ; Sun, 30 Dec 2012 14:08:51 +0100 (CET) Message-ID: <50E03CE8.7020907@informatik.haw-hamburg.de> Date: Sun, 30 Dec 2012 14:08:56 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: p2psip@ietf.org References: <20121230105928.32328.13827.idtracker@ietfa.amsl.com> In-Reply-To: <20121230105928.32328.13827.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121230105928.32328.13827.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Subject: [P2PSIP] Fwd: New Version Notification for draft-ietf-p2psip-sip-08.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 13:08:59 -0000 Hi all, we've updated the draft "SIP USAGE" with the aim of addressing all issues as discussed in the Atlanta meeting. Changes since draft-ietf-p2psip-sip-07 in detail: o Cleared open issues o Clarified use cases after WG discussion o Added configuration document extensions for configurable domain names o Specified format of contact_prefs o Clarified routing to AORs o Extended security section o Added Appendix on Third Party Registration o Added IANA code points o Editorial polishing o Updated and extended references I guess we all want to progress the document side by side with the base spec. So please feel encouraged to read and review! Cheers & best wishes for 2013 Thomas -------- Original Message -------- Subject: New Version Notification for draft-ietf-p2psip-sip-08.txt Date: Sun, 30 Dec 2012 02:59:28 -0800 From: internet-drafts@ietf.org To: schmidt@informatik.haw-hamburg.de CC: fluffy@cisco.com, ekr@rtfm.com, bbl@lowekamp.net, salman@cs.columbia.edu, hgs@cs.columbia.edu A new version of I-D, draft-ietf-p2psip-sip-08.txt has been successfully submitted by Thomas C. Schmidt and posted to the IETF repository. Filename: draft-ietf-p2psip-sip Revision: 08 Title: A SIP Usage for RELOAD Creation date: 2012-12-30 WG ID: p2psip Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-sip-08.txt Status: http://datatracker.ietf.org/doc/draft-ietf-p2psip-sip Htmlized: http://tools.ietf.org/html/draft-ietf-p2psip-sip-08 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-sip-08 Abstract: This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service for Address of Records (AoRs) stored in the overlay. It also defines Globally Routable User Agent Uris (GRUUs) that allow the registrations to map an AoR to a specific node reachable through the overlay. After such initial contact of a peer, the AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. The IETF Secretariat From petithug@acm.org Sun Dec 30 09:41:53 2012 Return-Path: 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 4018621F866F for ; Sun, 30 Dec 2012 09:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.038, 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 eiGM-2XBag-E for ; Sun, 30 Dec 2012 09:41:52 -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 F2BFC21F865D for ; Sun, 30 Dec 2012 09:41:51 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:cdff:cdee:4d41:50fd] (unknown [IPv6:2601:9:4b80:32:cdff:cdee:4d41:50fd]) (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 0590B20DB2; Sun, 30 Dec 2012 17:41:49 +0000 (UTC) Message-ID: <50E07CE7.4090908@acm.org> Date: Sun, 30 Dec 2012 09:41:59 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <20121230105928.32328.13827.idtracker@ietfa.amsl.com> <50E03CE8.7020907@informatik.haw-hamburg.de> In-Reply-To: <50E03CE8.7020907@informatik.haw-hamburg.de> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Fwd: New Version Notification for draft-ietf-p2psip-sip-08.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 17:41:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Thomas, This version is a great improvement, and all the items listed in my previous reviews are now fixed. I have two new comments and few nits related to this new version: 1. I think the document needs some guidance on how to use (D)TLS. The AppAttach creates a bare TLS connection or UDP association. The draft-ietf-p2psip-base document registers Application-ID 5061 in addition to 5060, so I guess that the intent was to use that as an indication that (D)TLS should be started on the connection/association immediately after the establishment (note that section 4.2 of -p2psip-sip talks only about 5060), but should all P2P SIP enabled peers listen on both Application-IDs? If not, how do peers know which one to use? Perhaps peers may want to register this information in the SipRegistration Resource Record. Note that this does not require a modification of the SipRegistration format, as contact_prefs can be used for that, e.g. if only Application-ID 5061 is supported: (sip.schemes=sips) 2. The pattern language used in 3.4 is not defined. Looking at the example, it seems to be a regex variant, but in this case the first example would also match with dht-example.com. I propose to use "POSIX Extended Regular Expression" (see reference in RFC 3402), in which case the examples in the spec become: dht\.example\.com .*\.my\.name A simpler alternative would be to use Unix wildcards, in which case the examples become: dht.example.com *.my.name Note that draft-ietf-p2psip-share also does not define the wildcard/regex variant used. Nits ==== - - In the whole document: s/kind/Kind/ (unless it is "kind of" form) - - Abstract: s/AoR/AOR/ - - 1. Introduction: s/stores a mapping from his URI/stores a mapping from his AOR/ - - 3.2. Data Structure Replace: enum {sip_registration_uri (1), sip_registration_route (2), (255)} SipRegistrationType; With: enum { sip_registration_uri(1), sip_registration_route(2), (255) } SipRegistrationType; - - 3.2. Data Structure: s/PDU/Resource Record/ - - 3.2. Data Structure: Add a reference to RFC 2738, that fixes bugs in RFC 2533. - - 3.4. Overlay Configuration Document Extension: s/or contains the domain suffix/or ends with the domain/ - - 9. IANA Considerations: Add registration for namespace "urn:ietf:params:xml:ns:p2p:config-base:sip" Thanks. On 12/30/2012 05:08 AM, Thomas C. Schmidt wrote: > Hi all, > > we've updated the draft "SIP USAGE" with the aim of addressing all issues > as discussed in the Atlanta meeting. > > Changes since draft-ietf-p2psip-sip-07 in detail: > > o Cleared open issues o Clarified use cases after WG discussion o Added > configuration document extensions for configurable domain names o > Specified format of contact_prefs o Clarified routing to AORs o Extended > security section o Added Appendix on Third Party Registration o Added > IANA code points o Editorial polishing o Updated and extended references > > I guess we all want to progress the document side by side with the base > spec. So please feel encouraged to read and review! > > Cheers & best wishes for 2013 > > Thomas > > -------- Original Message -------- Subject: New Version Notification for > draft-ietf-p2psip-sip-08.txt Date: Sun, 30 Dec 2012 02:59:28 -0800 From: > internet-drafts@ietf.org To: schmidt@informatik.haw-hamburg.de CC: > fluffy@cisco.com, ekr@rtfm.com, bbl@lowekamp.net, salman@cs.columbia.edu, > hgs@cs.columbia.edu > > > A new version of I-D, draft-ietf-p2psip-sip-08.txt has been successfully > submitted by Thomas C. Schmidt and posted to the IETF repository. > > Filename: draft-ietf-p2psip-sip Revision: 08 Title: A SIP > Usage for RELOAD Creation date: 2012-12-30 WG ID: p2psip Number > of pages: 17 URL: > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-sip-08.txt Status: > http://datatracker.ietf.org/doc/draft-ietf-p2psip-sip Htmlized: > http://tools.ietf.org/html/draft-ietf-p2psip-sip-08 Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-sip-08 > > Abstract: This document defines a SIP Usage for REsource LOcation And > Discovery (RELOAD). The SIP Usage provides the functionality of a SIP > proxy or registrar in a fully-distributed system and includes a lookup > service for Address of Records (AoRs) stored in the overlay. It also > defines Globally Routable User Agent Uris (GRUUs) that allow the > registrations to map an AoR to a specific node reachable through the > overlay. After such initial contact of a peer, the AppAttach method is > used to establish a direct connection between nodes through which SIP > messages are exchanged. > > - -- 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) iQIcBAEBCAAGBQJQ4HzlAAoJECnERZXWan7EgZsQAJuSaGxps+mpeqVmKGTcNV4I /J+68OqfQljTyf22NGwqAl76SCnYqva1cEcTZk/CEMeu4CCjYPIjbNKx9BRF7APq e9JQyyqBWAnExXCdywkDmUb88pkpXwWB14o7KaQ2pL/xILUeu2JrKgEEfyeGuYY1 F3N52Oyvx/XZikawxOZb4iEh5Ys1vEYRuaJTnhovXYA+kP4Ier2BdjymJz7k7vgM szTrCZ780d+wSVUZjH6p5Ji8webbeIq90pbjQrBXfRPY+oiPCQaQOwks8m3nJozK dwzEe7TK+4R20LiWq84W/8RQR1ISr2AyjLXxijMqHRCRBpQwqg000Q8o5npubAhc SKXXvEyZbb5E/6h4ilg0Yl4pgbj1iyAsI4BtM9hJp9wxLoYRmR8dZAdSmI+wVOE4 Hdalz9xY2yvPpufYmcDyP1aTG8J51wZg9OOLnJsVVf6IWLKbO8lSF2XcHf4ZplLc dpykLCKU+Y+xJcLThJhYT+lngs4SzW1To6GLORIyWW9/5PLVpIrFKTt0u2qku7/4 XBspxKS0pkLemHIzIDdrbdnMGZFvxe1sdiTvHmPLqRdoFTc0xwuwE8OzTKtTDA7X wlEPsX3mOwk/MsC98G09qAz5zTZ445eHCSl5CPasLgasxdFjlTQ7b7n65QPZm1Lv qgzfSOgWKWrkZU20d+1o =HnEO -----END PGP SIGNATURE-----