From petithug@acm.org Mon Oct 3 07:57:04 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ACF21F8505 for ; Mon, 3 Oct 2011 07:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.294 X-Spam-Level: X-Spam-Status: No, score=-102.294 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFL-M51tV9mr for ; Mon, 3 Oct 2011 07:56:59 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id DB9CB21F84A7 for ; Mon, 3 Oct 2011 07:56:58 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id C3D93202D1 for ; Mon, 3 Oct 2011 14:53:08 +0000 (UTC) Message-ID: <4E89CDEE.5040000@acm.org> Date: Mon, 03 Oct 2011 07:59:58 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [VIPR] Minutes for 2011/09/30 conference call X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 14:57:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 VIPR Design Team conference call on Friday September 30th, from 9:05am to 9:55am PST. o Attendees: Mary Barnes Hakim Mehmood Muthu Arul Mozhi Perumal Jon Peterson Marc Petit-Huguenin John Ward Dean Willis o Regrets: Daryl Malas Michael Procter o Agenda - - Security section of -overview (5 min) - - SIP Intermediaries (10 min) - - Capabilities (10 min) - - RELOAD registration (5 min) - - PVP privacy (10 min) - - PVP method priority and registration (10 min) - - PVP method entropy (10 min) - - Replacement ticket by client certificate (10 min) - - Ticket renewal (10 min) - - Infrastructure overlays (5 min) o Action items - - Mary will send an improved text for the -overview Security Considerations section to the mailing-list. - - Marc will send an email describing the problem and use cases for SIP intermediaries. o Minutes - - Security section of -overview Marc: Mary published a new version of the -overview document. Security section still need some work. Mary: My impression is that it's 80% there. Not sure what it's in there will get us past AD security review. Hakim: Any concern on the test of phone numbers? Mary: The idea of the attacker claiming phone numbers as its own was part of the concerns that Richard Shockey brought forward. Dean: There is potential for denial of service by claiming a lot of numbers. Hakim: The idea with VIPR is that you bring your own resources. There should be a way for the overlay to reject excessive requests. Mary: Does RELOAD handle that? Dean: The fundamental problem with RELOAD is that someone can dedicate 10000's CPU to mess up the overlay. But that's a RELOAD problem, not a VIPR problem Hakim: DHTs perform better as more nodes are added. Dean: Only if those nodes are performing correctly. Hakim: It's an attack on performance. Jon: In the security section we must be careful to enumerate the limitations of the system. One thing that is missing is the property of the token that is carried in SIP. What are the protocols that are securing the actual network interaction, e.g. TLS. Should list the counter-measures, for example for the phone number mechanism it would be a combination of the overlay validation mechanism and the generation of the SIP token. Marc: The methods that are described in -pvp are just examples, and the security of these should be deferred to the document where they are defined. Mary: It's OK to point solution in other documents but we need to be sure that we have a comprehensive security overview. Jon: Is there an authentication problem, is there an integrity problem? Then saying that there is a token in this other draft. Marc: So who want to contribute? Mary: I can make a pass at the modifications suggested and send it to the mailing-list. - - SIP Intermediaries Marc: We agreed on the previous call that SIP intermediaries should not be only for toll bypass, but to improve the SIP situation. I put a proposal together and this proposal is to carry both the SDP to the PSTN gateway (aka SIPconnect profile) and the SDP with SIP enhanced feature (aka SIPbeyond, which could be defined in collaboration with RTCWEB) in a multipart/alternative body. Jon: I am not initially a huge fan of this. We want to keep VIPR as close as possible to standard SIP. As said in the previous call, the high level solution is to be clear that VIPR is intended to provide feature transparency. If you just provide a great PSTN service, then you should not be doing this. Marc: I agree 100%, but what VIPR domains who want to participate should do? Hakim: I agree with Jon, the original intent of VIPR was to use SIP has is. I am not sure there is a good solution. One of the approach is to collect all the routes you can and then use a policy to choose one, a policy could be to choose the route that have the best features, or your policy could be to choose the least cost. Marc: It's a different topic. It is not about choosing the best route, but for intermediate VIPR domains on an outgoing call. We all agree that a domain that is not improving SIP should not participate. The question is what do we do when an intermediate want to do the right thing. Jon: Same answer that I gave last time, if we do that, we completely missed what we want to do with VIPR. Any entity that is advertizing a route to an endpoint should doing so only if it is a route to the features of the endpoint. Dean: It's almost a denial of service on the intent of VIPR. Jon: We want to have a story to how VIPR is gonna work with federations, but I see that as a distant goal for us. I am not saying that intermediaries should not participate, but we need to understand how to work with this kind of systems. Marc: We all agree on this, but we are not proposing a solution. I think that we should not exclude intermediaries, and I disagree that we should do this later. If we exclude them then we will not have enough participants. [The next 15 minutes of audio recording are lost. Next call will have one more recording point to prevent this to happen again. Sorry for that] Jon: ...we should not give up on the idea that we can have one route per phone number provisioned in your VIPR entity. John: We should definitively talk more about this. For us to know as a provider, a carrier, the capabilities of a given endpoint is something that will be more and more possible. So having a route to an endpoint at this capability level is something that we really want support. Jon: If it is desirable for an endpoint to defer to an upstream entity, it's perhaps possible to have a kind of negotiation. There is other ways than forcing this complexity. John: Your issue is that it is the endpoint that should decide based on all the entities that reported back. Jon: I am trying to deal with the issue which is how do you deal with sending a SIP INVITE that there is multiple places it could land and how do you build the richest connection features. How does an INVITE will reach the entity with the richest feature, which is not a trivial problem to solve. John: Unless each of these routes are reporting their supported feature set. Hakim: But intermediaries will not really know. John: I am not convinced that's a valid assumption. Suppose that a provider knows the features supported by the devices. Why shouldn’t this provider been able to participate in VIPR? Hakim: OK, but what about an entity one step further? John: They shouldn't be advertizing it. Hakim: Then how do you prevent it? John: If you do not allow the proxy, then you can never, ever, have non-VIPR players play with VIPR federations. Hakim: I am not suggesting that. Everybody should publish, but we need to have a way to pick the right route. Marc: Sorry to interrupt, but we are running out of time. I will send another email only describing the problem, and use cases. But we need discussion on the mailing-list to accelerate decisions. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6JzewACgkQ9RoMZyVa61euoQCeIKs3wfKt18UGiSzGIKs87LVU lfUAnR6eihekvGGixAumXYF82kr9jKJ0 =G+WT -----END PGP SIGNATURE----- From petithug@acm.org Mon Oct 3 09:23:28 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86F221F8B62 for ; Mon, 3 Oct 2011 09:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.303 X-Spam-Level: X-Spam-Status: No, score=-102.303 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sKkvwaYwq8X for ; Mon, 3 Oct 2011 09:23:28 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9BF21F8B26 for ; Mon, 3 Oct 2011 09:23:28 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 15DBD202D1; Mon, 3 Oct 2011 16:19:38 +0000 (UTC) Message-ID: <4E89E235.6000908@acm.org> Date: Mon, 03 Oct 2011 09:26:29 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <4E7B5199.5000409@petit-huguenin.org> <3175C4C5F682C145B25808EB5737F16C0ECA7F83@xmb-sjc-21b.amer.cisco.com> <1D062974A4845E4D8A343C653804920206805382@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920206805382@XMB-BGL-414.cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: vipr@ietf.org Subject: Re: [VIPR] Agenda for 2011/09/23 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 16:23:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Muthu, On 09/28/2011 11:10 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: > A fundamental question: Why would a provider want to advertise routes for a > number for which neither of the enterprises is willing to pay for? I am not sure why you are saying that. When an enterprise uses a provider, it is paying for the service of routing the calls to the PSTN, so why advertizing the number in the VIPR overlay could not be part of this cost? > Isn't ViPR based on the fact the provider is trusted for the first (PSTN) > call? If the provider is fooling with the enterprise, won't the enterprise > switch to a different provider? Or are we concerned about the security > implications around routing subsequent calls through the provider? Aren't > they applicable to the first call as well? > > If the enterprise doesn't trust the provider then ViPR in its current form > doesn't seem to make sense. > > Muthu - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6J4jQACgkQ9RoMZyVa61cL+QCfTYblcS5CYAfWyJtEgwEUpdQX pfoAniHnwohEklPZMndKsOcA6wo+3IXr =AS6j -----END PGP SIGNATURE----- From petithug@acm.org Mon Oct 3 10:24:49 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C196B21F8C17 for ; Mon, 3 Oct 2011 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.161 X-Spam-Level: X-Spam-Status: No, score=-101.161 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, MANGLED_TEXT=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x77t+oQHQh4d for ; Mon, 3 Oct 2011 10:24:49 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A1E4721F8C2B for ; Mon, 3 Oct 2011 10:24:48 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8AFD6202D1 for ; Mon, 3 Oct 2011 17:20:58 +0000 (UTC) Message-ID: <4E89F095.3070301@acm.org> Date: Mon, 03 Oct 2011 10:27:49 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] A new proposal for SIP Intermediaries X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 17:24:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For the second time, the Design Team conference call got stuck on the subject of SIP intermediaries in VIPR, and we were not able to make any progress on the VIPR specifications themselves. I was supposed to send another email to this mailing-list to describe in more details the problems created by SIP intermediaries but I fear that the next conference calls will still being spent arguing about this. So I would like to propose an alternate route to solve this issue. SIP intermediaries are not described at all in the current specifications, but I think that everybody agree that we should say something about it, because it will become a reality, even if we decide to make it a SHOULD NOT (which would exclude a lot of potential participants from the VIPR federation). On the other hand, VIPR domains does not require SIP intermediaries to work. So my proposal is: 1. Put everything related to SIP intermediaries in a separate I-D, so it does not hold the main specifications. 2. Add in the main specifications the "hooks" required to be able to add support for SIP intermediaries as an extension in the future (as opposed to have to work on a new version of the VIPR RFCs to add SIP intermediaries, which will push back the deployment of SIP intermediaries for another 3 years). 3. Add a new milestone for the SIP intermediaries (I would suggest April 2012[1]) Please let me know as soon as possible if you agree with this new plan, at least on the two first points, so I can release the first version of the new draft-petithuguenin-vipr-sip-intermediaries I-D, and so we can move one on the other subjects that are actually blocking the work on -framework. Thanks. [1] And I would also suggest to move at the same time the "Submit Specification of authorization tokens to mitigate SPAM for publication as Proposed Standard" to December 2011, as it make sense to submit this at the same time than the other core VIPR specifications. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6J8JMACgkQ9RoMZyVa61ckLQCgpM/sND37krkNZRPWrQt4deHF dRMAnAmG7FZFFaIU7xNC+oHUIChQGU/C =t3x7 -----END PGP SIGNATURE----- From petithug@acm.org Tue Oct 4 10:03:31 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5A621F8C53 for ; Tue, 4 Oct 2011 10:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.288 X-Spam-Level: X-Spam-Status: No, score=-102.288 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoqdjkKo40Ga for ; Tue, 4 Oct 2011 10:03:31 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 39CAA21F8C13 for ; Tue, 4 Oct 2011 10:03:31 -0700 (PDT) Received: from [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08] (unknown [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 12A2720D86 for ; Tue, 4 Oct 2011 16:59:39 +0000 (UTC) Message-ID: <4E8B3D19.9040607@acm.org> Date: Tue, 04 Oct 2011 10:06:33 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Fwd: I-D Action: draft-petithuguenin-vipr-sip-intermediaries-00.txt X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 17:03:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As discussed in the last conference call, I prepared a description of the problem created by SIP intermediaries in a VIPR federation. But as explained yesterday, I decided to publish it as an Internet-Draft instead of in an email, so we can separate this problem from the more pressing problems that we need to solve to be able to publish a new version of the VIPR documents in time for the IETF meeting in Taipei. Thanks. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-vipr-sip-intermediaries-00.txt Date: Tue, 04 Oct 2011 09:59:49 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Verification Involving PSTN Reachability (VIPR) enabled SIP Intermediaries Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-vipr-sip-intermediaries-00.txt Pages : 8 Date : 2011-10-04 This document presents some of the problems created by SIP intermediaries inside a VIPR federation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-sip-intermediaries-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-vipr-sip-intermediaries-00.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6LPRcACgkQ9RoMZyVa61cTkACfW0Qu+e7hz0oaHs3QkwnHSmLp /HQAn0Fcie+zYECaQWszuEeGQ2BtNAdE =FNhF -----END PGP SIGNATURE----- From petithug@acm.org Tue Oct 4 11:55:15 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E1921F8E3A for ; Tue, 4 Oct 2011 11:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.296 X-Spam-Level: X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMa8rS74HM4t for ; Tue, 4 Oct 2011 11:55:14 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 3C85021F8E37 for ; Tue, 4 Oct 2011 11:55:12 -0700 (PDT) Received: from [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08] (unknown [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 48E3920D86 for ; Tue, 4 Oct 2011 18:51:21 +0000 (UTC) Message-ID: <4E8B5746.5010504@acm.org> Date: Tue, 04 Oct 2011 11:58:14 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Fwd: I-D Action: draft-petithuguenin-vipr-sip-intermediaries-01.txt X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:55:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A new version that adds more details on the problems created by SIP intermediaries. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-vipr-sip-intermediaries-01.txt Date: Tue, 04 Oct 2011 11:54:01 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Verification Involving PSTN Reachability (VIPR) enabled SIP Intermediaries Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-vipr-sip-intermediaries-01.txt Pages : 11 Date : 2011-10-04 This document presents some of the problems created by SIP intermediaries inside a VIPR federation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-sip-intermediaries-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-vipr-sip-intermediaries-01.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6LV0UACgkQ9RoMZyVa61fggQCcCG8/64j0fLyVCqLXXLEjNVsI RQoAnij8WZv/cTr2wyC732TC9ec2fdIR =++J6 -----END PGP SIGNATURE----- From jward@IntelePeer.com Wed Oct 5 13:09:36 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB88921F8BE5 for ; Wed, 5 Oct 2011 13:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_00=-2.599, MANGLED_TEXT=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfXHBAWhsE6V for ; Wed, 5 Oct 2011 13:09:36 -0700 (PDT) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF1421F8BE4 for ; Wed, 5 Oct 2011 13:09:36 -0700 (PDT) Received: from gateout02.mbox.net (gwo2-lo [127.0.0.1]) by gateout02.mbox.net (Postfix) with ESMTP id 78F8C4BDCEB; Wed, 5 Oct 2011 20:12:39 +0000 (GMT) X-USANET-Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.72B) with ESMTP id 516PJeumj2480Mo2; Wed, 05 Oct 2011 20:12:35 -0000 X-USANET-Routed: 10 gwsout-externalarchive C:gwsarchive:650 intelepeer.com.gw.dwtetzxbj@incoming02.seccas.com Received: from S1HUB4.EXCHPROD.USA.NET [165.212.120.254] by gateout02.mbox.net via smtad (C8.MAIN.3.72B) with ESMTPS id XID248PJeumj6109Xo2; Wed, 05 Oct 2011 20:12:35 -0000 X-USANET-Source: 165.212.120.254 IN jward@IntelePeer.com S1HUB4.EXCHPROD.USA.NET X-USANET-MsgId: XID248PJeumj6109Xo2 Received: from MBX6.EXCHPROD.USA.NET ([10.120.221.62]) by S1HUB4.EXCHPROD.USA.NET ([10.120.220.34]) with mapi; Wed, 5 Oct 2011 20:12:21 +0000 From: John Ward To: Marc Petit-Huguenin , "vipr@ietf.org" Date: Wed, 5 Oct 2011 20:11:52 +0000 Thread-Topic: [VIPR] A new proposal for SIP Intermediaries Thread-Index: AcyB/yh8x+OK1fPXRAyhKtlO6TJXTQBm8mRQ Message-ID: <8461F7EE2109014B9D247CF39BBA419FA9EC7B411C@MBX6.EXCHPROD.USA.NET> References: <4E89F095.3070301@acm.org> In-Reply-To: <4E89F095.3070301@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [VIPR] A new proposal for SIP Intermediaries X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 20:09:37 -0000 TWFyYywNCg0KSSBhbSBzdXBwb3J0ZWQgb2YgdGhpcyBwcm9wb3NhbC4NCg0KSm9obg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFyYyBQZXRpdC1IdWd1ZW5pbiBbbWFpbHRv OnBldGl0aHVnQGFjbS5vcmddIA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDAzLCAyMDExIDExOjI4 IEFNDQpUbzogdmlwckBpZXRmLm9yZw0KU3ViamVjdDogW1ZJUFJdIEEgbmV3IHByb3Bvc2FsIGZv ciBTSVAgSW50ZXJtZWRpYXJpZXMNCg0KLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0t LQ0KSGFzaDogU0hBMQ0KDQpGb3IgdGhlIHNlY29uZCB0aW1lLCB0aGUgRGVzaWduIFRlYW0gY29u ZmVyZW5jZSBjYWxsIGdvdCBzdHVjayBvbiB0aGUgc3ViamVjdCBvZg0KU0lQIGludGVybWVkaWFy aWVzIGluIFZJUFIsIGFuZCB3ZSB3ZXJlIG5vdCBhYmxlIHRvIG1ha2UgYW55IHByb2dyZXNzIG9u IHRoZQ0KVklQUiBzcGVjaWZpY2F0aW9ucyB0aGVtc2VsdmVzLiAgSSB3YXMgc3VwcG9zZWQgdG8g c2VuZCBhbm90aGVyIGVtYWlsIHRvIHRoaXMNCm1haWxpbmctbGlzdCB0byBkZXNjcmliZSBpbiBt b3JlIGRldGFpbHMgdGhlIHByb2JsZW1zIGNyZWF0ZWQgYnkgU0lQDQppbnRlcm1lZGlhcmllcyBi dXQgSSBmZWFyIHRoYXQgdGhlIG5leHQgY29uZmVyZW5jZSBjYWxscyB3aWxsIHN0aWxsIGJlaW5n IHNwZW50DQphcmd1aW5nIGFib3V0IHRoaXMuICBTbyBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSBh biBhbHRlcm5hdGUgcm91dGUgdG8gc29sdmUgdGhpcw0KaXNzdWUuDQoNClNJUCBpbnRlcm1lZGlh cmllcyBhcmUgbm90IGRlc2NyaWJlZCBhdCBhbGwgaW4gdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlv bnMsIGJ1dCBJDQp0aGluayB0aGF0IGV2ZXJ5Ym9keSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBzYXkg c29tZXRoaW5nIGFib3V0IGl0LCBiZWNhdXNlIGl0DQp3aWxsIGJlY29tZSBhIHJlYWxpdHksIGV2 ZW4gaWYgd2UgZGVjaWRlIHRvIG1ha2UgaXQgYSBTSE9VTEQgTk9UICh3aGljaCB3b3VsZA0KZXhj bHVkZSBhIGxvdCBvZiBwb3RlbnRpYWwgcGFydGljaXBhbnRzIGZyb20gdGhlIFZJUFIgZmVkZXJh dGlvbikuICBPbiB0aGUgb3RoZXINCmhhbmQsIFZJUFIgZG9tYWlucyBkb2VzIG5vdCByZXF1aXJl IFNJUCBpbnRlcm1lZGlhcmllcyB0byB3b3JrLg0KDQpTbyBteSBwcm9wb3NhbCBpczoNCg0KMS4g UHV0IGV2ZXJ5dGhpbmcgcmVsYXRlZCB0byBTSVAgaW50ZXJtZWRpYXJpZXMgaW4gYSBzZXBhcmF0 ZSBJLUQsIHNvIGl0IGRvZXMNCm5vdCBob2xkIHRoZSBtYWluIHNwZWNpZmljYXRpb25zLg0KMi4g QWRkIGluIHRoZSBtYWluIHNwZWNpZmljYXRpb25zIHRoZSAiaG9va3MiIHJlcXVpcmVkIHRvIGJl IGFibGUgdG8gYWRkIHN1cHBvcnQNCmZvciBTSVAgaW50ZXJtZWRpYXJpZXMgYXMgYW4gZXh0ZW5z aW9uIGluIHRoZSBmdXR1cmUgKGFzIG9wcG9zZWQgdG8gaGF2ZSB0byB3b3JrDQpvbiBhIG5ldyB2 ZXJzaW9uIG9mIHRoZSBWSVBSIFJGQ3MgdG8gYWRkIFNJUCBpbnRlcm1lZGlhcmllcywgd2hpY2gg d2lsbCBwdXNoDQpiYWNrIHRoZSBkZXBsb3ltZW50IG9mIFNJUCBpbnRlcm1lZGlhcmllcyBmb3Ig YW5vdGhlciAzIHllYXJzKS4NCjMuIEFkZCBhIG5ldyBtaWxlc3RvbmUgZm9yIHRoZSBTSVAgaW50 ZXJtZWRpYXJpZXMgKEkgd291bGQgc3VnZ2VzdCBBcHJpbCAyMDEyWzFdKQ0KDQpQbGVhc2UgbGV0 IG1lIGtub3cgYXMgc29vbiBhcyBwb3NzaWJsZSBpZiB5b3UgYWdyZWUgd2l0aCB0aGlzIG5ldyBw bGFuLCBhdCBsZWFzdA0Kb24gdGhlIHR3byBmaXJzdCBwb2ludHMsIHNvIEkgY2FuIHJlbGVhc2Ug dGhlIGZpcnN0IHZlcnNpb24gb2YgdGhlIG5ldw0KZHJhZnQtcGV0aXRodWd1ZW5pbi12aXByLXNp cC1pbnRlcm1lZGlhcmllcyBJLUQsIGFuZCBzbyB3ZSBjYW4gbW92ZSBvbmUgb24gdGhlDQpvdGhl ciBzdWJqZWN0cyB0aGF0IGFyZSBhY3R1YWxseSBibG9ja2luZyB0aGUgd29yayBvbiAtZnJhbWV3 b3JrLg0KDQpUaGFua3MuDQoNCg0KWzFdIEFuZCBJIHdvdWxkIGFsc28gc3VnZ2VzdCB0byBtb3Zl IGF0IHRoZSBzYW1lIHRpbWUgdGhlICJTdWJtaXQgU3BlY2lmaWNhdGlvbg0Kb2YgYXV0aG9yaXph dGlvbiB0b2tlbnMgdG8gbWl0aWdhdGUgU1BBTSBmb3IgcHVibGljYXRpb24gYXMgUHJvcG9zZWQg U3RhbmRhcmQiDQp0byBEZWNlbWJlciAyMDExLCBhcyBpdCBtYWtlIHNlbnNlIHRvIHN1Ym1pdCB0 aGlzIGF0IHRoZSBzYW1lIHRpbWUgdGhhbiB0aGUNCm90aGVyIGNvcmUgVklQUiBzcGVjaWZpY2F0 aW9ucy4NCg0KLSAtLSANCk1hcmMgUGV0aXQtSHVndWVuaW4NClBlcnNvbmFsIGVtYWlsOiBtYXJj QHBldGl0LWh1Z3VlbmluLm9yZw0KUHJvZmVzc2lvbmFsIGVtYWlsOiBwZXRpdGh1Z0BhY20ub3Jn DQpCbG9nOiBodHRwOi8vYmxvZy5tYXJjLnBldGl0LWh1Z3VlbmluLm9yZw0KLS0tLS1CRUdJTiBQ R1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTEgKEdOVS9MaW51eCkNCg0K aUVZRUFSRUNBQVlGQWs2SjhKTUFDZ2tROVJvTVp5VmE2MWNrTFFDZ3BNL3NORDM3a3JrTlpSUFdy UXQ0ZGVIRg0KZFJNQW5BbUc3RlpGRmFJVTd4TkMrb0hVSUNoUUdVL0MNCj10M3g3DQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg0K From petithug@acm.org Thu Oct 6 08:00:36 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BDC21F8D6D for ; Thu, 6 Oct 2011 08:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.85 X-Spam-Level: X-Spam-Status: No, score=-99.85 tagged_above=-999 required=5 tests=[AWL=-2.050, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_SUMOF=5, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6g7zftAHTyM for ; Thu, 6 Oct 2011 08:00:34 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 43FD121F8D72 for ; Thu, 6 Oct 2011 08:00:34 -0700 (PDT) Received: from [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08] (unknown [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 0EC172087B; Thu, 6 Oct 2011 14:56:37 +0000 (UTC) Message-ID: <4E8DC34B.8020703@acm.org> Date: Thu, 06 Oct 2011 08:03:39 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111005 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Dean Willis , "Hakim Mehmood (naim)" , Michael Procter , John Ward , 'Mary Barnes' , "Muthu Arul Mozhi Perumal (mperumal)" , Daryl Malas , Jon Peterson X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "vipr@ietf.org" Subject: [VIPR] Agenda & Handout for 2011/10/07 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 15:00:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A. Agenda - - Move SIP intermediaries in a future draft (5 min) - - RELOAD registration (5 min) - - Replacement ticket by client certificate (10 min) - - PVP privacy (10 min) - - PVP method priority and registration (10 min) - - PVP method entropy (10 min) - - Ticket renewal (10 min) - - Infrastructure overlays (5 min) Note that the sum of the time allocated to each topic exceeds the time allocated to the whole call. The topics that cannot make it to the discussion will be postponed to the next conference call if they are not subsequently decided in the mailing-list. Because the conference bridge as a limited capacity, an individual invitation to the conference will be sent shortly after this email to each member of the design team. Please send me an email if you are not on this list and want to receive an invitation. Note that the design team conference call is not a way to short-circuit the normal process, but a way to accelerate it by increasing face to face time. All decisions made must be confirmed on the mailing-list. This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). B. Handout (reading time: 10 min) B.1. Move SIP intermediaries in a future draft SIP intermediaries are not described at all in the current specifications, but everybody agree that we should say something about it, because it will become a reality, even if we decide to make it a SHOULD NOT (which would exclude a lot of potential participants from the VIPR federation). On the other hand, VIPR domains does not require SIP intermediaries to work. So the proposal is: 1. Put everything related to SIP intermediaries in a separate I-D, so it does not hold the main specifications. 2. Add in the main specifications the "hooks" required to be able to add support for SIP intermediaries as an extension in the future (as opposed to have to work on a new version of the VIPR RFCs to add SIP intermediaries, which will push back the deployment of SIP intermediaries for another 3 years). 3. Add a new milestone for the SIP intermediaries (April 2012 proposed) B.2. RELOAD registration The current specification states that a phone number must be registered 3 times, which with the underlying replication done by the CHORD RELOAD algorithm, means that the mapping between a PVP server and a phone number is stored 9 times. The question discussed in Quebec City was what to do when the 3 copies retrieved from the overlay are not identical, and the proposal was to use the copy that appears at least twice, so no peer can alone create a denial of service for a specific number. The discussion moved to the reasons for having 3 copies in the first place. The proposal is to drop the requirement for the 3 copies from VIPR, but to add the requirement that the node requesting the phone number MUST also fetch (or stat) the 2 additional replicas and use the value that matches at least one other copy (using a majority vote prevents a rogue peer to block the access to the phone numbers currently stored here). If not all 3 copies are equals, then an incident must be logged. The PVP client must retrieve the 2 replicas in addition to the original registration and use the voting algorithm to choose one and log an incident if all 3 are not equal. B.3. Ticket vs Client certificate In the current specification, the PVP server builds and signs a VIPR ticket, and sends it back to the PVP client, which passes it to the SIP element. The SIP element will insert this ticket in the next SIP method to the remote SIP element, which will check the validity of the ticket and the domain of the TLS client. There is multiple problems with this process: - - The verification of the ticket use HMAC-SHA1, and so the same password has to be provisioned in both the SIP element (to verify the ticket) and the PVP server (to generate the ticket). - - The ticket can be used without TLS, and we all know that implementers think of MUST as SHOULD and SHOULD as MAY. So the proposal would be to replace the ticket by a client certificate, which could work like this: Instead of using a symmetrical key, the local PVP server generates an RSA key pair, with the public key distributed to the SIP element(s). After a successful PVP connection, the remote PVP client sends a PKCS#10 certificate request, containing the domain name and signed with a private key. The local PVP server generates a new certificate, sign it with its private key and send it back to the remote PVP client, which pass it back to the remote SIP element. The remote SIP element will use the certificate received to establish the TLS connection for the SIP transactions to the local SIP element, which will use a standard CA based certificate for its own domain. The local SIP element will be able to verify with the PVP server public key that it issued the certificate, then will validate the standard parts of the certificate (expiration date and so on). There is multiple advantages to this proposal: - - The private key is stored only in the PVP server, or better in a physical token. - - VIPR does not work without TLS for the SIP connection. - - There is plenty of commercial or free TLS and X.509 implementations that have years of experience and testing, which is not the case for the ticket proposal. - - Security agility is provided by TLS. - - No additional SIP Header. - - Because the ticket verification process is folded into the client certificate verification, less processing resources are needed. B.4. PVP Privacy As reported by Michael Procter, there is ways with the current PVP methods to discover valuable information about a competitor. But first let's add some common vocabulary related to PVP: - - The PVP selector is a list of parameters that are sent by the PVP client side to retrieve a set of call records in the PVP server side. The resulting set can be empty, in which case the validation fails, can contain one element, or can contain multiple elements in which case the method description must also defines what call record should be selected (e.g. in the case of method "a", the most recent call record is selected). One important point is that the selector is always passed from the PVP client to the PVP server in clear, and so this is where the privacy leakage happens. - - The PVP parameter is a list of name/value pairs that are passed in clear between the PVP client and PVP server to aid the verification. Examples are the rounding value and the vservice id for methods "a" and "b". - - The PVP secret is the information that each side of the PVP transaction tries to verify. The algorithm used (SRP) uses a zero-knowledge password proof, so neither side can deduce the secret if the verification fails. In the case of methods "a" and "b" the secret is the rounded start and end time for the call, but there is a lot of other possible secrets that can be used in new methods (DTMF, UUIE, fingerprint, SMS hash, etc...). In the privacy issue, the problem is that callee number and caller numbers are disclosed in the PVP selector for method "a" and the callee number is disclosed in the PVP selector for method "b". One proposed solution would be to hash these numbers, but finding the phone numbers would still be trivial for a determined competitor. Passing the hash salt as a PVP parameter and using an adaptive hash method like bcrypt will force the PVP server to rehash all the current terminating call record, but will force a competitor to rehash probably half of the total E.164 space to find the numbers. This is still possible but can provide an adequate privacy protection level. Another possibility would be to invert the selector and the secret. After all the star/stop time of a call is not as sensitive as the caller/callee phone numbers. In this method the PVP selector would be the start/stop time and the secret would be the caller/callee numbers. The problem is that it will be more difficult to design an algorithm to select a unique call record if the returned set contains more than one. One solution could be to add more data in the PVP selector, for example by adding the call initiation time and the direction of the termination. We do not even need to decide - we can define these two algorithms as different methods (in addition to "a" and "b") and let the VIPR domain choose (see PVP registry proposal). B.5. PVP Methods Registry On the PVP subject, The VIPR specification currently defines two methods for the PSTN validation: Method "a", which is used when the Caller-ID is available and method "b", which is used when it is not. The PVP draft also permits to define new validation methods, but it does not explain when and how to use this extended methods. This proposal is in two parts. First we need to establish a IANA registry for the PVP methods, and to assign a priority to each of these methods. Let's say for now that the priority is between -∞ (lowest priority) to +∞ (highest priority) and that priorities should be assigned by steps of 100. With this scale we could assign priority 0 to method "b" and priority 100 to method "a". Then we say in the spec that a VIPR server must try available methods starting from the highest priority to the lowest priority, until one succeeds or all fail. This implements the same algorithm that is currently in -pvp ("a" first, then "b"). Now the problem with this is that the number of methods will increase in the future, but we may not want that the PVP client tries all the methods available each time. So the second part of this proposal is to have each VIPR domain publishing the list of methods supported by each of its phone numbers in the RELOAD distributed database, in the existing VIPR-REGISTRATION resource record. With this information, the PVP client immediately knows what methods to try from the VIPR-REGISTRATION record, and the order to try them from the IANA registry, and can also accumulate statistics on the usage of unsupported methods. The PVP server can use this mechanism to simplify the process. For example if it knows that it will never receive the Caller-ID, it just have to never advertize the "a" method. Another example is with analog FXO ports that cannot be used with either method "a" or "b". In this case the VIPR server can still advertize a new method using DTMF or fingerprint. Note that because the methods supported per phone number are stored in the RELOAD distributed database, the SIP call agent cannot retrieve them to decide what method to use when starting a call, as it would take too much time to retrieve it (same reason the validation is not done in real-time). But it can query them in the background using the history of calls or just before scheduling a re-validation. I would also propose to move the description of the generic PVP algorithm to the - -framework document, to add a section in -framework explaining how to register a new method on a IANA registry and to keep the two existing methods ("a" and "b") into the -pvp draft. B.6. PVP Entropy A second issue related to PVP is the management of entropy (Section 10.1 of the - -pvp draft). The idea is that the fact that one validation succeeds is not always enough for a remote VIPR server to give back routes and ticket for this destination. For example a VIPR domain could decide that at least 3 different calls validated with method "b" are needed to let a SIP call reach the endpoint. This proposal describes a mechanism for PVP to implement this. The idea is that when a PVP validation succeeds, the PVP server will return a ticket but may not return the list of routes if the entropy threshold is not reached. The ticket will contain an opaque value set by the PVP server that contain the level of entropy that this caller has reached. The PVP client stores the ticket but does not notify the call agent as there is no routes available. The next time the PVP client has a successful validation with the same destination, it sends the saved ticket in addition to the domain. The PVP server then evaluates the ticket, increases the entropy value stored and sends back a new ticket. If the threshold has been reached, then the PVP server sends back the routes at the same time, routes that the PVP client can now send with the ticket to the SIP element. When renewing the routes/ticket, the PVP client also sends the existing ticket, so the PVP server can decide to lower the threshold based on the entropy collected the previous time and the date of the ticket. This can be combined with the proposal for method priority. If multiple methods are available for a destination but the first that succeeds does not return the routes then the PVP client can use the next available methods in the list to try to increase the entropy and receive them. A PVP server may even use different thresholds, depending on the domains to validate. This then becomes an extension to the white/black list, where a blacklist is implemented as a default threshold of X and an infinite threshold for the domains blacklisted, and where a whitelist is implemented as a default infinite threshold and a threshold of X for the domains whitelisted. B.7. Ticket renewal Another thing that was discussed in Quebec City was the "First Call Problem", i.e. the problem that it takes up to 48 hours to verify a call and been able to use enhanced media. I think the conclusion of the discussion was that it was not too annoying for the first call, as it did not degrade the user experience. On the other hand, the cryptographic ticket granted after the first has an expiration date and so need to be renewed, and that will degrade the user experience as it would mean that for each destination, the end-user will periodically not be able to use enhanced media for the duration of a call. There was multiple proposals at the microphone to solve this problem, but I would like to detail the one I proposed. The idea is, sometimes before the expiration of the ticket, to make in parallel a PSTN call and a SIP call using the existing SIP route and ticket for the enhanced media (let's say video for the remaining of this discussion). There is already an existing I-D that can be use for this, draft-ietf-mmusic-sdp-cs. The way it could work is that the call agent, after retrieving the SIP route and ticket for a destination, will decide that it is time to re-validate the route, based for example on the frequency of calls to this number and the remaining validity of the ticket. The SIP element then adds an additional m= line to the SDP that contains a PSTN address. The offered SDP then looks something like this: v=0 o=- 2890844526 2890842807 IN IP4 10.47.16.5 s= c=IN IP4 10.47.16.5 t=0 0 m=audio 49170 RTP/AVP 0 m=audio 9 PSTN - c=PSTN - - a=setup:active a=connection:new a=cs-correlation: uuie callerid dtmf m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 The SIP element on the other side verifies the ticket then starts to process the SDP. If it does not support this feature then, as per the rules in RFC 3264, it will reject the second m= line by using port 0 in the answer SDP (In this case the end user will have to have PSTN only calls for the 48 hours after the expiration of the ticket). If the remote SIP element supports this extension then it will send back an offer like this: v=0 o=- 0 1 IN IP4 192.168.2.1 s= c=IN IP4 192.168.2.1 t=0 0 m=audio 8000 RTP/AVP 0 m=audio 9 PSTN - c=PSTN E164 +14085551234 a=setup:passive a=connection:new a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3 m=video 9000 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 The local SIP element checks that the c= line contains the right number, then establishes the audio and video media over IP, as usual, but also starts a PSTN call following the rules in draft-ietf-mmusic-sdp-cs (i.e. sending the correlation value as needed). The remote SIP element will receive the PSTN call, and correlate it with the existing SIP connection. Both parties must send audio on both the IP and the PSTN side, but the receivers can choose to play the audio coming from either the IP or PSTN connection (this is because we may want to use in the future fingerprint methods for the validation). The PSTN call is ended at the same time than the IP connection if the methods used for validation are based on the call duration (other methods may permit to end the call before), so the VCRs are processed as for an initial call. The local party marks the route as been under re-validation, so to not use the renewal method for the next 48 hours. The VIPR server will send a notification before the end of the 48 hours if there is still a PSTN route to this destination. B.8. Infrastructure overlays A new draft to discuss infrastructure overlays has been submitted to DISPATCH. "[RELOAD] is a peer to peer protocol developed by the P2PSIP Working Group. Each RELOAD instance has a unique name, which is used by the process in section 10.2 of this specification to find the configuration servers, enrollment servers and bootstrap servers needed to join the overlay. The process assumes that the RELOAD instance name is a FQDN, and uses the process in [RFC2782] (SRV RR) to find the IP address of the HTTPS server that serves the configuration document for this overlay. This process is adequate when the management of the overlay does not need to be distinguished from the owner of the FQDN used as the instance name, which is the case most of the time. But there is a special class of overlays that, by definition, requires to be unique on the Internet and for which having the possibility of create instances would defeat their very purpose. This specification calls the kind of overlays that are not domain specific, but application specific "infrastructure overlays". [VIPR] is a technology that is being standardized in the VIPR Working Group and that aims to build bridges between SIP islands by automatically provision SIP routes after the "ownership" of a PSTN phone number has been verified by an actual PSTN phone call. This technology uses an RELOAD overlay as a distributed database where mappings between phone numbers and servers responsible for the validation process are stored. The promise of VIPR to bridge these SIP islands cannot be fulfilled if there is more than one distributed database storing these mappings." - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6Nw0cACgkQ9RoMZyVa61fM1gCgg65SkwEgJvDIDofXD6mNOS6M BZcAnj7mFcoi/hYqaeqRH1cNBUs+aKZX =/W92 -----END PGP SIGNATURE----- From mperumal@cisco.com Fri Oct 7 04:46:47 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DA221F8ADC for ; Fri, 7 Oct 2011 04:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=-3.784, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+IBcYSbcmm5 for ; Fri, 7 Oct 2011 04:46:46 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 68AA921F893C for ; Fri, 7 Oct 2011 04:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3346; q=dns/txt; s=iport; t=1317988200; x=1319197800; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=5sY4Fj/CwB0HbRYiY644c4EM+3Qmh/Rpft/CH7YH9Go=; b=h3GhlZAp2EKP5a9AmXeuAAmLQ+ew6oJ9VBKClyzKrrmgxMZcdaRf9dds jWAFtn1nPaTcCk+OtghhDg0Qj7MjSdzEj0KAFu9UiD3vhbCJNCgVSwyLu fbLv8PZagZYpp1kCGiq0h9bIHn7PfLa1NTAS+IjQsfoTHiQ0FJr5/hMZC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoAAKHmjk5Io8UQ/2dsb2JhbABEhHSUKo4ke4EFgVMBAQEBAxIBEA0ERQwEAgEIEQQBAQMCBgYXAQICAgEBRAkIAQEECwgIGodjmUsBjEaRZ4EthHAzYQSHe5EljB8 X-IronPort-AV: E=Sophos;i="4.68,502,1312156800"; d="scan'208";a="531244" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-3.cisco.com with ESMTP; 07 Oct 2011 11:49:55 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p97Bnrlr029239; Fri, 7 Oct 2011 11:49:54 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 17:19:44 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 7 Oct 2011 17:19:42 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202068FE74D@XMB-BGL-414.cisco.com> In-Reply-To: <4E89E235.6000908@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for 2011/09/23 Thread-Index: AcyB6TyodF4BuZMsRJm8pRFNS5iy0wC+oFqg References: <4E7B5199.5000409@petit-huguenin.org> <3175C4C5F682C145B25808EB5737F16C0ECA7F83@xmb-sjc-21b.amer.cisco.com> <1D062974A4845E4D8A343C653804920206805382@XMB-BGL-414.cisco.com> <4E89E235.6000908@acm.org> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Marc Petit-Huguenin" X-OriginalArrivalTime: 07 Oct 2011 11:49:44.0535 (UTC) FILETIME=[34D15E70:01CC84E7] Cc: vipr@ietf.org Subject: Re: [VIPR] Agenda for 2011/09/23 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 11:46:47 -0000 SGkgTWFyaywNCg0KfFdoZW4gYW4gZW50ZXJwcmlzZSB1c2VzIGEgcHJvdmlkZXIsIGl0IGlzIHBh eWluZyBmb3IgDQp8dGhlIHNlcnZpY2Ugb2Ygcm91dGluZyB0aGUgY2FsbHMgdG8gdGhlIFBTVE4s IHNvIHdoeQ0KfGFkdmVydGl6aW5nIHRoZSBudW1iZXIgaW4gdGhlIFZJUFIgb3ZlcmxheSBjb3Vs ZCBub3QgDQp8YmUgcGFydCBvZiB0aGlzIGNvc3Q/DQoNClN1cmUsIGlmIGl0IGFkZHMgdmFsdWUg dG8gdGhlIGVudGVycHJpc2UgYW5kIHRoZSBwcm92aWRlciBjYW4gbW9uZXRpemUgaXQsIEkgc2Vl IG5vIGlzc3VlIChpdCBjb3VsZCBiZSBhIHByb3ZpZGVyIGhvc3RlZCBWaVBSIHNlcnZpY2UsIGZv ciBlLmcpLiBBdCB0aGUgZmlyc3QgbGV2ZWwsIHRoZSBlbnRlcnByaXNlIG1pZ2h0IHdhbnQgdG8g cmVxdWlyZSB0aGF0IHRoZSBwcm92aWRlciBwdWJsaXNoZWQgcm91dGUgYmUgZWFzaWx5IGRpc3Rp bmd1aXNoYWJsZSBmcm9tIHRoZSBlbnRlcnByaXNlIHB1Ymxpc2hlZCByb3V0ZSwgc28gdGhhdCBp ZiBib3RoIHJvdXRlcyBhcmUgYXZhaWxhYmxlIGZvciBzb21lb25lIGNhbGxpbmcgaW50byB0aGUg ZW50ZXJwcmlzZSB0aGV5IGNhbiBjaG9zZSBvbmUgYW1vbmcgdGhlbS4gSSB0aGluayBpbiB0aGUg bWFqb3JpdHkgb2YgY2FzZXMgb25lIHdvdWxkIHByZWZlciBhIGRpcmVjdCByb3V0ZSwgdW5sZXNz IHRoZSBwcm92aWRlciBvZmZlcnMgZGlmZmVyZW50aWF0ZWQgc2VydmljZXMgbGlrZSBhdWRpby92 aWRlbyB0cmFuc2NvZGluZywgcmF0ZSBhZGFwdGlvbiwgZWNobyBjYW5jZWxsYXRpb24gZXRjIHRo YXQgYSBkaXJlY3Qgcm91dGUgZG9lc24ndCBoYXZlLg0KDQpNdXRodQ0KDQp8LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCnxGcm9tOiBNYXJjIFBldGl0LUh1Z3VlbmluIFttYWlsdG86cGV0aXRo dWdAYWNtLm9yZ10NCnxTZW50OiBNb25kYXksIE9jdG9iZXIgMDMsIDIwMTEgOTo1NiBQTQ0KfFRv OiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KfENjOiB2aXByQGlldGYub3Jn DQp8U3ViamVjdDogUmU6IEFnZW5kYSBmb3IgMjAxMS8wOS8yMw0KfA0KfC0tLS0tQkVHSU4gUEdQ IFNJR05FRCBNRVNTQUdFLS0tLS0NCnxIYXNoOiBTSEExDQp8DQp8SGkgTXV0aHUsDQp8DQp8T24g MDkvMjgvMjAxMSAxMToxMCBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkg d3JvdGU6DQp8PiBBIGZ1bmRhbWVudGFsIHF1ZXN0aW9uOiBXaHkgd291bGQgYSBwcm92aWRlciB3 YW50IHRvIGFkdmVydGlzZSByb3V0ZXMgZm9yIGENCnw+IG51bWJlciBmb3Igd2hpY2ggbmVpdGhl ciBvZiB0aGUgZW50ZXJwcmlzZXMgaXMgd2lsbGluZyB0byBwYXkgZm9yPw0KfA0KfEkgYW0gbm90 IHN1cmUgd2h5IHlvdSBhcmUgc2F5aW5nIHRoYXQuICBXaGVuIGFuIGVudGVycHJpc2UgdXNlcyBh IHByb3ZpZGVyLCBpdA0KfGlzIHBheWluZyBmb3IgdGhlIHNlcnZpY2Ugb2Ygcm91dGluZyB0aGUg Y2FsbHMgdG8gdGhlIFBTVE4sIHNvIHdoeSBhZHZlcnRpemluZw0KfHRoZSBudW1iZXIgaW4gdGhl IFZJUFIgb3ZlcmxheSBjb3VsZCBub3QgYmUgcGFydCBvZiB0aGlzIGNvc3Q/DQp8DQp8PiBJc24n dCBWaVBSIGJhc2VkIG9uIHRoZSBmYWN0IHRoZSBwcm92aWRlciBpcyB0cnVzdGVkIGZvciB0aGUg Zmlyc3QgKFBTVE4pDQp8PiBjYWxsPyBJZiB0aGUgcHJvdmlkZXIgaXMgZm9vbGluZyB3aXRoIHRo ZSBlbnRlcnByaXNlLCB3b24ndCB0aGUgZW50ZXJwcmlzZQ0KfD4gc3dpdGNoIHRvIGEgZGlmZmVy ZW50IHByb3ZpZGVyPyBPciBhcmUgd2UgY29uY2VybmVkIGFib3V0IHRoZSBzZWN1cml0eQ0KfD4g aW1wbGljYXRpb25zIGFyb3VuZCByb3V0aW5nIHN1YnNlcXVlbnQgY2FsbHMgdGhyb3VnaCB0aGUg cHJvdmlkZXI/IEFyZW4ndA0KfD4gdGhleSBhcHBsaWNhYmxlIHRvIHRoZSBmaXJzdCBjYWxsIGFz IHdlbGw/DQp8Pg0KfD4gSWYgdGhlIGVudGVycHJpc2UgZG9lc24ndCB0cnVzdCB0aGUgcHJvdmlk ZXIgdGhlbiBWaVBSIGluIGl0cyBjdXJyZW50IGZvcm0NCnw+IGRvZXNuJ3Qgc2VlbSB0byBtYWtl IHNlbnNlLg0KfD4NCnw+IE11dGh1DQp8DQp8LSAtLQ0KfE1hcmMgUGV0aXQtSHVndWVuaW4NCnxQ ZXJzb25hbCBlbWFpbDogbWFyY0BwZXRpdC1odWd1ZW5pbi5vcmcNCnxQcm9mZXNzaW9uYWwgZW1h aWw6IHBldGl0aHVnQGFjbS5vcmcNCnxCbG9nOiBodHRwOi8vYmxvZy5tYXJjLnBldGl0LWh1Z3Vl bmluLm9yZw0KfC0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQp8VmVyc2lvbjogR251UEcg djEuNC4xMSAoR05VL0xpbnV4KQ0KfA0KfGlFWUVBUkVDQUFZRkFrNko0alFBQ2drUTlSb01aeVZh NjFjTCtRQ2ZUWWJsY1M1Q1lBZld5SnRFZ3dFVXBkUVgNCnxwZm9BbmlIbndvaEVrbFBaTW5kS3NP Y0E2d28rM0lYcg0KfD1BUzZqDQp8LS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo= From mperumal@cisco.com Fri Oct 7 04:51:03 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7F121F8B3F for ; Fri, 7 Oct 2011 04:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.068 X-Spam-Level: X-Spam-Status: No, score=-9.068 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_00=-2.599, MANGLED_TEXT=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHuWdmIVEEHd for ; Fri, 7 Oct 2011 04:51:02 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8A821F8B3E for ; Fri, 7 Oct 2011 04:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2880; q=dns/txt; s=iport; t=1317988455; x=1319198055; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=DHsPIEuMLCUYPwoRYB4PZdBAeC8SPTum3/hQSf9I+2w=; b=IoWussTIbZ5gT+Cwq3n/WBxY+Ue5jzkTBOT2FGXzYCFQHkQ1FBxdnSTf fwjKvSShOAZXS27xdmxvxZUR8Okn+BCbsa3Twp2HZE5idu9mHOr52etuT WtsEkILwMxk37zUxU6gzoodRXUo+UWxOgEhoGce/KU7pyoCF6LraWnum4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoAAAvojk5Io8UT/2dsb2JhbABEmR6PH4EFgVMBAQEBAwEBAQ8BHQouBhcEAgEIEQQBAQsGFwEGASYfCQgBAQQBCggIGodjmU0Bni6GUGEEh3uRJYwf X-IronPort-AV: E=Sophos;i="4.68,502,1312156800"; d="scan'208";a="57309161" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 07 Oct 2011 11:54:13 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p97Bs6j6014008; Fri, 7 Oct 2011 11:54:13 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 17:24:13 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Oct 2011 17:24:11 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202068FE751@XMB-BGL-414.cisco.com> In-Reply-To: <4E89F095.3070301@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [VIPR] A new proposal for SIP Intermediaries Thread-Index: AcyB8czKM4oEiRI3RLu59/mKIC42sgC9YtJg References: <4E89F095.3070301@acm.org> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Marc Petit-Huguenin" , X-OriginalArrivalTime: 07 Oct 2011 11:54:13.0186 (UTC) FILETIME=[D4F24220:01CC84E7] Subject: Re: [VIPR] A new proposal for SIP Intermediaries X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 11:51:03 -0000 I agree with this proposal. Muthu |-----Original Message----- |From: vipr-bounces@ietf.org [mailto:vipr-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin |Sent: Monday, October 03, 2011 10:58 PM |To: vipr@ietf.org |Subject: [VIPR] A new proposal for SIP Intermediaries | |-----BEGIN PGP SIGNED MESSAGE----- |Hash: SHA1 | |For the second time, the Design Team conference call got stuck on the subject of |SIP intermediaries in VIPR, and we were not able to make any progress on the |VIPR specifications themselves. I was supposed to send another email to this |mailing-list to describe in more details the problems created by SIP |intermediaries but I fear that the next conference calls will still being spent |arguing about this. So I would like to propose an alternate route to solve this |issue. | |SIP intermediaries are not described at all in the current specifications, but I |think that everybody agree that we should say something about it, because it |will become a reality, even if we decide to make it a SHOULD NOT (which would |exclude a lot of potential participants from the VIPR federation). On the other |hand, VIPR domains does not require SIP intermediaries to work. | |So my proposal is: | |1. Put everything related to SIP intermediaries in a separate I-D, so it does |not hold the main specifications. |2. Add in the main specifications the "hooks" required to be able to add support |for SIP intermediaries as an extension in the future (as opposed to have to work |on a new version of the VIPR RFCs to add SIP intermediaries, which will push |back the deployment of SIP intermediaries for another 3 years). |3. Add a new milestone for the SIP intermediaries (I would suggest April 2012[1]) | |Please let me know as soon as possible if you agree with this new plan, at least |on the two first points, so I can release the first version of the new |draft-petithuguenin-vipr-sip-intermediaries I-D, and so we can move one on the |other subjects that are actually blocking the work on -framework. | |Thanks. | | |[1] And I would also suggest to move at the same time the "Submit Specification |of authorization tokens to mitigate SPAM for publication as Proposed Standard" |to December 2011, as it make sense to submit this at the same time than the |other core VIPR specifications. | |- -- |Marc Petit-Huguenin |Personal email: marc@petit-huguenin.org |Professional email: petithug@acm.org |Blog: http://blog.marc.petit-huguenin.org |-----BEGIN PGP SIGNATURE----- |Version: GnuPG v1.4.11 (GNU/Linux) | |iEYEARECAAYFAk6J8JMACgkQ9RoMZyVa61ckLQCgpM/sND37krkNZRPWrQt4deHF |dRMAnAmG7FZFFaIU7xNC+oHUIChQGU/C |=3Dt3x7 |-----END PGP SIGNATURE----- |_______________________________________________ |VIPR mailing list |VIPR@ietf.org |https://www.ietf.org/mailman/listinfo/vipr From petithug@acm.org Fri Oct 7 06:48:06 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA1C21F8B10 for ; Fri, 7 Oct 2011 06:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.202 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZh5kUDe8G8J for ; Fri, 7 Oct 2011 06:48:01 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 291AC21F8B15 for ; Fri, 7 Oct 2011 06:48:01 -0700 (PDT) Received: from [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08] (unknown [IPv6:2001:5c0:1111:4e00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 43B6420892; Fri, 7 Oct 2011 13:44:06 +0000 (UTC) Message-ID: <4E8F03CE.9000504@acm.org> Date: Fri, 07 Oct 2011 06:51:10 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111005 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <4E7B5199.5000409@petit-huguenin.org> <3175C4C5F682C145B25808EB5737F16C0ECA7F83@xmb-sjc-21b.amer.cisco.com> <1D062974A4845E4D8A343C653804920206805382@XMB-BGL-414.cisco.com> <4E89E235.6000908@acm.org> <1D062974A4845E4D8A343C6538049202068FE74D@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202068FE74D@XMB-BGL-414.cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: vipr@ietf.org Subject: Re: [VIPR] Agenda for 2011/09/23 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 13:48:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/07/2011 04:49 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: > Hi Mark, > > |When an enterprise uses a provider, it is paying for |the service of routing > the calls to the PSTN, so why |advertizing the number in the VIPR overlay > could not |be part of this cost? > > Sure, if it adds value to the enterprise and the provider can monetize it, I > see no issue (it could be a provider hosted ViPR service, for e.g). At the > first level, the enterprise might want to require that the provider published > route be easily distinguishable from the enterprise published route, so that > if both routes are available for someone calling into the enterprise they can > chose one among them. I think in the majority of cases one would prefer a > direct route, unless the provider offers differentiated services like > audio/video transcoding, rate adaption, echo cancellation etc that a direct > route doesn't have. Yes, but the difficulty here is how to choose this route. The proposal sent by Hakim, i.e. sending the capabilities of the endpoint together with the SIP route and ticket, would permit this, as only the VIPR domain the closest to the end user would be able to send the real capabilities of the endpoint (extracted for example from the SIP registrar). The transcoding is interesting, as an intermediary using it could eventually claim to better route than the direct route. Perhaps what we need is a new media feature tag that would indicate that a capability set is "native" (i.e. built directly from the SIP registrar or information coming from the endpoint), instead of been from a intermediate media point, like transcoding. > > Muthu > > |-----Original Message----- |From: Marc Petit-Huguenin > [mailto:petithug@acm.org] |Sent: Monday, October 03, 2011 9:56 PM |To: Muthu > Arul Mozhi Perumal (mperumal) |Cc: vipr@ietf.org |Subject: Re: Agenda for > 2011/09/23 | |-----BEGIN PGP SIGNED MESSAGE----- |Hash: SHA1 | |Hi Muthu, | > |On 09/28/2011 11:10 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: |> A > fundamental question: Why would a provider want to advertise routes for a |> > number for which neither of the enterprises is willing to pay for? | |I am > not sure why you are saying that. When an enterprise uses a provider, it |is > paying for the service of routing the calls to the PSTN, so why advertizing > |the number in the VIPR overlay could not be part of this cost? | |> Isn't > ViPR based on the fact the provider is trusted for the first (PSTN) |> call? > If the provider is fooling with the enterprise, won't the enterprise |> > switch to a different provider? Or are we concerned about the security |> > implications around routing subsequent calls through the provider? Aren't |> > they applicable to the first call as well? |> |> If the enterprise doesn't > trust the provider then ViPR in its current form |> doesn't seem to make > sense. |> |> Muthu | - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6PA80ACgkQ9RoMZyVa61c9VACfXlY5MEOhkpMRBj8/p+p28YNq ES8AnAuNKvjboXam6uPVpsUZzVK2Oi5S =G59i -----END PGP SIGNATURE----- From dean.willis@softarmor.com Fri Oct 7 09:19:58 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E53921F8BF3 for ; Fri, 7 Oct 2011 09:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.34 X-Spam-Level: X-Spam-Status: No, score=-103.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkjNBhrbO4nL for ; Fri, 7 Oct 2011 09:19:57 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 904A021F8AEE for ; Fri, 7 Oct 2011 09:19:57 -0700 (PDT) Received: by ggnk3 with SMTP id k3so3548067ggn.31 for ; Fri, 07 Oct 2011 09:23:11 -0700 (PDT) Received: by 10.150.238.18 with SMTP id l18mr1639573ybh.335.1318004590857; Fri, 07 Oct 2011 09:23:10 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id m10sm25911151ang.12.2011.10.07.09.23.09 (version=SSLv3 cipher=OTHER); Fri, 07 Oct 2011 09:23:09 -0700 (PDT) Message-ID: <4E8F276B.5090200@softarmor.com> Date: Fri, 07 Oct 2011 11:23:07 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: vipr@ietf.org References: <4E7B5199.5000409@petit-huguenin.org> <3175C4C5F682C145B25808EB5737F16C0ECA7F83@xmb-sjc-21b.amer.cisco.com> <1D062974A4845E4D8A343C653804920206805382@XMB-BGL-414.cisco.com> <4E89E235.6000908@acm.org> <1D062974A4845E4D8A343C6538049202068FE74D@XMB-BGL-414.cisco.com> <4E8F03CE.9000504@acm.org> In-Reply-To: <4E8F03CE.9000504@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [VIPR] Agenda for 2011/09/23 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 16:19:58 -0000 On 10/7/11 8:51 AM, Marc P > Yes, but the difficulty here is how to choose this route. The proposal sent by > Hakim, i.e. sending the capabilities of the endpoint together with the SIP route > and ticket, would permit this, as only the VIPR domain the closest to the end > user would be able to send the real capabilities of the endpoint (extracted for > example from the SIP registrar). The transcoding is interesting, as an > intermediary using it could eventually claim to better route than the direct > route. Perhaps what we need is a new media feature tag that would indicate that > a capability set is "native" (i.e. built directly from the SIP registrar or > information coming from the endpoint), instead of been from a intermediate media > point, like transcoding. If we create a situation where there is an incentive for an intermediary to mis-state a capability set in order to "capture" more revenue-generating traffic, then the intermediaries are going to lie like politicians seeking re-election. I think this is a MUCH harder problem than we currently realize. Even Hakim's proposal requires that route-validation also validate the offered capabilities, not just evaluate them and choose the richest set. This is hard; a motivated intermediary could probably convince a test-bot that it is the target instead of an intermediary. -- Dean From petithug@acm.org Mon Oct 10 08:28:10 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E87B21F8C42 for ; Mon, 10 Oct 2011 08:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.374 X-Spam-Level: X-Spam-Status: No, score=-98.374 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, NO_RELAYS=-0.001, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vENpRBVstaO for ; Mon, 10 Oct 2011 08:28:09 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 895CC21F8BCB for ; Mon, 10 Oct 2011 08:28:09 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6E35D2025C for ; Mon, 10 Oct 2011 15:20:48 +0000 (UTC) Message-ID: <4E930F06.9040304@acm.org> Date: Mon, 10 Oct 2011 08:28:06 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111005 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Minutes for 2011/10/07 conference call X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 15:28:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 VIPR Design Team conference call on Friday October 7th, from 9:05am to 9:55am PST. o Attendees: Mary Barnes Daryl Malas Hakim Mehmood Muthu Arul Mozhi Perumal Jon Peterson Marc Petit-Huguenin Michael Procter John Ward Dean Willis o Agenda - - Move SIP intermediaries in a future draft (5 min) - - RELOAD registration (5 min) - - Replacement ticket by client certificate (10 min) - - PVP privacy (10 min) - - PVP method priority and registration (10 min) - - PVP method entropy (10 min) - - Ticket renewal (10 min) - - Infrastructure overlays (5 min) o Action items - - Treat SIP interworking as an extension. - - Remove the text saying that the phone number must be stored 3 times at the VIPR level. - - Explain the problem and requirements for the ticket mechanism. o Minutes - - Move SIP intermediaries in a future draft Marc: The proposal is to treat SIP intermediaries as an extension to VIPR, in a separate draft, but to be sure that we have the required hooks in the VIPR drafts to not have to modify VIPR later. The last part of the proposal is to add a milestone for this after finishing the work on the base VIPR. Jon: The viability of this proposal would depends on what the hooks are. Second I would be careful to not put this in term of SIP intermediaries, a more generic problem is inter-working. But I am really interested on what the hooks are. Marc: I do not know what the hooks would be. I just published what the problem is, as I said I would do in the previous meeting. I will release another version that will contain multiple solutions and we can see from here what the hooks will be, if there is any needed. Dean: If we are going to place a lot of requirements, it becomes a location server. It's a simple lookup operation. Jon: Documenting the hooks in the intermediary draft is one thing but the hooks will be in the base draft, we need to be clear on this. We need to not scope this work too narrowly. Marc: Do we agree to work on this later? Mary: Yes. Dean: I disagree slightly with Jon. One hop is straightforward, but more raises a set of transitive trust issues. Jon: If we have two overlays then we have a disaster. Keep the milestone high level. - - RELOAD registration Marc: The current spec is saying that each phone number is registered 3 times, which with the normal RELOAD replication, means that it is stored 9 times. So the question was what to do when there is a difference between the copies retrieved. The proposal was to require to have at least two identical copies. But the discussion moved to why do we require 3 copies in the first place. So the next proposal was to store the phone number one time, to verify that there was 3 identical replicas, and to use the voting algorithm when retrieved. Hakim: What does identical mean? Marc: Which return the same Node-ID. The idea is that a rogue peer should not prevent PVP to work. But the discussion was more about the requirement of having 3 copies at the VIPR level. Hakim: Does it really mater? The data in the overlay is not trusted. Marc: Do we want to say that all nodes need to register 3 times or keep it simple, i.e. one time? It does not make a difference when storing, but the nodes that will fetch need to know the number of copies. One way it can be solved is to put a parameter in the configuration file that indicate the number of copies at the VIPR level. Jon: Did we ever find why there was 3 copies? Hakim: That was to increase the security - I am not sure. Michael: It is easy to retrieve the replica? Marc: Yes, what you do is that you put the Node-ID of the successor in the Fetch request, instead of using just the Resource-ID. Michael: If the first node is compromised, why should I trust it to give me the successor? Marc: An excellent question, but more of a RELOAD problem. Michael: So RELOAD protects against network outages, no malicious nodes. So to go back to Jon's point, we will validate any request anyway because we do not trust anything from RELOAD. Hakim: Yes, the idea was to protect in case a copy is lost. Jon: OK, so just need one copy. Hakim: It does not matter for an application point of view. Jon: It is related to the SIP intermediaries. Hakim: No its a dictionary storage. Also having multiple copies permits to increase the trust in a copy. Marc: So one proposal would be to add a variable ion the configuration file that contain the number of copies at the VIPR level. Michael: I am reluctant to add a configuration variable. I do not think we need to replicate at the VIPR level, because we will verify everything we get. Marc: OK so everybody agree to remove the duplication at the VIPR level. - - Replacement ticket by client certificate Marc: The first problem with the ticket is that the ticket is signed using a symmetrical key, key that need to be shared between the PVP server and the call agent. The second problem is that the ticket is separated from the TLS certificate, so you have to validate the TLS connection, then verify the ticket. Another problem is that there is not existing proven code for processing the ticket. So the idea is to replace the ticket by an X.509 certificate, which already contains all the fields required by the ticket, can use asymmetrical keys, and has existing proven libraries. Jon: This is a significant change, and we would need more time. We should not diverge too much from what SIP is doing. TLS is not use much so pushing all the security features into TLS might not be a guarantee of widespread success. How do you push this certificate onto systems that want to use it, and how do you capture the parameters of the call so that you verify that it is the right person you are talking to. Marc: To push the certificate, you just send it instead of the ticket. As for the significant change, I will publish code that shows that it is less work to use a certificate than a ticket. Hakim: If sharing the secret is a concern, we should consider diverging? Marc: It is a concern for me. Jon: It's unclear to me why you need to share the symmetrical key. The proxy could just pass the ticket to the element that can verify it. Michael: A middle ground would be to use public keys to sign the ticket. Marc: It's not like there is 100's of implementations that need to be modified. Hakim: I agree with Jon that keeping the semantics of SIP is important. If that means changing whatever Cisco implemented, it is fine. Marc: A certificate is not that different from a ticket using asymmetrical keys. Hakim: If it falls within regular TLS, then OK. Jon: If the symmetrical key is the problem, then we need to go back to the requirements. This proposal is worth considering, but there is a huge space of solutions that can be considered. Marc: One problem is that in the current version of VAP there is no possibility to verify the ticket at another place than on the call agent. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6TDwQACgkQ9RoMZyVa61e7bgCdHV+MWYw7kK+2sPY/0/CfIo6A 6wAAnjrrsEj7RSlRj3zgBaM1hJ1jA0zL =3Pch -----END PGP SIGNATURE----- From petithug@acm.org Tue Oct 11 12:07:22 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C3921F8E63 for ; Tue, 11 Oct 2011 12:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.487 X-Spam-Level: X-Spam-Status: No, score=-100.487 tagged_above=-999 required=5 tests=[AWL=2.113, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwbdhG5ioMUO for ; Tue, 11 Oct 2011 12:07:22 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 30A3D21F8E44 for ; Tue, 11 Oct 2011 12:07:22 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6CAC4204AD; Tue, 11 Oct 2011 18:59:56 +0000 (UTC) Message-ID: <4E9493E6.8000804@acm.org> Date: Tue, 11 Oct 2011 12:07:18 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Dean Willis References: <4E7B5199.5000409@petit-huguenin.org> <3175C4C5F682C145B25808EB5737F16C0ECA7F83@xmb-sjc-21b.amer.cisco.com> <1D062974A4845E4D8A343C653804920206805382@XMB-BGL-414.cisco.com> <4E89E235.6000908@acm.org> <1D062974A4845E4D8A343C6538049202068FE74D@XMB-BGL-414.cisco.com> <4E8F03CE.9000504@acm.org> <4E8F276B.5090200@softarmor.com> In-Reply-To: <4E8F276B.5090200@softarmor.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: vipr@ietf.org Subject: Re: [VIPR] Agenda for 2011/09/23 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:07:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/07/2011 09:23 AM, Dean Willis wrote: > On 10/7/11 8:51 AM, Marc P >> Yes, but the difficulty here is how to choose this route. The proposal sent by >> Hakim, i.e. sending the capabilities of the endpoint together with the SIP route >> and ticket, would permit this, as only the VIPR domain the closest to the end >> user would be able to send the real capabilities of the endpoint (extracted for >> example from the SIP registrar). The transcoding is interesting, as an >> intermediary using it could eventually claim to better route than the direct >> route. Perhaps what we need is a new media feature tag that would indicate that >> a capability set is "native" (i.e. built directly from the SIP registrar or >> information coming from the endpoint), instead of been from a intermediate media >> point, like transcoding. > > > If we create a situation where there is an incentive for an intermediary to > mis-state a capability set in order to "capture" more revenue-generating > traffic, then the intermediaries are going to lie like politicians seeking > re-election. > > I think this is a MUCH harder problem than we currently realize. > > Even Hakim's proposal requires that route-validation also validate the offered > capabilities, not just evaluate them and choose the richest set. This is hard; a > motivated intermediary could probably convince a test-bot that it is the target > instead of an intermediary. Perhaps one way to solve this would be to lower the priority of a route if a subsequent SIP call made using it does not match the capabilities advertized. It could also be done with an OPTIONS, but the response can also be faked. It's a little bit more difficult to fake the actual video (I suppose that wideband audio can be faked by resampling the narrowband signal). - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6Uk+UACgkQ9RoMZyVa61fr6QCfWdjxaiKUBeHoFBu9xs54aWK0 98cAn3miNyYPjcpZZhCMQ0lBmVSCFoC1 =mZo4 -----END PGP SIGNATURE----- From dean.willis@softarmor.com Wed Oct 12 10:40:32 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B986C21F8D0E for ; Wed, 12 Oct 2011 10:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.855 X-Spam-Level: X-Spam-Status: No, score=-102.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sQTd49h1Jvy for ; Wed, 12 Oct 2011 10:40:32 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D574521F8CFE for ; Wed, 12 Oct 2011 10:40:31 -0700 (PDT) Received: by ywm3 with SMTP id 3so289805ywm.31 for ; Wed, 12 Oct 2011 10:40:31 -0700 (PDT) Received: by 10.146.181.41 with SMTP id d41mr18977yaf.11.1318441231419; Wed, 12 Oct 2011 10:40:31 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id k31sm8001864ann.15.2011.10.12.10.40.28 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 10:40:29 -0700 (PDT) Message-ID: <4E95D10B.10203@softarmor.com> Date: Wed, 12 Oct 2011 12:40:27 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4E7B5199.5000409@petit-huguenin.org> <3175C4C5F682C145B25808EB5737F16C0ECA7F83@xmb-sjc-21b.amer.cisco.com> <1D062974A4845E4D8A343C653804920206805382@XMB-BGL-414.cisco.com> <4E89E235.6000908@acm.org> <1D062974A4845E4D8A343C6538049202068FE74D@XMB-BGL-414.cisco.com> <4E8F03CE.9000504@acm.org> <4E8F276B.5090200@softarmor.com> <4E9493E6.8000804@acm.org> In-Reply-To: <4E9493E6.8000804@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vipr@ietf.org Subject: Re: [VIPR] Agenda for 2011/09/23 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:40:32 -0000 On 10/11/11 2:07 PM, Marc Petit-Huguenin wrote: > Perhaps one way to solve this would be to lower the priority of a route if a > subsequent SIP call made using it does not match the capabilities advertized. > It could also be done with an OPTIONS, but the response can also be faked. It's > a little bit more difficult to fake the actual video (I suppose that wideband > audio can be faked by resampling the narrowband signal). My local broadcaster sends a lot of fake HDTV by just upsampling the SD signal. The problem is that a transit provider might get "greedy" and advertise capabilities they can't deliver in order to get more traffic. But the ability of a route to support a capability says nothing about what capability the called party might allow on a given call, so a caller can't just deprioritize a route when a completed call receives less capability than the route advertised. Nor can the called party withdraw validation support for a route just because it receives low-capability calls over that route, because the callers themselves might have low capabilities (or desires). Essentially, we're trying to detect a MITM "capability bid-down" attack. This might be a generic SIP problem, not just a ViPR problem, although we could perhaps use ViPR to help cure it. If we had a way for the caller to securely express the capabilities that the route is offering, then the callee could compare those capabilities to what it thinks the route should be offering, and thereby filter out "bad" routes. However, every attempt I make to solve this falls into "but the greedy intermediary could fake it" because they have access to the only actual authentication data in the system. It's a catch-22; by giving a transit provider access to your call verification data, you give them the keys to the city. The only answer I have so far is that one could audit the routes pointing at oneself and get upset about bogus/misleading entries. -- Dean From petithug@acm.org Wed Oct 12 15:53:38 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F367421F8AFB for ; Wed, 12 Oct 2011 15:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.544 X-Spam-Level: X-Spam-Status: No, score=-101.544 tagged_above=-999 required=5 tests=[AWL=1.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyC32v63h2m6 for ; Wed, 12 Oct 2011 15:53:36 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9728F21F8AF9 for ; Wed, 12 Oct 2011 15:53:36 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 5D82620595 for ; Wed, 12 Oct 2011 22:46:05 +0000 (UTC) Message-ID: <4E961A6B.2090603@acm.org> Date: Wed, 12 Oct 2011 15:53:31 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "vipr@ietf.org" References: <4E627AB4.7070806@acm.org> In-Reply-To: <4E627AB4.7070806@acm.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [VIPR] An alternative to the VIPR ticket X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 22:53:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 During the last conference call, this proposal was criticized as been a significant change from the way SIP is processing TLS requests. My research shows that it is not the case. First of all, let's define exactly what SIP, without even talking about VIPR, is doing regarding TLS. The best place for this is RFC 5922. We can skip the client behavior discussion (section 7.3) because neither VIPR or my proposal suggest any modification to this procedure. Here's what RFC 5922 says about the server behavior (aka client certificate): " When a server accepts a TLS connection, the server presents its own X.509 certificate to the client. Servers that wish to authenticate the client will ask the client for a certificate. If the client possesses a certificate, that certificate is presented to the server. If the client does not present a certificate, the client MUST NOT be considered authenticated. [...] When authenticating the client, the server MUST obtain the set of SIP domain identities from the client certificate as described in Section 7.1. Because the server accepted the TLS connection passively, unlike a client, the server does not possess an AUS for comparison. Nonetheless, server policies can use the set of SIP domain identities gathered from the certificate in Section 7.1 to make authorization decisions. For example, a very open policy could be to accept an X.509 certificate and validate the certificate using the procedures in RFC 5280 [6]. If the certificate is valid, the identity set is logged. Alternatively, the server could have a list of all SIP domains the server is allowed to accept connections from; when a client presents its certificate, for each identity in the client certificate, the server searches for the identity in the list of acceptable domains to decide whether or not to accept the connection. Other policies that make finer distinctions are possible." In other words, the SIP server (or proxy) does whatever it thinks is necessary with the client certificate, and it does not seems that even following RFC 5280 is required (note in particular that nowhere it is said that the validation must use a public trust anchor). VIPR itself adds very little to the requirements of RFC 5922. Here is what - -sip-antispam says about TLS and the ticket: " The Border Element will receive the TLS ClientHello which begins the TLS handshake. The Border Element will present its own configured cert. Once TLS handshaking is complete, the Border Element notes the domain from the SubjectAltName on the other side of the TLS connection, and associates it with that connection. Next, the Border Element will receive an INVITE. This INVITE will contain a ticket in the ViPR-Ticket header field value. The Border Element extracts this header field. This call flow assumes it is present. The Border Element parses it, and obtains the epoch value encoded in the ticket. This is matched against the current epoch value for the configured password. If they match, processing continues. The Border Element verifies the signature is correct. Next, it examines the start and stop time of the validity. If the current time is between the start and stop times, the check is passed. Next, the Border Element checks the granted-to domain in the ticket. It compares that domain against the domain name in the SubjectAltName of the peer on the other side of the TLS connection, as noted above. Next, it takes the Request-URI of the SIP INVITE. That will be of the form sip:+number@domain. If it is not in that form, and if the number does not begin with a plus, the request is dropped. The value, including the plus, is then compared to the number in the ticket. If it is equal, the check has passed. The Border Element leaves the header field in the request, but forwards to the Call Agent." The only policy that is added to what RFC 5922 says is that the granted-to domain in the ticket must be equal to the domain in the SubjectAltName of the client certificate. Here too, not a word about a public trust anchor. Now back to my proposal. The first thing is that the client certificate must be validated using the CA of the VIPR server as trust anchor, which is already what a SIP server could do. It validates according to the rules in RFC 5280, which is equivalent to verifying the signature of the ticket and the start/stop validity. The SubjectAltName in the client certificate (which is not even required to be used in standard SIP) can be checked against the domain part of the From header of the INVITE. The phone number and the granting-domain (which not even verified in VIPR) can be stored as an URI in the Issuer Alternative Name extension in the client certificate and be validated against the Request-URI of the INVITE. The granting node can be also be stored as a reload URI in an Issuer Alternative Name extension. So in conclusion, my proposal does not change what a normal SIP stack is doing, because the specification does not say what a SIP stack should do with a client certificate. (Note that to -sip-antispam should also be added some text saying that RFC 5923 must be used, because there is no way to create an additional TLS connection in the other direction for a subsequent SIP transaction). On 09/03/2011 12:06 PM, Marc Petit-Huguenin wrote: > In the current specification, the PVP server builds and signs a VIPR ticket, and > send it back to the PVP client, that passes it to the Call Agent/ Border Element > (CA/BE). The CA/BE will insert this ticket in the next SIP INVITE to the remote > CA/BE, which will check the validity of the ticket and the domain of the TLS client. > > There is multiple things that bother me with this process: > > - The verification of the ticket use HMAC-SHA1, and so the same password has to > be provisioned in both the CA/BE(s) (to verify the ticket) and the VIPR > server(s) (to generate the ticket). > - The ticket can be used without TLS (we all know that implementers think of > MUST as SHOULD and SHOULD as MAY). > > I would like to propose an alternative that is simpler to implement and, I > think, more secure than the ticket. > > Instead of using a symmetrical key, the local VIPR server generates an RSA key > pair, with the public key distributed to the CA/BE(s). After a successful PVP > connection, the remote PVP client sends a PKCS#10 certificate request, > containing the domain name and signed with a private key[1]. The local PVP > server generates a new certificate[2], sign it with its private key and send it > back to the remote PVP client, which pass it back to the remote CA/BE. > > The remote CA/BE will use the certificate received to establish the TLS > connection for the SIP transactions to the local CA/BE, which will use a > standard CA based certificate for its domain. The local CA/BE will be able to > verify with the VIPR public key that it issued the certificate, then will > validate the standard parts of the certificate (expiration date and so on). > > There is multiple advantages to this proposal: > > - The private key is stored only in the VIPR server, or better in a physical > token. > - VIPR does not work without TLS for the SIP connection. > - There is plenty of commercial or free TLS and X.509 implementations that have > years of experience and testing, which is not the case for the ticket proposal. > - Security agility is provided by TLS. > - No additional SIP Header. > - Because the ticket verification process is folded into the client certificate > verification, there is less resources needed. > > > [1] This is the private key of the CA/BE, so the CA/BE needs to upload the > PKCS#10 file in the VIPR server. Depending on the architecture used, each CA/BE > can use a different PKCS#10 or the same, which means that the PVP server must be > able to process more than one PKCS#10 and send back more than one certificate on > one PVP connection. > > [2] The certificate sent back can directly contain the SIP routes, increasing > the overall security. One possible mapping from the ValExchange response to the > certificate could be: > > - Unique ID: serialNumber > - Epoch: issuer > - salt: N/A > - integrity: signature > - Validity: validity > - Phone Number: subjectAltName uniformResourceIdentifier tel:+14085551234 > - Node-ID: subjectAltName uniformResourceIdentifier > reload://0110123456789ABCDEF0123456789ABCDEF/ > - Granted domain: subjectAltName dNSName example.com > - Granting domain: implicit in routes > - Route(s): subjectAltName uniformResourceIdentifier > sip:+14085551234@example.org:371;maddr=10.1.1.1 > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6WGmoACgkQ9RoMZyVa61dW3gCeMcKcsvqK27kk2ZW1mRMPYdep 3ZcAn3EIFv8hlBZop57YIDN7HCOUtixU =v31B -----END PGP SIGNATURE----- From michael@voip.co.uk Thu Oct 13 00:29:49 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FF021F87C5 for ; Thu, 13 Oct 2011 00:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQQCcNKSjSCX for ; Thu, 13 Oct 2011 00:29:48 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with SMTP id A8F8A21F8783 for ; Thu, 13 Oct 2011 00:29:47 -0700 (PDT) Received: from mail-vx0-f177.google.com ([209.85.220.177]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP; Thu, 13 Oct 2011 00:29:47 PDT Received: by mail-vx0-f177.google.com with SMTP id fl15so1098881vcb.36 for ; Thu, 13 Oct 2011 00:29:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.176.139 with SMTP id be11mr174850vcb.181.1318490986732; Thu, 13 Oct 2011 00:29:46 -0700 (PDT) Received: by 10.220.1.132 with HTTP; Thu, 13 Oct 2011 00:29:46 -0700 (PDT) In-Reply-To: <4E961A6B.2090603@acm.org> References: <4E627AB4.7070806@acm.org> <4E961A6B.2090603@acm.org> Date: Thu, 13 Oct 2011 08:29:46 +0100 Message-ID: From: Michael Procter To: Marc Petit-Huguenin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vipr@ietf.org" Subject: Re: [VIPR] An alternative to the VIPR ticket X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 07:29:49 -0000 On 12 October 2011 23:53, Marc Petit-Huguenin wrote: > During the last conference call, this proposal was criticized as been a > significant change from the way SIP is processing TLS requests. =A0My res= earch > shows that it is not the case. [...] > So in conclusion, my proposal does not change what a normal SIP stack is = doing, > because the specification does not say what a SIP stack should do with a = client > certificate. What you describe is that the server side of the connection will need to validate a client certificate whatever happens, and changing the ticket to a certificate does not substantively change the validation process. It does force the ticket validation to the edge of your network though, which having the ticket in a header field doesn't. Since ticket validation is a new process introduced with ViPR, this may be a reasonable change. However, what is overlooked in this analysis is that the client side must present a different certificate on a per-call basis. Most implementations that I have seen tend to have a fairly statically configured certificate (or several, but not lots) that is valid for the duration of the process/between scheduled maintenance. Having the certificate change on a per-call basis is a change for these implementations. How significant a change depends on their architecture, but it is a change nonetheless. Why does this matter? With the ViPR ticket in a header field, I can route ViPR traffic out in much the same way as I route other SIP traffic. Granted it has an additional header, but that doesn't substantively change the job my egress points perform. With a ViPR certificate instead of a ticket, my egress points need to be sufficiently ViPR-aware to know to use a dynamically selected certificate, and how to get hold of that certificate. Not insurmountable problems, but ones that are introduced by changing to a certificate over a simple header field. There may be other problems (Jon seemed to jump on the change quite fast so he may have more reasons), but this is the one that struck me. I think this change warrants wider discussion before deciding whether to adopt or not. Regards, Michael From petithug@acm.org Thu Oct 13 07:54:11 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F45721F8ADE for ; Thu, 13 Oct 2011 07:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.896 X-Spam-Level: X-Spam-Status: No, score=-101.896 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iR5c5lCGeFV4 for ; Thu, 13 Oct 2011 07:54:10 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9B97321F8A66 for ; Thu, 13 Oct 2011 07:54:10 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 9CF332087B; Thu, 13 Oct 2011 14:46:36 +0000 (UTC) Message-ID: <4E96FB8D.7030207@acm.org> Date: Thu, 13 Oct 2011 07:54:05 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Michael Procter References: <4E627AB4.7070806@acm.org> <4E961A6B.2090603@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: Re: [VIPR] An alternative to the VIPR ticket X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 14:54:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/13/2011 12:29 AM, Michael Procter wrote: > On 12 October 2011 23:53, Marc Petit-Huguenin wrote: >> During the last conference call, this proposal was criticized as been a >> significant change from the way SIP is processing TLS requests. My research >> shows that it is not the case. > [...] >> So in conclusion, my proposal does not change what a normal SIP stack is doing, >> because the specification does not say what a SIP stack should do with a client >> certificate. > > What you describe is that the server side of the connection will need > to validate a client certificate whatever happens, and changing the > ticket to a certificate does not substantively change the validation > process. It does force the ticket validation to the edge of your > network though, which having the ticket in a header field doesn't. > Since ticket validation is a new process introduced with ViPR, this > may be a reasonable change. > > However, what is overlooked in this analysis is that the client side > must present a different certificate on a per-call basis. Most > implementations that I have seen tend to have a fairly statically > configured certificate (or several, but not lots) that is valid for > the duration of the process/between scheduled maintenance. Having the > certificate change on a per-call basis is a change for these > implementations. How significant a change depends on their > architecture, but it is a change nonetheless. True. > > Why does this matter? With the ViPR ticket in a header field, I can > route ViPR traffic out in much the same way as I route other SIP > traffic. Granted it has an additional header, but that doesn't > substantively change the job my egress points perform. With a ViPR > certificate instead of a ticket, my egress points need to be > sufficiently ViPR-aware to know to use a dynamically selected > certificate, and how to get hold of that certificate. Not > insurmountable problems, but ones that are introduced by changing to a > certificate over a simple header field. Another argument to add to your point is that using a different certificate for each different phone number reduces the possibility of session caching or session resumption. > > There may be other problems (Jon seemed to jump on the change quite > fast so he may have more reasons), but this is the one that struck me. > I think this change warrants wider discussion before deciding whether > to adopt or not. OK, so I think that there is a way to keep the properties of the ticket (can be processed separately from the TLS server processing, does not require to dynamically choose the certificate on the client side), and still let "advanced" implementations not use this. The first step is to simply say that an X.509 certificate is a better replacement for the ticket as defined currently, independently to its usage in TLS: - - Existing and proven libraries. - - Support for asymmetrical keys. - - Security agility. With this first step, we use the X.509 certificate just like the current ticket, as a container to carry the parameters in the ticket. This means that the border element on the originating side establishes a TLS connection using a static client certificate, and then send an INVITE with a vipr-ticket header containing the X.509 certificate received from the PVP transaction and encoded in base64. The border element on the receiving side verifies the client certificate as per RFC 5280, then verifies the certificate inside the vipr-ticket (or pass it to another element to verify this second certificate). At this point we have exactly the same process than before, expected for the container used to carry the ticket values. Now let's add two very small modifications on the server processing side: - - The VIPR server CA is added to the list of public trust anchor that the TLS server uses to validate the client certificate. - - If there is no vipr-ticket in the INVITE, the client certificate received from the other side is used as if it was received in a vipr-ticket header field. With this, we now can have the TLS client choose to either work as a standard SIP client, i.e. it uses its static client certificate for the TLS connection, and put the certificate received from PVP in the vipr-ticket field, or work more dynamically, by using directly the certificate received from PVP as the client certificate for the TLS connection. On the server side all the processing can be done at one point, or it can have the ticket processing delegated to another server. This way we have the best of the two worlds. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6W+4sACgkQ9RoMZyVa61crEgCfeBmjMOtgbQ62tmcCfQXrzOH0 8FsAnj/lq24IXVOSv89MjHweoJLQwLCZ =WGHo -----END PGP SIGNATURE----- From petithug@acm.org Thu Oct 13 08:18:27 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949D821F8C12 for ; Thu, 13 Oct 2011 08:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.672 X-Spam-Level: X-Spam-Status: No, score=-99.672 tagged_above=-999 required=5 tests=[AWL=-1.872, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_SUMOF=5, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccGE5KNXy9GZ for ; Thu, 13 Oct 2011 08:18:26 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A288C21F8C0C for ; Thu, 13 Oct 2011 08:18:25 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id CEAFD2087B; Thu, 13 Oct 2011 15:10:51 +0000 (UTC) Message-ID: <4E97013D.7070804@acm.org> Date: Thu, 13 Oct 2011 08:18:21 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Dean Willis , "Hakim Mehmood (naim)" , Michael Procter , John Ward , 'Mary Barnes' , "Muthu Arul Mozhi Perumal (mperumal)" , Daryl Malas , Jon Peterson X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "vipr@ietf.org" Subject: [VIPR] Agenda & Handout for 2011/10/14 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 15:18:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A. Agenda - - Replacement ticket by client certificate (10 min) - - PVP method priority and registration (10 min) - - PVP privacy (10 min) - - PVP method entropy (10 min) - - Ticket renewal (10 min) - - Infrastructure overlays (5 min) Note that the sum of the time allocated to each topic exceeds the time allocated to the whole call. The topics that cannot make it to the discussion will be postponed to the next conference call if they are not subsequently decided in the mailing-list. Because the conference bridge as a limited capacity, an individual invitation to the conference will be sent shortly after this email to each member of the design team. Please send me an email if you are not on this list and want to receive an invitation. Note that the design team conference call is not a way to short-circuit the normal process, but a way to accelerate it by increasing face to face time. All decisions made must be confirmed on the mailing-list. This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). B. Handout (reading time: 10 min) B.1. Ticket vs Client certificate In the current specification, the PVP server builds and signs a VIPR ticket, and sends it back to the PVP client, which passes it to the SIP element. The SIP element will insert this ticket in the next SIP method to the remote SIP element, which will check the validity of the ticket and the domain of the TLS client. The problem with this process is that the verification of the ticket use HMAC-SHA1, and so the same password has to be provisioned in both the SIP element (to verify the ticket) and the PVP server (to generate the ticket). Also the ticket uses an adhoc format, for which no code currently exist, and there is no provision for security agility. So the proposal would be to replace the ticket by a client certificate, which could work like this: Instead of using a symmetrical key, the local PVP server generates an RSA key pair, with the public key distributed to the SIP element(s). After a successful PVP connection, the remote PVP client sends a PKCS#10 certificate request, containing the domain name and signed with a private key. The local PVP server generates a new certificate, sign it with its private key and send it back to the remote PVP client, which pass it back to the remote SIP element. The SubjectAltName contains the granted-by field, and the phone number and the granting-domain are stored as one URI in the Issuer Alternative Name extension, and the granting node is also be stored as a reload URI in another Issuer Alternative Name extension. With this first step, we use the X.509 certificate just like the current ticket, as a container to carry the parameters in the ticket. This means that the border element on the originating side establishes a TLS connection using a static client certificate, and then send an INVITE with a Vipr-Ticket header containing the X.509 certificate received from the PVP transaction and encoded in base64. The border element on the receiving side verifies the client certificate as per RFC 5280 (using public trust anchors), then verifies the certificate inside the Vipr-Ticket (or pass it to another element to verify this second certificate), using RFC 5280 with the PVP CA certificate as trust anchor and by using the same algorithm than currently. At this point we have exactly the same process than before, expected for the container used to carry the ticket values. Now let's add two very small modifications on the server processing side: - - The VIPR server CA is added to the list of public trust anchor that the TLS server uses to validate the client certificate. - - If there is no Vipr-Ticket in the INVITE, the client certificate received from the other side is used as if it was received in a Vipr-Ticket header field. With this, we now can have the TLS client choose to either work as a standard SIP client, i.e. it uses its static client certificate for the TLS connection, and put the certificate received from PVP in the Vipr-Ticket field, or work more dynamically, by using directly the certificate received from PVP as the client certificate for the TLS connection. On the server side all the processing can be done at one point, or it can have the ticket processing delegated to another server. B.2. PVP Methods Registry On the PVP subject, The VIPR specification currently defines two methods for the PSTN validation: Method "a", which is used when the Caller-ID is available and method "b", which is used when it is not. The PVP draft also permits to define new validation methods, but it does not explain when and how to use this extended methods. This proposal is in two parts. First we need to establish a IANA registry for the PVP methods, and to assign a priority to each of these methods. Let's say for now that the priority is between -∞ (lowest priority) to +∞ (highest priority) and that priorities should be assigned by steps of 100. With this scale we could assign priority 0 to method "b" and priority 100 to method "a". Then we say in the spec that a VIPR server must try available methods starting from the highest priority to the lowest priority, until one succeeds or all fail. This implements the same algorithm that is currently in -pvp ("a" first, then "b"). Now the problem with this is that the number of methods will increase in the future, but we may not want that the PVP client tries all the methods available each time. So the second part of this proposal is to have each VIPR domain publishing the list of methods supported by each of its phone numbers in the RELOAD distributed database, in the existing VIPR-REGISTRATION resource record. With this information, the PVP client immediately knows what methods to try from the VIPR-REGISTRATION record, and the order to try them from the IANA registry, and can also accumulate statistics on the usage of unsupported methods. The PVP server can use this mechanism to simplify the process. For example if it knows that it will never receive the Caller-ID, it just have to never advertize the "a" method. Another example is with analog FXO ports that cannot be used with either method "a" or "b". In this case the VIPR server can still advertize a new method using DTMF or fingerprint. Note that because the methods supported per phone number are stored in the RELOAD distributed database, the SIP call agent cannot retrieve them to decide what method to use when starting a call, as it would take too much time to retrieve it (same reason the validation is not done in real-time). But it can query them in the background using the history of calls or just before scheduling a re-validation. I would also propose to move the description of the generic PVP algorithm to the - -framework document, to add a section in -framework explaining how to register a new method on a IANA registry and to keep the two existing methods ("a" and "b") into the -pvp draft. B.3. PVP Privacy As reported by Michael Procter, there is ways with the current PVP methods to discover valuable information about a competitor. But first let's add some common vocabulary related to PVP: - - The PVP selector is a list of parameters that are sent by the PVP client side to retrieve a set of call records in the PVP server side. The resulting set can be empty, in which case the validation fails, can contain one element, or can contain multiple elements in which case the method description must also defines what call record should be selected (e.g. in the case of method "a", the most recent call record is selected). One important point is that the selector is always passed from the PVP client to the PVP server in clear, and so this is where the privacy leakage happens. - - The PVP parameter is a list of name/value pairs that are passed in clear between the PVP client and PVP server to aid the verification. Examples are the rounding value and the vservice id for methods "a" and "b". - - The PVP secret is the information that each side of the PVP transaction tries to verify. The algorithm used (SRP) uses a zero-knowledge password proof, so neither side can deduce the secret if the verification fails. In the case of methods "a" and "b" the secret is the rounded start and end time for the call, but there is a lot of other possible secrets that can be used in new methods (DTMF, UUIE, fingerprint, SMS hash, etc...). In the privacy issue, the problem is that callee number and caller numbers are disclosed in the PVP selector for method "a" and the callee number is disclosed in the PVP selector for method "b". One proposed solution would be to hash these numbers, but finding the phone numbers would still be trivial for a determined competitor. Passing the hash salt as a PVP parameter and using an adaptive hash method like bcrypt will force the PVP server to rehash all the current terminating call record, but will force a competitor to rehash probably half of the total E.164 space to find the numbers. This is still possible but can provide an adequate privacy protection level. Another possibility would be to invert the selector and the secret. After all the star/stop time of a call is not as sensitive as the caller/callee phone numbers. In this method the PVP selector would be the start/stop time and the secret would be the caller/callee numbers. The problem is that it will be more difficult to design an algorithm to select a unique call record if the returned set contains more than one. One solution could be to add more data in the PVP selector, for example by adding the call initiation time and the direction of the termination. We do not even need to decide - we can define these two algorithms as different methods (in addition to "a" and "b") and let the VIPR domain choose (see PVP registry proposal). B.4. PVP Entropy Another issue related to PVP is the management of entropy (Section 10.1 of the - -pvp draft). The idea is that the fact that one validation succeeds is not always enough for a remote VIPR server to give back routes and ticket for this destination. For example a VIPR domain could decide that at least 3 different calls validated with method "b" are needed to let a SIP call reach the endpoint. This proposal describes a mechanism for PVP to implement this. The idea is that when a PVP validation succeeds, the PVP server will return a ticket but may not return the list of routes if the entropy threshold is not reached. The ticket will contain an opaque value set by the PVP server that contain the level of entropy that this caller has reached. The PVP client stores the ticket but does not notify the call agent as there is no routes available. The next time the PVP client has a successful validation with the same destination, it sends the saved ticket in addition to the domain. The PVP server then evaluates the ticket, increases the entropy value stored and sends back a new ticket. If the threshold has been reached, then the PVP server sends back the routes at the same time, routes that the PVP client can now send with the ticket to the SIP element. When renewing the routes/ticket, the PVP client also sends the existing ticket, so the PVP server can decide to lower the threshold based on the entropy collected the previous time and the date of the ticket. This can be combined with the proposal for method priority. If multiple methods are available for a destination but the first that succeeds does not return the routes then the PVP client can use the next available methods in the list to try to increase the entropy and receive them. A PVP server may even use different thresholds, depending on the domains to validate. This then becomes an extension to the white/black list, where a blacklist is implemented as a default threshold of X and an infinite threshold for the domains blacklisted, and where a whitelist is implemented as a default infinite threshold and a threshold of X for the domains whitelisted. B.5. Ticket renewal Another thing that was discussed in Quebec City was the "First Call Problem", i.e. the problem that it takes up to 48 hours to verify a call and been able to use enhanced media. I think the conclusion of the discussion was that it was not too annoying for the first call, as it did not degrade the user experience. On the other hand, the cryptographic ticket granted after the first has an expiration date and so need to be renewed, and that will degrade the user experience as it would mean that for each destination, the end-user will periodically not be able to use enhanced media for the duration of a call. There was multiple proposals at the microphone to solve this problem, but I would like to detail the one I proposed. The idea is, sometimes before the expiration of the ticket, to make in parallel a PSTN call and a SIP call using the existing SIP route and ticket for the enhanced media (let's say video for the remaining of this discussion). There is already an existing I-D that can be use for this, draft-ietf-mmusic-sdp-cs. The way it could work is that the call agent, after retrieving the SIP route and ticket for a destination, will decide that it is time to re-validate the route, based for example on the frequency of calls to this number and the remaining validity of the ticket. The SIP element then adds an additional m= line to the SDP that contains a PSTN address. The offered SDP then looks something like this: v=0 o=- 2890844526 2890842807 IN IP4 10.47.16.5 s= c=IN IP4 10.47.16.5 t=0 0 m=audio 49170 RTP/AVP 0 m=audio 9 PSTN - c=PSTN - - a=setup:active a=connection:new a=cs-correlation: uuie callerid dtmf m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 The SIP element on the other side verifies the ticket then starts to process the SDP. If it does not support this feature then, as per the rules in RFC 3264, it will reject the second m= line by using port 0 in the answer SDP (In this case the end user will have to have PSTN only calls for the 48 hours after the expiration of the ticket). If the remote SIP element supports this extension then it will send back an offer like this: v=0 o=- 0 1 IN IP4 192.168.2.1 s= c=IN IP4 192.168.2.1 t=0 0 m=audio 8000 RTP/AVP 0 m=audio 9 PSTN - c=PSTN E164 +14085551234 a=setup:passive a=connection:new a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3 m=video 9000 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 The local SIP element checks that the c= line contains the right number, then establishes the audio and video media over IP, as usual, but also starts a PSTN call following the rules in draft-ietf-mmusic-sdp-cs (i.e. sending the correlation value as needed). The remote SIP element will receive the PSTN call, and correlate it with the existing SIP connection. Both parties must send audio on both the IP and the PSTN side, but the receivers can choose to play the audio coming from either the IP or PSTN connection (this is because we may want to use in the future fingerprint methods for the validation). The PSTN call is ended at the same time than the IP connection if the methods used for validation are based on the call duration (other methods may permit to end the call before), so the VCRs are processed as for an initial call. The local party marks the route as been under re-validation, so to not use the renewal method for the next 48 hours. The VIPR server will send a notification before the end of the 48 hours if there is still a PSTN route to this destination. B.6. Infrastructure overlays A new draft to discuss infrastructure overlays has been submitted to DISPATCH. "[RELOAD] is a peer to peer protocol developed by the P2PSIP Working Group. Each RELOAD instance has a unique name, which is used by the process in section 10.2 of this specification to find the configuration servers, enrollment servers and bootstrap servers needed to join the overlay. The process assumes that the RELOAD instance name is a FQDN, and uses the process in [RFC2782] (SRV RR) to find the IP address of the HTTPS server that serves the configuration document for this overlay. This process is adequate when the management of the overlay does not need to be distinguished from the owner of the FQDN used as the instance name, which is the case most of the time. But there is a special class of overlays that, by definition, requires to be unique on the Internet and for which having the possibility of create instances would defeat their very purpose. This specification calls the kind of overlays that are not domain specific, but application specific "infrastructure overlays". [VIPR] is a technology that is being standardized in the VIPR Working Group and that aims to build bridges between SIP islands by automatically provision SIP routes after the "ownership" of a PSTN phone number has been verified by an actual PSTN phone call. This technology uses an RELOAD overlay as a distributed database where mappings between phone numbers and servers responsible for the validation process are stored. The promise of VIPR to bridge these SIP islands cannot be fulfilled if there is more than one distributed database storing these mappings." - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEUEARECAAYFAk6XATsACgkQ9RoMZyVa61euvACYzXUXvaJIjHtdtLw7dY2evIyy UwCeKkbyUScdiyh5/g9lb2NIB4LWNC4= =foaT -----END PGP SIGNATURE----- From petithug@acm.org Thu Oct 13 08:41:56 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C6C21F87C5 for ; Thu, 13 Oct 2011 08:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.697 X-Spam-Level: X-Spam-Status: No, score=-101.697 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry45fyuso4kY for ; Thu, 13 Oct 2011 08:41:56 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E8C4C21F8797 for ; Thu, 13 Oct 2011 08:41:55 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 797E32087B for ; Thu, 13 Oct 2011 15:34:22 +0000 (UTC) Message-ID: <4E9706BF.3030902@acm.org> Date: Thu, 13 Oct 2011 08:41:51 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] VIPR toubleshooting X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 15:41:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One very important point made in draft-jennings-vipr-overview is the troubleshooting problem (section 2.4). Because the provisioning of SIP routes is automatic, there is no possibility to have a interop testing between two domains before the establishment of the fist call. This means two things: - - We will need in the future to define a SIP profile that defines exactly what SIP extensions and media are supported (I propose to call this profile SIPbeyond). I think that we have a common goal here with the RTCWEB WG, and should probably work with them on this. - - We need to provide help for debugging problems if things go wrong. For the latter, the main issue is that it is not always possible to troubleshoot a problem only by looking on the logs and traces on the sending side - some kind of cooperation is required by the receiving side. Having a way to retrieve the logs and traces automatically would be a good step in this direction, but we now have a security problem to take care of, as we certainly do not want anybody to be able to retrieve this information. One internet-draft on this topic was just published, and it could be a start on this discussion: http://www.ietf.org/id/draft-kaithal-dispatch-sip-log-information-00.txt There is certainly other possibilities, and this email is meant as a way to start this discussion. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6XBr0ACgkQ9RoMZyVa61fFGACgnel3+QbX3dvHmqJ47aMjrSZS E6sAoIxSnbt9RpT+8hfT3/FLtyKyGIqG =iSG9 -----END PGP SIGNATURE----- From jon.peterson@neustar.biz Thu Oct 13 10:26:02 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390B921F84CF for ; Thu, 13 Oct 2011 10:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuotNnGK4Q7N for ; Thu, 13 Oct 2011 10:26:00 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 903FA21F84B1 for ; Thu, 13 Oct 2011 10:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1318526700; x=1633879643; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=IdJt68luJ5JApeNybPCd+ +FP9yh1jLtP+5xvXgaLYEs=; b=H+7faZFBjaubSQW6WHXedb48R4MqQV1aWiqR+ PPyJIwB/HD0dTs1Zf/5hdq6BVrKZXXQ5oQDFELkucq+T38zTw== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.512922; Thu, 13 Oct 2011 13:24:59 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 13 Oct 2011 13:25:54 -0400 From: "Peterson, Jon" To: Marc Petit-Huguenin Date: Thu, 13 Oct 2011 13:25:45 -0400 Thread-Topic: [VIPR] An alternative to the VIPR ticket Thread-Index: AcyJzSkvFwzHOb+gTh6l7UFZRSgK1Q== Message-ID: <5C4D5C85-A551-4E11-A5D6-FCC56C56A1B3@neustar.biz> References: <4E627AB4.7070806@acm.org> <4E961A6B.2090603@acm.org> In-Reply-To: <4E961A6B.2090603@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: jP+wt2cal/yXgtMCILFeJg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "vipr@ietf.org" Subject: Re: [VIPR] An alternative to the VIPR ticket X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 17:26:02 -0000 On the last design call, I expressed a number of reservations about this ch= ange, but the main one was that it was insufficiently motivated. For my par= t, anyway, I was curious to understand what the problem was with the existi= ng mechanism that you believed this solved - once we understood the problem= , we could understand the potential design space to solve it. I had thought= we'd left the call understanding that you were going to explain the proble= m; instead, you're pretty much defending a solution here without reference = to what the problem is.=20 I've taken a look at the sketch of your proposal below, but it's a bit too = high level for me to really understand its properties. I will say that if y= our argument is: > my proposal does not change what a normal SIP stack is doing, > because the specification does not say what a SIP stack should do with a = client > certificate. I have to disagree. 5922 cites the relevant text in 3261: Each side of the connection SHOULD verify and inspect the certificate of the other, noting the domain name that appears in the certificate for comparison with the header fields of SIP messages. Now by today's standards, that text is somewhat vague, but back when we wro= te that the idea was basically that you compare the domain in the cert (typ= ically the CN or SubjectAltName) used in TLS with the supposed identity of = the sender of a request over that transport connection (typically given in = the From header field value). That works when the cert has been issued by a= n authority capable of ascertaining who owns domain names. 5922 introduces = qualifications to this in order to support cases where a virtual hosting se= rvice has a certificate with multiple names, for example, but it isn't real= ly chipping away at the basic operation. ViPR today, as you cite, requires = that same reference integrity between the granted-to field of the ticket an= d the domain in the cert used in TLS. Again, the idea here is that the gran= ted-to has to correspond with a cert issued by an authority who actually ve= rifies ownership of domain names. Thus, purely on the basis of capturing a = ticket with a granted-to of example.com, you cannot impersonate example.com= unless you also control a cert issued for that domain by a CA, and inciden= tally a CA trusted by the target ViPR domain. If you are arguing for a case= where a ViPR domain that is not in a position to certify who owns what dom= ain names is issuing certificates that are used for TLS, then you are chang= ing how certificate usage in SIP is commonly understood. >From what I can gather about your proposal, I suspect you underestimate the= complexity of acting as a CA, enrolling peers in the CA and enabling them = to use those credentials properly - what it means for two entities that hav= e no pre-existing relationship to suddenly treat each other as trust anchor= s. I furthermore suspect that TLS operations would not be optimal in this s= ort of model. Is the antispam property something that is best bound to the = transport or to a single SIP request? The use cases, ultimately, answer tha= t for us: consider two large ViPR domains that want to exchange traffic - s= hould they have to establish a new TLS connection for each called number, o= r should they be able to send signaling for many calls over a single TLS co= nnection? Are there cases where the hop-by-hop property of TLS weakens the = utility of the mechanism? Are there environments we want ViPR to be useful = where TLS is not available?=20 Jon Peterson (as an individual) NeuStar, Inc. On Oct 12, 2011, at 3:53 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > During the last conference call, this proposal was criticized as been a s= ignificant change from the way SIP is processing TLS requests. My research > shows that it is not the case. >=20 > First of all, let's define exactly what SIP, without even talking about V= IPR, is > doing regarding TLS. The best place for this is RFC 5922. We can skip t= he > client behavior discussion (section 7.3) because neither VIPR or my propo= sal > suggest any modification to this procedure. Here's what RFC 5922 says ab= out the > server behavior (aka client certificate): >=20 > " When a server accepts a TLS connection, the server presents its own > X.509 certificate to the client. Servers that wish to authenticate > the client will ask the client for a certificate. If the client > possesses a certificate, that certificate is presented to the server. > If the client does not present a certificate, the client MUST NOT be > considered authenticated. >=20 > [...] >=20 > When authenticating the client, the server MUST obtain the set of SIP > domain identities from the client certificate as described in > Section 7.1. Because the server accepted the TLS connection > passively, unlike a client, the server does not possess an AUS for > comparison. Nonetheless, server policies can use the set of SIP > domain identities gathered from the certificate in Section 7.1 to > make authorization decisions. >=20 > For example, a very open policy could be to accept an X.509 > certificate and validate the certificate using the procedures in RFC > 5280 [6]. If the certificate is valid, the identity set is logged. >=20 > Alternatively, the server could have a list of all SIP domains the > server is allowed to accept connections from; when a client presents > its certificate, for each identity in the client certificate, the > server searches for the identity in the list of acceptable domains to > decide whether or not to accept the connection. Other policies that > make finer distinctions are possible." >=20 > In other words, the SIP server (or proxy) does whatever it thinks is nece= ssary > with the client certificate, and it does not seems that even following RF= C 5280 > is required (note in particular that nowhere it is said that the validati= on must > use a public trust anchor). >=20 > VIPR itself adds very little to the requirements of RFC 5922. Here is wh= at > - -sip-antispam says about TLS and the ticket: >=20 > " The Border Element will receive the TLS ClientHello which begins the > TLS handshake. The Border Element will present its own configured > cert. Once TLS handshaking is complete, the Border Element notes the > domain from the SubjectAltName on the other side of the TLS > connection, and associates it with that connection. >=20 > Next, the Border Element will receive an INVITE. This INVITE will > contain a ticket in the ViPR-Ticket header field value. The Border > Element extracts this header field. This call flow assumes it is > present. The Border Element parses it, and obtains the epoch value > encoded in the ticket. This is matched against the current epoch > value for the configured password. If they match, processing > continues. The Border Element verifies the signature is correct. > Next, it examines the start and stop time of the validity. If the > current time is between the start and stop times, the check is > passed. Next, the Border Element checks the granted-to domain in the > ticket. It compares that domain against the domain name in the > SubjectAltName of the peer on the other side of the TLS connection, > as noted above. Next, it takes the Request-URI of the SIP INVITE. > That will be of the form sip:+number@domain. If it is not in that > form, and if the number does not begin with a plus, the request is > dropped. The value, including the plus, is then compared to the > number in the ticket. If it is equal, the check has passed. The > Border Element leaves the header field in the request, but forwards > to the Call Agent." >=20 > The only policy that is added to what RFC 5922 says is that the granted-t= o > domain in the ticket must be equal to the domain in the SubjectAltName of= the > client certificate. Here too, not a word about a public trust anchor. >=20 > Now back to my proposal. The first thing is that the client certificate = must be > validated using the CA of the VIPR server as trust anchor, which is alrea= dy what > a SIP server could do. It validates according to the rules in RFC 5280, = which > is equivalent to verifying the signature of the ticket and the start/stop > validity. The SubjectAltName in the client certificate (which is not eve= n > required to be used in standard SIP) can be checked against the domain pa= rt of > the From header of the INVITE. The phone number and the granting-domain = (which > not even verified in VIPR) can be stored as an URI in the Issuer Alternat= ive > Name extension in the client certificate and be validated against the > Request-URI of the INVITE. The granting node can be also be stored as a = reload > URI in an Issuer Alternative Name extension. >=20 > So in conclusion, my proposal does not change what a normal SIP stack is = doing, > because the specification does not say what a SIP stack should do with a = client > certificate. >=20 > (Note that to -sip-antispam should also be added some text saying that RF= C 5923 > must be used, because there is no way to create an additional TLS connect= ion in > the other direction for a subsequent SIP transaction). >=20 > On 09/03/2011 12:06 PM, Marc Petit-Huguenin wrote: >> In the current specification, the PVP server builds and signs a VIPR tic= ket, and >> send it back to the PVP client, that passes it to the Call Agent/ Border= Element >> (CA/BE). The CA/BE will insert this ticket in the next SIP INVITE to th= e remote >> CA/BE, which will check the validity of the ticket and the domain of the= TLS client. >>=20 >> There is multiple things that bother me with this process: >>=20 >> - The verification of the ticket use HMAC-SHA1, and so the same password= has to >> be provisioned in both the CA/BE(s) (to verify the ticket) and the VIPR >> server(s) (to generate the ticket). >> - The ticket can be used without TLS (we all know that implementers thin= k of >> MUST as SHOULD and SHOULD as MAY). >>=20 >> I would like to propose an alternative that is simpler to implement and,= I >> think, more secure than the ticket. >>=20 >> Instead of using a symmetrical key, the local VIPR server generates an R= SA key >> pair, with the public key distributed to the CA/BE(s). After a successf= ul PVP >> connection, the remote PVP client sends a PKCS#10 certificate request, >> containing the domain name and signed with a private key[1]. The local = PVP >> server generates a new certificate[2], sign it with its private key and = send it >> back to the remote PVP client, which pass it back to the remote CA/BE. >>=20 >> The remote CA/BE will use the certificate received to establish the TLS >> connection for the SIP transactions to the local CA/BE, which will use a >> standard CA based certificate for its domain. The local CA/BE will be a= ble to >> verify with the VIPR public key that it issued the certificate, then wil= l >> validate the standard parts of the certificate (expiration date and so o= n). >>=20 >> There is multiple advantages to this proposal: >>=20 >> - The private key is stored only in the VIPR server, or better in a phys= ical >> token. >> - VIPR does not work without TLS for the SIP connection. >> - There is plenty of commercial or free TLS and X.509 implementations th= at have >> years of experience and testing, which is not the case for the ticket pr= oposal. >> - Security agility is provided by TLS. >> - No additional SIP Header. >> - Because the ticket verification process is folded into the client cert= ificate >> verification, there is less resources needed. >>=20 >>=20 >> [1] This is the private key of the CA/BE, so the CA/BE needs to upload t= he >> PKCS#10 file in the VIPR server. Depending on the architecture used, ea= ch CA/BE >> can use a different PKCS#10 or the same, which means that the PVP server= must be >> able to process more than one PKCS#10 and send back more than one certif= icate on >> one PVP connection. >>=20 >> [2] The certificate sent back can directly contain the SIP routes, incre= asing >> the overall security. One possible mapping from the ValExchange respons= e to the >> certificate could be: >>=20 >> - Unique ID: serialNumber >> - Epoch: issuer >> - salt: N/A >> - integrity: signature >> - Validity: validity >> - Phone Number: subjectAltName uniformResourceIdentifier tel:+1408555123= 4 >> - Node-ID: subjectAltName uniformResourceIdentifier >> reload://0110123456789ABCDEF0123456789ABCDEF/ >> - Granted domain: subjectAltName dNSName example.com >> - Granting domain: implicit in routes >> - Route(s): subjectAltName uniformResourceIdentifier >> sip:+14085551234@example.org:371;maddr=3D10.1.1.1 >>=20 >=20 >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iEYEARECAAYFAk6WGmoACgkQ9RoMZyVa61dW3gCeMcKcsvqK27kk2ZW1mRMPYdep > 3ZcAn3EIFv8hlBZop57YIDN7HCOUtixU > =3Dv31B > -----END PGP SIGNATURE----- > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr From petithug@acm.org Thu Oct 13 11:41:01 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374F721F8513 for ; Thu, 13 Oct 2011 11:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.848 X-Spam-Level: X-Spam-Status: No, score=-101.848 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttqelrkjowaq for ; Thu, 13 Oct 2011 11:40:59 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 550EE21F84A6 for ; Thu, 13 Oct 2011 11:40:59 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E24AE2087B; Thu, 13 Oct 2011 18:33:24 +0000 (UTC) Message-ID: <4E9730B6.8060107@acm.org> Date: Thu, 13 Oct 2011 11:40:54 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "Peterson, Jon" References: <4E627AB4.7070806@acm.org> <4E961A6B.2090603@acm.org> <5C4D5C85-A551-4E11-A5D6-FCC56C56A1B3@neustar.biz> In-Reply-To: <5C4D5C85-A551-4E11-A5D6-FCC56C56A1B3@neustar.biz> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: Re: [VIPR] An alternative to the VIPR ticket X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 18:41:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/13/2011 10:25 AM, Peterson, Jon wrote: > > On the last design call, I expressed a number of reservations about this > change, but the main one was that it was insufficiently motivated. For my > part, anyway, I was curious to understand what the problem was with the > existing mechanism that you believed this solved - once we understood the > problem, we could understand the potential design space to solve it. I had > thought we'd left the call understanding that you were going to explain the > problem; instead, you're pretty much defending a solution here without > reference to what the problem is. I thought I did this, but here is my list of problems associated with the ticket as currently defined: - - Use of a symmetrical key, which has to be shared between different boxes if the generation of the ticket is done in a different box than the verification of the ticket. - - No security agility. - - Code has to be written from scratch for both the generation and the verification of the ticket. > > I've taken a look at the sketch of your proposal below, but it's a bit too > high level for me to really understand its properties. I will say that if > your argument is: > >> my proposal does not change what a normal SIP stack is doing, because the >> specification does not say what a SIP stack should do with a client >> certificate. > > I have to disagree. 5922 cites the relevant text in 3261: Each side of the > connection SHOULD verify and inspect the certificate of the other, noting the > domain name that appears in the certificate for comparison with the header > fields of SIP messages. Now by today's standards, that text is somewhat > vague, but back when we wrote that the idea was basically that you compare > the domain in the cert (typically the CN or SubjectAltName) used in TLS with > the supposed identity of the sender of a request over that transport > connection (typically given in the From header field value). That works when > the cert has been issued by an authority capable of ascertaining who owns > domain names. 5922 introduces qualifications to this in order to support > cases where a virtual hosting service has a certificate with multiple names, > for example, but it isn't really chipping away at the basic operation. Let me offer a more complete quote of RFC 5922: " RFC 3261 [2], Section 26.3.2.2, only tells Proxy-B to "compare the domain asserted by the certificate with the 'domainname' portion of the From header field in the INVITE request". The difficulty with that instruction is that the domainname in the From header field is not always that of the domain from which the request is received." So here RFC 5922 acknowledges that doing this verification is not possible in all cases. The minimum should have been to do an RFC 5280 validation, but even that is not required. > ViPR > today, as you cite, requires that same reference integrity between the > granted-to field of the ticket and the domain in the cert used in TLS. Again, > the idea here is that the granted-to has to correspond with a cert issued by > an authority who actually verifies ownership of domain names. Thus, purely on > the basis of capturing a ticket with a granted-to of example.com, you cannot > impersonate example.com unless you also control a cert issued for that domain > by a CA, and incidentally a CA trusted by the target ViPR domain. If you are > arguing for a case where a ViPR domain that is not in a position to certify > who owns what domain names is issuing certificates that are used for TLS, > then you are changing how certificate usage in SIP is commonly understood. Yes, you have a point here. Verifying the granted-to domain at call time will prevent someone to use a stolen ticket, and will prevent the granted-to domain to sell their tickets (although a domain can sell its private key also with the tickets). So if this verification is really that important (still thinking about this), I guess that using the ticket as the client certificate is a problem. But in any case I still think that using an X.509 certificate in the Vipr-Ticket field is a better solution than using an adhoc ticket as described currently in VIPR. > >> From what I can gather about your proposal, I suspect you underestimate the >> complexity of acting as a CA, enrolling peers in the CA and enabling them >> to use those credentials properly I do not underestimate anything. On the other hand the CAs certainly overestimate the value of their services, especially on the light of the recent problems some of them experienced. Running a CA is not difficult, and the best proof is that RELOAD (draft-ietf-p2psip-base section 10.3) requires running it's own CA in a way that is similar to what I propose. >> - what it means for two entities that >> have no pre-existing relationship to suddenly treat each other as trust >> anchors. I furthermore suspect that TLS operations would not be optimal in >> this sort of model. Is the antispam property something that is best bound >> to the transport or to a single SIP request? The use cases, ultimately, >> answer that for us: consider two large ViPR domains that want to exchange >> traffic - should they have to establish a new TLS connection for each >> called number, or should they be able to send signaling for many calls over >> a single TLS connection? Are there cases where the hop-by-hop property of >> TLS weakens the utility of the mechanism? Are there environments we want >> ViPR to be useful where TLS is not available? Here you are not talking about my proposal, but about VIPR itself, as it already requires TLS. That's a different problem. > > Jon Peterson (as an individual) NeuStar, Inc. > > On Oct 12, 2011, at 3:53 PM, Marc Petit-Huguenin wrote: > > During the last conference call, this proposal was criticized as been a > significant change from the way SIP is processing TLS requests. My research > shows that it is not the case. > > First of all, let's define exactly what SIP, without even talking about VIPR, > is doing regarding TLS. The best place for this is RFC 5922. We can skip > the client behavior discussion (section 7.3) because neither VIPR or my > proposal suggest any modification to this procedure. Here's what RFC 5922 > says about the server behavior (aka client certificate): > > " When a server accepts a TLS connection, the server presents its own X.509 > certificate to the client. Servers that wish to authenticate the client will > ask the client for a certificate. If the client possesses a certificate, > that certificate is presented to the server. If the client does not present a > certificate, the client MUST NOT be considered authenticated. > > [...] > > When authenticating the client, the server MUST obtain the set of SIP domain > identities from the client certificate as described in Section 7.1. Because > the server accepted the TLS connection passively, unlike a client, the server > does not possess an AUS for comparison. Nonetheless, server policies can use > the set of SIP domain identities gathered from the certificate in Section 7.1 > to make authorization decisions. > > For example, a very open policy could be to accept an X.509 certificate and > validate the certificate using the procedures in RFC 5280 [6]. If the > certificate is valid, the identity set is logged. > > Alternatively, the server could have a list of all SIP domains the server is > allowed to accept connections from; when a client presents its certificate, > for each identity in the client certificate, the server searches for the > identity in the list of acceptable domains to decide whether or not to accept > the connection. Other policies that make finer distinctions are possible." > > In other words, the SIP server (or proxy) does whatever it thinks is > necessary with the client certificate, and it does not seems that even > following RFC 5280 is required (note in particular that nowhere it is said > that the validation must use a public trust anchor). > > VIPR itself adds very little to the requirements of RFC 5922. Here is what > -sip-antispam says about TLS and the ticket: > > " The Border Element will receive the TLS ClientHello which begins the TLS > handshake. The Border Element will present its own configured cert. Once > TLS handshaking is complete, the Border Element notes the domain from the > SubjectAltName on the other side of the TLS connection, and associates it > with that connection. > > Next, the Border Element will receive an INVITE. This INVITE will contain a > ticket in the ViPR-Ticket header field value. The Border Element extracts > this header field. This call flow assumes it is present. The Border Element > parses it, and obtains the epoch value encoded in the ticket. This is > matched against the current epoch value for the configured password. If they > match, processing continues. The Border Element verifies the signature is > correct. Next, it examines the start and stop time of the validity. If the > current time is between the start and stop times, the check is passed. Next, > the Border Element checks the granted-to domain in the ticket. It compares > that domain against the domain name in the SubjectAltName of the peer on the > other side of the TLS connection, as noted above. Next, it takes the > Request-URI of the SIP INVITE. That will be of the form sip:+number@domain. > If it is not in that form, and if the number does not begin with a plus, the > request is dropped. The value, including the plus, is then compared to the > number in the ticket. If it is equal, the check has passed. The Border > Element leaves the header field in the request, but forwards to the Call > Agent." > > The only policy that is added to what RFC 5922 says is that the granted-to > domain in the ticket must be equal to the domain in the SubjectAltName of > the client certificate. Here too, not a word about a public trust anchor. > > Now back to my proposal. The first thing is that the client certificate must > be validated using the CA of the VIPR server as trust anchor, which is > already what a SIP server could do. It validates according to the rules in > RFC 5280, which is equivalent to verifying the signature of the ticket and > the start/stop validity. The SubjectAltName in the client certificate (which > is not even required to be used in standard SIP) can be checked against the > domain part of the From header of the INVITE. The phone number and the > granting-domain (which not even verified in VIPR) can be stored as an URI in > the Issuer Alternative Name extension in the client certificate and be > validated against the Request-URI of the INVITE. The granting node can be > also be stored as a reload URI in an Issuer Alternative Name extension. > > So in conclusion, my proposal does not change what a normal SIP stack is > doing, because the specification does not say what a SIP stack should do with > a client certificate. > > (Note that to -sip-antispam should also be added some text saying that RFC > 5923 must be used, because there is no way to create an additional TLS > connection in the other direction for a subsequent SIP transaction). > > On 09/03/2011 12:06 PM, Marc Petit-Huguenin wrote: >>>> In the current specification, the PVP server builds and signs a VIPR >>>> ticket, and send it back to the PVP client, that passes it to the Call >>>> Agent/ Border Element (CA/BE). The CA/BE will insert this ticket in >>>> the next SIP INVITE to the remote CA/BE, which will check the validity >>>> of the ticket and the domain of the TLS client. >>>> >>>> There is multiple things that bother me with this process: >>>> >>>> - The verification of the ticket use HMAC-SHA1, and so the same >>>> password has to be provisioned in both the CA/BE(s) (to verify the >>>> ticket) and the VIPR server(s) (to generate the ticket). - The ticket >>>> can be used without TLS (we all know that implementers think of MUST as >>>> SHOULD and SHOULD as MAY). >>>> >>>> I would like to propose an alternative that is simpler to implement >>>> and, I think, more secure than the ticket. >>>> >>>> Instead of using a symmetrical key, the local VIPR server generates an >>>> RSA key pair, with the public key distributed to the CA/BE(s). After a >>>> successful PVP connection, the remote PVP client sends a PKCS#10 >>>> certificate request, containing the domain name and signed with a >>>> private key[1]. The local PVP server generates a new certificate[2], >>>> sign it with its private key and send it back to the remote PVP client, >>>> which pass it back to the remote CA/BE. >>>> >>>> The remote CA/BE will use the certificate received to establish the >>>> TLS connection for the SIP transactions to the local CA/BE, which will >>>> use a standard CA based certificate for its domain. The local CA/BE >>>> will be able to verify with the VIPR public key that it issued the >>>> certificate, then will validate the standard parts of the certificate >>>> (expiration date and so on). >>>> >>>> There is multiple advantages to this proposal: >>>> >>>> - The private key is stored only in the VIPR server, or better in a >>>> physical token. - VIPR does not work without TLS for the SIP >>>> connection. - There is plenty of commercial or free TLS and X.509 >>>> implementations that have years of experience and testing, which is not >>>> the case for the ticket proposal. - Security agility is provided by >>>> TLS. - No additional SIP Header. - Because the ticket verification >>>> process is folded into the client certificate verification, there is >>>> less resources needed. >>>> >>>> >>>> [1] This is the private key of the CA/BE, so the CA/BE needs to upload >>>> the PKCS#10 file in the VIPR server. Depending on the architecture >>>> used, each CA/BE can use a different PKCS#10 or the same, which means >>>> that the PVP server must be able to process more than one PKCS#10 and >>>> send back more than one certificate on one PVP connection. >>>> >>>> [2] The certificate sent back can directly contain the SIP routes, >>>> increasing the overall security. One possible mapping from the >>>> ValExchange response to the certificate could be: >>>> >>>> - Unique ID: serialNumber - Epoch: issuer - salt: N/A - integrity: >>>> signature - Validity: validity - Phone Number: subjectAltName >>>> uniformResourceIdentifier tel:+14085551234 - Node-ID: subjectAltName >>>> uniformResourceIdentifier >>>> reload://0110123456789ABCDEF0123456789ABCDEF/ - Granted domain: >>>> subjectAltName dNSName example.com - Granting domain: implicit in >>>> routes - Route(s): subjectAltName uniformResourceIdentifier >>>> sip:+14085551234@example.org:371;maddr=10.1.1.1 >>>> > > _______________________________________________ VIPR mailing list VIPR@ietf.org https://www.ietf.org/mailman/listinfo/vipr - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6XMLUACgkQ9RoMZyVa61dhCgCghMV7hIJ8Gcc1GZjGEiDflw44 kwkAn3zHPotOdEQRb4VQort1a8aYb/f4 =Slq9 -----END PGP SIGNATURE----- From jon.peterson@neustar.biz Thu Oct 13 12:56:03 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FF521F8497 for ; Thu, 13 Oct 2011 12:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.597 X-Spam-Level: X-Spam-Status: No, score=-105.597 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e41AHB0+1WhS for ; Thu, 13 Oct 2011 12:56:00 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 25A2821F84D1 for ; Thu, 13 Oct 2011 12:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1318535825; x=1633892657; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=YtoiEkNPoQ7I8x5l6B9u94JQ5HcNbgBc2lkyFG9KICM=; b=na+4B02RHbsjajYGutq8/xWrWNqMpkAzH66HOi3HJkny8XAaY2te1tRVmorH7X 8tvAlHvIHdurVLlTC3lM4YXw== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.1121600; Thu, 13 Oct 2011 15:57:03 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 13 Oct 2011 15:55:51 -0400 From: "Peterson, Jon" To: Marc Petit-Huguenin Date: Thu, 13 Oct 2011 15:55:35 -0400 Thread-Topic: [VIPR] An alternative to the VIPR ticket Thread-Index: AcyJ4hvUkKePGX/DRrGBwbeII9r/rA== Message-ID: <5143068F-634B-4578-AA6D-4EF902471B30@neustar.biz> References: <4E627AB4.7070806@acm.org> <4E961A6B.2090603@acm.org> <5C4D5C85-A551-4E11-A5D6-FCC56C56A1B3@neustar.biz> <4E9730B6.8060107@acm.org> In-Reply-To: <4E9730B6.8060107@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 2TvgZZyQISOIBXGusWWLrw== Content-Type: multipart/alternative; boundary="_000_5143068F634B4578AA6D4EF902471B30neustarbiz_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 13 Oct 2011 13:23:50 -0700 Cc: "vipr@ietf.org" Subject: Re: [VIPR] An alternative to the VIPR ticket X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 19:56:03 -0000 --_000_5143068F634B4578AA6D4EF902471B30neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I thought I did this, but here is my list of problems associated with the t= icket as currently defined: - - Use of a symmetrical key, which has to be shared between different boxe= s if the generation of the ticket is done in a different box than the verificati= on of the ticket. This was the only problem you brought up during the call. I would say howev= er that if you're running a CA, then you need to share a great deal more th= an a symmetrical key to validate signed messages. Unless the thing that iss= ued the cert is colocated with the box that acts as a TLS server, you're no= t going to be able to avoid some communication between those boxes. As I said on the call, there are a number of ways to address that need for = communication among distributed components that do not involve replicating = secrets, and those are part of the design space for addressing implementati= ons that want to distribute these components. - - No security agility. I assume you mean algorithm agility. TLS does have a great deal of latitude= here, it's true, including the ability to set a null cipher suite. You're = going to end up having to narrowly profile TLS for the application if you w= ant to achieve any measure of interoperability or security. SIP, for exampl= e, is pretty specific about what algorithms you use with TLS. If you want t= o change the recommended algorithm, you will still be iterating your specif= ications and rolling out new versions. - - Code has to be written from scratch for both the generation and the verification of the ticket. I'm dubious that any off-the-shelf CA library will enable you to put attrib= utes like granted-by and so on into certificates without putting any signif= icant burden on implementers, let alone parsing and verifying those attribu= tes as a step in validating a TLS connection. I've taken a look at the sketch of your proposal below, but it's a bit too high level for me to really understand its properties. I will say that if your argument is: my proposal does not change what a normal SIP stack is doing, because the specification does not say what a SIP stack should do with a client certificate. I have to disagree. 5922 cites the relevant text in 3261: Each side of the connection SHOULD verify and inspect the certificate of the other, noting t= he domain name that appears in the certificate for comparison with the header fields of SIP messages. Now by today's standards, that text is somewhat vague, but back when we wrote that the idea was basically that you compare the domain in the cert (typically the CN or SubjectAltName) used in TLS wit= h the supposed identity of the sender of a request over that transport connection (typically given in the From header field value). That works whe= n the cert has been issued by an authority capable of ascertaining who owns domain names. 5922 introduces qualifications to this in order to support cases where a virtual hosting service has a certificate with multiple names= , for example, but it isn't really chipping away at the basic operation. Let me offer a more complete quote of RFC 5922: " RFC 3261 [2], Section 26.3.2.2, only tells Proxy-B to "compare the domain asserted by the certificate with the 'domainname' portion of the From header field in the INVITE request". The difficulty with that instruction is that the domainname in the From header field is not always that of the domain from which the request is received." So here RFC 5922 acknowledges that doing this verification is not possible = in all cases. The minimum should have been to do an RFC 5280 validation, but = even that is not required. RFC3261 still naively assumed a SIP trapezoid. ViPR does as well, but much = less naively. The notice given in here in RFC5922 is about cases where an i= ntermediary domain prevents the establishment of a direct TLS connection. I= f we have an intrusive intermediary in ViPR, then yes, you'll have a failur= e establishing reference integrity. However, I'd say that the whole, entire= point of doing ViPR, of using RELOAD as a foundation, was to establish dir= ect connections between ViPR domains without relying on any intermediary in= frastructure. ViPR is by design a dis-intermediation mechanism. (This is in= danger of being the intermediary discussion again - hopefully this isn't o= ne of the "hooks" that we're fishing for.) Anyway, 5922 is speaking to a subset of SIP TLS behavior - behavior, incide= ntally, that has been controversial in all of the protocols that rely on TL= S, like virtual hosting cases and proxying cases. We should be using that a= s a departure point to argue that reference integrity isn't a desirable or = necessary property, especially not in ViPR. That is not the intention behin= d RFC5922. ViPR today, as you cite, requires that same reference integrity between the granted-to field of the ticket and the domain in the cert used in TLS. Agai= n, the idea here is that the granted-to has to correspond with a cert issued b= y an authority who actually verifies ownership of domain names. Thus, purely = on the basis of capturing a ticket with a granted-to of example.com, you cannot impersonate example.com unless you also control a cert = issued for that domain by a CA, and incidentally a CA trusted by the target ViPR domain. If you ar= e arguing for a case where a ViPR domain that is not in a position to certify who owns what domain names is issuing certificates that are used for TLS, then you are changing how certificate usage in SIP is commonly understood. Yes, you have a point here. Verifying the granted-to domain at call time w= ill prevent someone to use a stolen ticket, and will prevent the granted-to dom= ain to sell their tickets (although a domain can sell its private key also with= the tickets). So if this verification is really that important (still thinking about this= ), I guess that using the ticket as the client certificate is a problem. But in= any case I still think that using an X.509 certificate in the Vipr-Ticket field= is a better solution than using an adhoc ticket as described currently in VIPR. Again, I think this would need to be far more thoroughly specified for us t= o be able to evaluate the idea. I gather you mean that you could just put t= he signature generated by the cert into the ticket's header field value. Th= at is a much less radical proposal than doing this at the transport layer. = We'd then need to evaluate, again, how those certs get created, installed a= nd validated, and whether or not this truly solves your problem with distri= buted components - or if indeed there are other ways entirely to approach t= he distributed components problem that changing the way the ticket is secur= ed, and which ways would require the least work. >From what I can gather about your proposal, I suspect you underestimate the complexity of acting as a CA, enrolling peers in the CA and enabling them to use those credentials properly I do not underestimate anything. On the other hand the CAs certainly overestimate the value of their services, especially on the light of the re= cent problems some of them experienced. Running a CA is not difficult, and the = best proof is that RELOAD (draft-ietf-p2psip-base section 10.3) requires running= it's own CA in a way that is similar to what I propose. I rather think the recent CA problems are an illustration of how easy it is= to do things wrong. I look forward to reading your CPS. Honestly, this would be a lot easier to swallow if you proposed just to gen= erate a public/private key pair without all the X.509 baggage. I really don= 't see how a certificate adds any value, except in so far TLS requires them= , but if you're willing to move this to a header field, X.509 would be the = first thing I'd drop. - what it means for two entities that have no pre-existing relationship to suddenly treat each other as trust anchors. I furthermore suspect that TLS operations would not be optimal in this sort of model. Is the antispam property something that is best bound to the transport or to a single SIP request? The use cases, ultimately, answer that for us: consider two large ViPR domains that want to exchange traffic - should they have to establish a new TLS connection for each called number, or should they be able to send signaling for many calls over a single TLS connection? Are there cases where the hop-by-hop property of TLS weakens the utility of the mechanism? Are there environments we want ViPR to be useful where TLS is not available? Here you are not talking about my proposal, but about VIPR itself, as it al= ready requires TLS. That's a different problem. If ViPR Domain A nails up a TLS connection to ViPR Domain B, in the origina= l ViPR plan as I understand it, the (public) cert presented by A in TLS is = compared to the granted-to of tickets by B when A sends requests over that = connection. A could send thousands of different requests, from thousands of= different callers, to thousands of different destinations, over the same T= LS channel, because the channel is bound to the domain and not to any speci= fic ticket. Unless I totally misunderstand your proposal, you are changing = that, right? You want to instantiate the antispam function at the establish= ment of a TLS connection. The issue is that in SIP, call signaling isn't ne= cessary bound to the establishment of an underlying transport. Agreed, however, that ViPR does basically require TLS today, so if TLS isn'= t available, those parts of the spec as written today would't work, so that= isn't a problem with your proposal as such - though perhaps your (original= ) proposal would make adjusting the spec to fix that impossible. Jon Peterson (as an individual) NeuStar, Inc. Jon Peterson (as an individual) NeuStar, Inc. On Oct 12, 2011, at 3:53 PM, Marc Petit-Huguenin wrote: During the last conference call, this proposal was criticized as been a significant change from the way SIP is processing TLS requests. My researc= h shows that it is not the case. First of all, let's define exactly what SIP, without even talking about VIP= R, is doing regarding TLS. The best place for this is RFC 5922. We can skip the client behavior discussion (section 7.3) because neither VIPR or my proposal suggest any modification to this procedure. Here's what RFC 5922 says about the server behavior (aka client certificate): " When a server accepts a TLS connection, the server presents its own X.50= 9 certificate to the client. Servers that wish to authenticate the client wi= ll ask the client for a certificate. If the client possesses a certificate, that certificate is presented to the server. If the client does not present= a certificate, the client MUST NOT be considered authenticated. [...] When authenticating the client, the server MUST obtain the set of SIP domai= n identities from the client certificate as described in Section 7.1. Becaus= e the server accepted the TLS connection passively, unlike a client, the serv= er does not possess an AUS for comparison. Nonetheless, server policies can u= se the set of SIP domain identities gathered from the certificate in Section 7= .1 to make authorization decisions. For example, a very open policy could be to accept an X.509 certificate and validate the certificate using the procedures in RFC 5280 [6]. If the certificate is valid, the identity set is logged. Alternatively, the server could have a list of all SIP domains the server i= s allowed to accept connections from; when a client presents its certificate, for each identity in the client certificate, the server searches for the identity in the list of acceptable domains to decide whether or not to acce= pt the connection. Other policies that make finer distinctions are possible." In other words, the SIP server (or proxy) does whatever it thinks is necessary with the client certificate, and it does not seems that even following RFC 5280 is required (note in particular that nowhere it is said that the validation must use a public trust anchor). VIPR itself adds very little to the requirements of RFC 5922. Here is what -sip-antispam says about TLS and the ticket: " The Border Element will receive the TLS ClientHello which begins the TLS handshake. The Border Element will present its own configured cert. Once TLS handshaking is complete, the Border Element notes the domain from the SubjectAltName on the other side of the TLS connection, and associates it with that connection. Next, the Border Element will receive an INVITE. This INVITE will contain = a ticket in the ViPR-Ticket header field value. The Border Element extracts this header field. This call flow assumes it is present. The Border Eleme= nt parses it, and obtains the epoch value encoded in the ticket. This is matched against the current epoch value for the configured password. If th= ey match, processing continues. The Border Element verifies the signature is correct. Next, it examines the start and stop time of the validity. If the current time is between the start and stop times, the check is passed. Nex= t, the Border Element checks the granted-to domain in the ticket. It compares that domain against the domain name in the SubjectAltName of the peer on th= e other side of the TLS connection, as noted above. Next, it takes the Request-URI of the SIP INVITE. That will be of the form sip:+number@domain. If it is not in that form, and if the number does not begin with a plus, th= e request is dropped. The value, including the plus, is then compared to the number in the ticket. If it is equal, the check has passed. The Border Element leaves the header field in the request, but forwards to the Call Agent." The only policy that is added to what RFC 5922 says is that the granted-to domain in the ticket must be equal to the domain in the SubjectAltName of the client certificate. Here too, not a word about a public trust anchor. Now back to my proposal. The first thing is that the client certificate mu= st be validated using the CA of the VIPR server as trust anchor, which is already what a SIP server could do. It validates according to the rules in RFC 5280, which is equivalent to verifying the signature of the ticket and the start/stop validity. The SubjectAltName in the client certificate (whi= ch is not even required to be used in standard SIP) can be checked against the domain part of the From header of the INVITE. The phone number and the granting-domain (which not even verified in VIPR) can be stored as an URI i= n the Issuer Alternative Name extension in the client certificate and be validated against the Request-URI of the INVITE. The granting node can be also be stored as a reload URI in an Issuer Alternative Name extension. So in conclusion, my proposal does not change what a normal SIP stack is doing, because the specification does not say what a SIP stack should do wi= th a client certificate. (Note that to -sip-antispam should also be added some text saying that RFC 5923 must be used, because there is no way to create an additional TLS connection in the other direction for a subsequent SIP transaction). On 09/03/2011 12:06 PM, Marc Petit-Huguenin wrote: In the current specification, the PVP server builds and signs a VIPR ticket, and send it back to the PVP client, that passes it to the Call Agent/ Border Element (CA/BE). The CA/BE will insert this ticket in the next SIP INVITE to the remote CA/BE, which will check the validity of the ticket and the domain of the TLS client. There is multiple things that bother me with this process: - The verification of the ticket use HMAC-SHA1, and so the same password has to be provisioned in both the CA/BE(s) (to verify the ticket) and the VIPR server(s) (to generate the ticket). - The ticket can be used without TLS (we all know that implementers think of MUST as SHOULD and SHOULD as MAY). I would like to propose an alternative that is simpler to implement and, I think, more secure than the ticket. Instead of using a symmetrical key, the local VIPR server generates an RSA key pair, with the public key distributed to the CA/BE(s). After a successful PVP connection, the remote PVP client sends a PKCS#10 certificate request, containing the domain name and signed with a private key[1]. The local PVP server generates a new certificate[2], sign it with its private key and send it back to the remote PVP client, which pass it back to the remote CA/BE. The remote CA/BE will use the certificate received to establish the TLS connection for the SIP transactions to the local CA/BE, which will use a standard CA based certificate for its domain. The local CA/BE will be able to verify with the VIPR public key that it issued the certificate, then will validate the standard parts of the certificate (expiration date and so on). There is multiple advantages to this proposal: - The private key is stored only in the VIPR server, or better in a physical token. - VIPR does not work without TLS for the SIP connection. - There is plenty of commercial or free TLS and X.509 implementations that have years of experience and testing, which is not the case for the ticket proposal. - Security agility is provided by TLS. - No additional SIP Header. - Because the ticket verification process is folded into the client certificate verification, there is less resources needed. [1] This is the private key of the CA/BE, so the CA/BE needs to upload the PKCS#10 file in the VIPR server. Depending on the architecture used, each CA/BE can use a different PKCS#10 or the same, which means that the PVP server must be able to process more than one PKCS#10 and send back more than one certificate on one PVP connection. [2] The certificate sent back can directly contain the SIP routes, increasing the overall security. One possible mapping from the ValExchange response to the certificate could be: - Unique ID: serialNumber - Epoch: issuer - salt: N/A - integrity: signature - Validity: validity - Phone Number: subjectAltName uniformResourceIdentifier tel:+14085551234 - Node-ID: subjectAltName uniformResourceIdentifier reload://0110123456789ABCDEF0123456789ABCDEF/ - Granted domain: subjectAltName dNSName example.com - Granting domain: i= mplicit in routes - Route(s): subjectAltName uniformResourceIdentifier sip:+14085551234@example.org:371;maddr=3D10.1.1.1 _______________________________________________ VIPR mailing list VIPR@ietf.org https://www.ietf.org/mailman/listinfo/vipr - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6XMLUACgkQ9RoMZyVa61dhCgCghMV7hIJ8Gcc1GZjGEiDflw44 kwkAn3zHPotOdEQRb4VQort1a8aYb/f4 =3DSlq9 -----END PGP SIGNATURE----- --_000_5143068F634B4578AA6D4EF902471B30neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I thought I did this, but here is my list of probl= ems associated with the ticket
as currently defined:

- - Use of a= symmetrical key, which has to be shared between different boxes if
the = generation of the ticket is done in a different box than the verification o= f
the ticket.

This was the onl= y problem you brought up during the call. I would say however that if you'r= e running a CA, then you need to share a great deal more than a symmetrical= key to validate signed messages. Unless the thing that issued the cert is = colocated with the box that acts as a TLS server, you're not going to be ab= le to avoid some communication between those boxes.

As I said on the call, there are a number of ways to address that need fo= r communication among distributed components that do not involve replicatin= g secrets, and those are part of the design space for addressing implementa= tions that want to distribute these components.

- - No security agility.

I assume you mean algorithm agility. TLS does have a great deal of latitu= de here, it's true, including the ability to set a null cipher suite. You'r= e going to end up having to narrowly profile TLS for the application if you= want to achieve any measure of interoperability or security. SIP, for exam= ple, is pretty specific about what algorithms you use with TLS. If you want= to change the recommended algorithm, you will still be iterating your spec= ifications and rolling out new versions.

<= div>- - Code has to be written from scratch for both the generation and the=
verification of the ticket.

I= 'm dubious that any off-the-shelf CA library will enable you to put attribu= tes like granted-by and so on into certificates without putting any signifi= cant burden on implementers, let alone parsing and verifying those attribut= es as a step in validating a TLS connection.


I've taken a look at the sketch of your proposal below, but it's a bit = too
high level for me to really u= nderstand its properties. I will say that if
your argument is:
my propos= al does not change what a normal SIP stack is doing, because the
spec= ification does not say what a SIP stack should do with a client
certi= ficate.

I have to disagree. 5922 cites the relevant = text in 3261: Each side of the
co= nnection SHOULD verify and inspect the certificate of the other, noting the=
domain name that appears in the = certificate for comparison with the header
fields of SIP messages.  Now by today's standards, that text= is somewhat
vague, but back when= we wrote that the idea was basically that you compare
the domain in the cert (typically the CN or SubjectAl= tName) used in TLS with
the suppo= sed identity of the sender of a request over that transport
connection (typically given in the From header f= ield value). That works when
the = cert has been issued by an authority capable of ascertaining who owns
domain names. 5922 introduces qualific= ations to this in order to support
cases where a virtual hosting service has a certificate with multiple nam= es,
for example, but it isn't rea= lly chipping away at the basic operation.

Let me offer = a more complete quote of RFC 5922:

" RFC 3261 [2], Section 26.3.2.2,= only tells Proxy-B to "compare the
 domain asserted by the certif= icate with the 'domainname' portion
 of the From header field in t= he INVITE request".  The difficulty
 with that instruction is= that the domainname in the From header
 field is not always that = of the domain from which the request is
 received."

So here= RFC 5922 acknowledges that doing this verification is not possible in
a= ll cases.  The minimum should have been to do an RFC 5280 validation, = but even
that is not required.

RFC3261 still naively assumed a SIP trapezoid. ViPR does as well, but much= less naively. The notice given in here in RFC5922 is about cases where an = intermediary domain prevents the establishment of a direct TLS connection. = If we have an intrusive intermediary in ViPR, then yes, you'll have a failu= re establishing reference integrity. However, I'd say that the whole, entir= e point of doing ViPR, of using RELOAD as a foundation, was to establish di= rect connections between ViPR domains without relying on any intermediary i= nfrastructure. ViPR is by design a dis-intermediation mechanism. (This is i= n danger of being the intermediary discussion again - hopefully this isn't = one of the "hooks" that we're fishing for.)

Anyway= , 5922 is speaking to a subset of SIP TLS behavior - behavior, incidentally= , that has been controversial in all of the protocols that rely on TLS, lik= e virtual hosting cases and proxying cases. We should be using that as a de= parture point to argue that reference integrity isn't a desirable or necess= ary property, especially not in ViPR. That is not the intention behind RFC5= 922.


= ViPR
today, as you cite, requires= that same reference integrity between the
granted-to field of the ticket and the domain in the cert used in= TLS. Again,
the idea here is tha= t the granted-to has to correspond with a cert issued by
an authority who actually verifies ownership of dom= ain names. Thus, purely on
the ba= sis of capturing a ticket with a granted-to of example.com, you cannot
im= personate example.com unless you also co= ntrol a cert issued for that domain
by a CA, and incidentally a CA trusted by the target ViPR domain. If you= are
arguing for a case where a V= iPR domain that is not in a position to certify
who owns what domain names is issuing certificates that are = used for TLS,
then you are changi= ng how certificate usage in SIP is commonly understood.
Yes, you have a point here.  Verifying the granted-to domain at call = time will
prevent someone to use a stolen ticket, and will prevent the g= ranted-to domain
to sell their tickets (although a domain can sell its p= rivate key also with the
tickets).

So if this verification is rea= lly that important (still thinking about this), I
guess that using the t= icket as the client certificate is a problem.  But in any
case I st= ill think that using an X.509 certificate in the Vipr-Ticket field is a
= better solution than using an adhoc ticket as described currently in VIPR.<= br>

Again, I think this would need to= be far more thoroughly specified for us to be able to evaluate the idea. I= gather you mean that you could just put the signature generated by the cer= t into the ticket's header field value. That is a much less radical proposa= l than doing this at the transport layer. We'd then need to evaluate, again= , how those certs get created, installed and validated, and whether or not = this truly solves your problem with distributed components - or if indeed t= here are other ways entirely to approach the distributed components problem= that changing the way the ticket is secured, and which ways would require = the least work.



From what I can gather about your proposal, I suspect you underestimat= e the
complexity of acting as a CA, enrolling peers in the CA and ena= bling them
to use those credentials properly

I do not underestimate anything.  On the other hand the CAs c= ertainly
overestimate the value of their services, especially on the lig= ht of the recent
problems some of them experienced.  Running a CA i= s not difficult, and the best
proof is that RELOAD (draft-ietf-p2psip-ba= se section 10.3) requires running it's
own CA in a way that is similar t= o what I propose.


I rather th= ink the recent CA problems are an illustration of how easy it is to do thin= gs wrong. I look forward to reading your CPS.

Hone= stly, this would be a lot easier to swallow if you proposed just to generat= e a public/private key pair without all the X.509 baggage. I really don't s= ee how a certificate adds any value, except in so far TLS requires them, bu= t if you're willing to move this to a header field, X.509 would be the firs= t thing I'd drop.

- what it means for two entities that
have no pre-existing relationship to suddenly treat each other as trus= t
anchors. I furthermore suspect that TLS operations would not be o= ptimal in
this sort of model. Is the antispam property something that= is best bound
to the transport or to a single SIP request? The use c= ases, ultimately,
answer that for us: consider two large ViPR domains= that want to exchange
traffic - should they have to establish a new = TLS connection for each
called number, or should they be able to send= signaling for many calls over
a single TLS connection? Are there cas= es where the hop-by-hop property of
TLS weakens the utility of the me= chanism? Are there environments we want
ViPR to be useful where TLS i= s not available?

Here you are not talking = about my proposal, but about VIPR itself, as it already
requires TLS. &n= bsp;That's a different problem.

=

If ViPR Domain A nails up a T= LS connection to ViPR Domain B, in the original ViPR plan as I understand i= t, the (public) cert presented by A in TLS is compared to the granted-to of= tickets by B when A sends requests over that connection. A could send thou= sands of different requests, from thousands of different callers, to thousa= nds of different destinations, over the same TLS channel, because the chann= el is bound to the domain and not to any specific ticket. Unless I totally = misunderstand your proposal, you are changing that, right? You want to inst= antiate the antispam function at the establishment of a TLS connection. The= issue is that in SIP, call signaling isn't necessary bound to the establis= hment of an underlying transport.

Agreed, however,= that ViPR does basically require TLS today, so if TLS isn't available, tho= se parts of the spec as written today would't work, so that isn't a problem= with your proposal as such - though perhaps your (original) proposal would= make adjusting the spec to fix that impossible.

J= on Peterson (as an individual)
NeuStar, Inc.


Jon Peterson (as an individual) NeuStar, Inc.

On Oc= t 12, 2011, at 3:53 PM, Marc Petit-Huguenin wrote:

During the las= t conference call, this proposal was criticized as been a
<= blockquote type=3D"cite">significant change from the way SIP is processing = TLS requests.  My research
s= hows that it is not the case.
First of all, let's define exactly = what SIP, without even talking about VIPR,
is doing regarding TLS.  The best place for this is RFC 5922= .  We can skip
the client be= havior discussion (section 7.3) because neither VIPR or my
=
proposal suggest any modification to this procedu= re.  Here's what RFC 5922
sa= ys about the server behavior (aka client certificate):

"  Wh= en a server accepts a TLS connection, the server presents its own X.509
=
certificate to the client.  Ser= vers that wish to authenticate the client will
ask the client for a certificate.  If the client possess= es a certificate,
that certificat= e is presented to the server. If the client does not present a
certificate, the client MUST NOT be considere= d authenticated.

[...]
=
When authenticating the client, = the server MUST obtain the set of SIP domain
identities from the client certificate as described in Section = 7.1.  Because
the server acc= epted the TLS connection passively, unlike a client, the server
does not possess an AUS for comparison. &nbs= p;Nonetheless, server policies can use
the set of SIP domain identities gathered from the certificate in Sec= tion 7.1
to make authorization de= cisions.

For example, a very open policy could be to accept an X.= 509 certificate and
validate the = certificate using the procedures in RFC 5280 [6].  If the
certificate is valid, the identity set is log= ged.

Alternatively, the server could have a list of all SIP domai= ns the server is
allowed to accep= t connections from; when a client presents its certificate,
for each identity in the client certificate, the= server searches for the
identity= in the list of acceptable domains to decide whether or not to accept
the connection.  Other policies t= hat make finer distinctions are possible."

In other words, the SI= P server (or proxy) does whatever it thinks is
necessary with the client certificate, and it does not seems = that even
following RFC 5280 is r= equired (note in particular that nowhere it is said
that the validation must use a public trust anchor).
=

VIPR itself adds very little to the requirements of RFC 5922.  = Here is what
-sip-antispam says a= bout TLS and the ticket:

"  The Border Element will receive = the TLS ClientHello which begins the TLS
handshake.  The Border Element will present its own configur= ed cert.  Once
TLS handshaki= ng is complete, the Border Element notes the domain from the
SubjectAltName on the other side of the TLS con= nection, and associates it
with t= hat connection.

=
Next, the Border Element will receive an INVITE. =  This INVITE will contain a
= ticket in the ViPR-Ticket header field value.  The Border Element extr= acts
this header field.  Thi= s call flow assumes it is present.  The Border Element
parses it, and obtains the epoch value encoded i= n the ticket.  This is
match= ed against the current epoch value for the configured password.  If th= ey
match, processing continues. &= nbsp;The Border Element verifies the signature is
correct. Next, it examines the start and stop time of the = validity.  If the
current ti= me is between the start and stop times, the check is passed.  Next,
the Border Element checks the grant= ed-to domain in the ticket.  It compares
that domain against the domain name in the SubjectAltName of t= he peer on the
other side of the = TLS connection, as noted above.  Next, it takes the
Request-URI of the SIP INVITE. That will be of the = form sip:+number@domain.
If it is not in that form, and if the number do= es not begin with a plus, the
req= uest is dropped.  The value, including the plus, is then compared to t= he
number in the ticket.  If= it is equal, the check has passed.  The Border
Element leaves the header field in the request, but for= wards to the Call
Agent."

The only policy that is added to what RFC 5922 says is that the granted-= to
domain in the ticket must be e= qual to the domain in the SubjectAltName of
the client certificate.  Here too, not a word about a publi= c trust anchor.

=
Now back to my proposal.  The first thing is= that the client certificate must
be validated using the CA of the VIPR server as trust anchor, which is
=
already what a SIP server could do. =  It validates according to the rules in
RFC 5280, which is equivalent to verifying the signature of the= ticket and
the start/stop validi= ty.  The SubjectAltName in the client certificate (which
is not even required to be used in standard SI= P) can be checked against the
dom= ain part of the From header of the INVITE.  The phone number and the
granting-domain (which not even ve= rified in VIPR) can be stored as an URI in
the Issuer Alternative Name extension in the client certificate a= nd be
validated against the Reque= st-URI of the INVITE.  The granting node can be
also be stored as a reload URI in an Issuer Alternative= Name extension.

So in conclusion, my proposal does not change wh= at a normal SIP stack is
doing, b= ecause the specification does not say what a SIP stack should do with
a client certificate.
=

(Note = that to -sip-antispam should also be added some text saying that RFC
5923 must be used, because there is no = way to create an additional TLS
c= onnection in the other direction for a subsequent SIP transaction).

On 09/03/2011 12:06 PM, Marc Petit-Huguenin wrote:
In the current specification, the PVP server builds= and signs a VIPR
ticket, and send it back to the PVP client, that= passes it to the Call
Agent/ Border Element (CA/BE).  The CA= /BE will insert this ticket in
the next SIP INVITE to the remote C= A/BE, which will check the validity
of the ticket and the domain o= f the TLS client.

There is multiple things that bother m= e with this process:

- The verification of the ticket us= e HMAC-SHA1, and so the same
password has to be provisioned in bot= h the CA/BE(s) (to verify the
ticket) and the VIPR server(s) (to g= enerate the ticket). - The ticket
can be used without TLS (we all = know that implementers think of MUST as
SHOULD and SHOULD as MAY).=

I would like to propose an alternative that is simpler = to implement
and, I think, more secure than the ticket.
<= br>
Instead of using a symmetrical key, the local VIPR server generat= es an
RSA key pair, with the public key distributed to the CA/BE(s= ).  After a
=
successful PVP connection, the remote PVP client = sends a PKCS#10
<= blockquote type=3D"cite">certificate request, containing the domain name an= d signed with a
<= blockquote type=3D"cite">private key[1].  The local PVP server generat= es a new certificate[2],
sign it with its private key and send i= t back to the remote PVP client,
=
which pass it back to the remote = CA/BE.

=
The remote CA/BE will use the certificate receive= d to establish the
<= blockquote type=3D"cite">
TLS connection for the SIP transactions to the = local CA/BE, which will
use a standard CA based certificate for it= s domain.  The local CA/BE
<= /blockquote>
will be able to verify with the VI= PR public key that it issued the
=
certificate, then will validate t= he standard parts of the certificate
(expiration date and so on).<= br>

There is multiple advantages to this proposal:

- The private key is stored only in the VIPR server, or better= in a
physical token. - VIPR does not work without TLS for the SIP=
connection. - There is plenty of commercial or free TLS and X.509=
implementations that have years of experience and testing, which = is not
the case for the ticket proposal. - Security agility is pro= vided by
TLS. - No additional SIP Header. - Because the ticket ver= ification
process is folded into the client certificate verificati= on, there is
less resources needed.
<= /blockquote>


[= 1] This is the private key of the CA/BE, so the CA/BE needs to upload
the PKCS#10 file in the VIPR server.  Depending on the architectur= e
used, each CA/BE can use a different PKCS#10 or the same, whic= h means
that the PVP server must be able to process more than one = PKCS#10 and
send back more than one certificate on one PVP connect= ion.

[2] The certificate sent back can directly contain = the SIP routes,
<= blockquote type=3D"cite">increasing the overall security.  One possibl= e mapping from the
<= blockquote type=3D"cite">
ValExchange response to the certificate could b= e:

- Unique ID: serialNumber - Epoch: issuer - salt: N/= A - integrity:
signature - Validity: validity - Phone Number: subj= ectAltName
uniformResourceIdentifier tel:+14085551234 - Node-ID: s= ubjectAltName
uniformResourceIdentifier
reload://0110123456789ABCDEF012345= 6789ABCDEF/ - Granted domain:
subjectAltName dNSName example.com - Granting domain: implicit in
<= /blockquote>
routes - Route(s): subjectAltName uniformResourceIdentifier
<= a href=3D"sip:+14085551234@example.org:371;maddr=3D10.1.1.1">sip:+140855512= 34@example.org:371;maddr=3D10.1.1.1



__________________________________= _____________
VIPR mailing list
VIPR= @ietf.org
https://www.ietf.org/mailman/listinfo/vipr

- --
= Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professio= nal email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk6XMLUACgkQ9RoMZyVa61dhCgCghMV7hIJ8Gcc1GZjGEiDflw44
kwkAn3= zHPotOdEQRb4VQort1a8aYb/f4
=3DSlq9
-----END PGP SIGNATURE-----

= --_000_5143068F634B4578AA6D4EF902471B30neustarbiz_-- From dean.willis@softarmor.com Thu Oct 13 15:23:25 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A890521F8B8F for ; Thu, 13 Oct 2011 15:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH-NumExkZf2 for ; Thu, 13 Oct 2011 15:23:25 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.213.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0450621F8B84 for ; Thu, 13 Oct 2011 15:23:24 -0700 (PDT) Received: by yxn35 with SMTP id 35so125802yxn.38 for ; Thu, 13 Oct 2011 15:23:20 -0700 (PDT) Received: by 10.150.244.20 with SMTP id r20mr6418581ybh.50.1318544600495; Thu, 13 Oct 2011 15:23:20 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id m3sm3438121ang.0.2011.10.13.15.23.18 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 15:23:18 -0700 (PDT) Message-ID: <4E9764D5.2020408@softarmor.com> Date: Thu, 13 Oct 2011 17:23:17 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: vipr@ietf.org References: <4E627AB4.7070806@acm.org> <4E961A6B.2090603@acm.org> <5C4D5C85-A551-4E11-A5D6-FCC56C56A1B3@neustar.biz> In-Reply-To: <5C4D5C85-A551-4E11-A5D6-FCC56C56A1B3@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [VIPR] An alternative to the VIPR ticket X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 22:23:25 -0000 On 10/13/11 12:25 PM, Peterson, Jon wrote: > I furthermore suspect > that TLS operations would not be optimal in this sort of model. Is > the antispam property something that is best bound to the transport > or to a single SIP request? The use cases, ultimately, answer that > for us: consider two large ViPR domains that want to exchange traffic > - should they have to establish a new TLS connection for each called > number, or should they be able to send signaling for many calls over > a single TLS connection? Are there cases where the hop-by-hop > property of TLS weakens the utility of the mechanism? Are there > environments we want ViPR to be useful where TLS is not available? Perhaps the ViPR domain intermediaries shouldn't be cryptographically involved in TLS at all. See: http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01 -- Dean From petithug@acm.org Mon Oct 17 08:46:17 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB36521F84FD for ; Mon, 17 Oct 2011 08:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoKWfGJ93v0o for ; Mon, 17 Oct 2011 08:46:15 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A429021F8BAD for ; Mon, 17 Oct 2011 08:46:15 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 43ABF2025C for ; Mon, 17 Oct 2011 15:38:27 +0000 (UTC) Message-ID: <4E9C4DC4.9080901@acm.org> Date: Mon, 17 Oct 2011 08:46:12 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Minutes for 2011/10/14 conference call X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:46:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 VIPR Design Team conference call on Friday October 14th, from 9:05am to 9:50am PST. o Attendees: Daryl Malas Hakim Mehmood Muthu Arul Mozhi Perumal Jon Peterson Marc Petit-Huguenin Michael Procter Dean Willis o Regrets: Mary Barnes John Ward o Agenda - - Replacement ticket by client certificate (10 min) - - PVP method priority and registration (10 min) - - PVP privacy (10 min) - - PVP method entropy (10 min) - - Ticket renewal (10 min) - - Infrastructure overlays (5 min) o Action items - - Add template for IANA registration for PVP methods, with priority. - - Work on new method inverting the selector with the secret. - - Send an email in the list detailing the entropy solutions (client-side vs server-side). o Minutes - - Replacement ticket by client certificate Marc: The goal of this meeting is to discuss items that are not discussed in the mailing-list, and as there is good discussions on the mailing-list about this item, I propose to skip it for this conference call. - - PVP method priority and registration Marc: There is currently two PVP methods defined in the draft: method "a' which use the caller and callee number, and method "b" which uses the callee number and the time in the middle of the call. But there is more methods that can be used (fingerprint, DTMF, SMS, etc...). The first part of the proposal is to establish a IANA registry for new methods and to assign a priority to each method. The second part of the proposal is to advertize the methods supported by the PVP server in the RELOAD database, to accelerate the validation process. The third part of the proposal is to move the PVP algorithm into -framework and to keep only the description of the methods in -pvp. Hakim: So the proposal is to put the priority of the methods for PVP. Marc: I was proposing to put only the list of methods supported. I am not sure it is interesting to put also the priority in the RELOAD database. Hakim: OK, its just a list of methods supported for this particular resource. Marc: Yes, and this should not be an issue for security. Jon: It would matter if one method was weaker than another and a domain was claiming it prefers it. Marc: That's a good reason to not put the priority in the RELOAD database. Jon: From an administrative point view, you do not have to move out the current methods to provide a template. Also how an implementation knows if Caller-ID is going to work or not? That maybe specific to the method, so can you really say at the registry level that a method will work or not? Marc: If a domain will never ever receive the Caller-ID, then it should not advertize method "a". But if there is a chance that method "a" succeed, then it should advertize. Jon: So anything that could work, you will ask to try it. Marc: Yes, but the advantage is that methods we are absolutely sure that will not work, like SMS on a non mobile connection, can be excluded. If you have no access to the audio stream, then a method using fingerprint can also be excluded. Jon: OK, there is language that can capture that. Marc: And what about priority in the IANA registry? Hakim: That's fine. Jon: The more methods we have, the more an attacker will be able to choose the weakest. So I think that what it will come down to what we think our requirements a method has to meet to validate. Until we understand that, it will be tough to say that all these methods are secure. Marc: In the framework document, I will list exactly what should be in the document defining a method. - - PVP privacy The problem, reported by Michael Procter, is that the Caller-ID is send in clear in method "a". I proposed three additional definitions, to make the discussion on this topic easier. The PVP selector, which is sent in clear, is used to select the call record on the server side. In method "a" the selector is the called number and the Caller-ID, in method "b", it is the called number and the time in the middle of the call. The PVP parameters are a set of parameters that are also sent in clear, for example the rounding value for "a" and "b". The PVP secret is what is verified, and cannot be discovered if the verification fails. For the two methods, it is the beginning and end of the audio call. The privacy problem here is that someone can register a phone number and knows who is calling this phone number. There was a discussion on the mailing between Michael and Cullen Jennings, where the idea was to hash the phone numbers. But perhaps that instead of fixing methods "a" and "b" we should just create new methods. So a first new method is to use the same than "a", but hashing with something like bcrypt. A second new method would be to invert the selector and the secret. Hakim: If I understand correctly, the problem here is that someone can learn who calls. Marc: Yes Jon: Hashing is a speed bump, but I suspect not worth enough to do it. The idea of inverting the secret with the selector is interesting. I agree that the call start and stop is not sufficiently unique and it has the property that the more people are using VIPR the more likely there will be collision. But it can be combined with part of the numbers, i.e. area code or area code and prefixes that are longer. Hakim: Method "a" is more secure than method "b", but method "b" is not exposing the Caller-ID at all, so domains that have concerns over privacy simply do not advertize method "a". Marc: The problem is that method "b" probably does not have enough entropy. Hakim: Yes, it does circumvent to some extend the security concerns. Marc: So do we want to fix the two methods, or keep them as they are and define new methods? Hakim: Invent new methods. Jon: The problem is that if we invent new things that are less secure, then people will use them. Hakim: I do not disagree with that. Marc: True, but "b" is already not very secure. We cannot make something less secure than "b", and we can simply say that we cannot have a method less secure than "b". Jon: Let's figure how secure "b" is first. If we find that "b" is unacceptable, then we may not want to do that. Michael: We need to understand what the tradeoff are between have enough entropy for a reliable call identification compared to leaking too much information. Marc: I am personally on working on new methods and put explanations on the security section of the current methods saying, do not use this. - - PVP method entropy Marc: Method "b" provides less entropy than method "a", which itself provides less entropy than the future methods. The idea is to accumulate entropy, so a domain can require more than one validation before sending back a route and a ticket. Instead of sending back a route and ticket, the server sends back a temporary ticket that contains the entropy accumulated, which is sent during the next attempt at validation. It fits well with what we talked before, priority, and the fact that some methods have less security than other. We can put in the IANA registry the entropy that a specific method would accumulate. Jon: I do not understand the way entropy is calculated but someone should figure out if that actually works. Marc: But is it a direction we want to go to? Jon: The goal of VIPR is to reduce as much as possible the number of calls to the PSTN, so something that would require more of those is undesirable. We need to evaluate what we get in return. Is there alternative that accomplish the same thing? We can use probe calls during off hours. If we decide to do this, we really need to decide what the goals are. Marc: The goal is to make method "b" better than what it is, because it is will the best that some domains will be able to do. I not would like to exclude method "b" because it would exclude a lot of domains from VIPR. Jon: Do we have a sense of how many people are excluded by this today? Marc: This is all the cases where we do not have the Caller-ID. Jon: How many things that we think will participate in VIPR have PRI? Hakim: The problem is not necessarily not having access to Caller-ID, but how enterprise domains send Caller-IDs that are the Caller-Id of the enterprise versus the calling entity. Jon: But for VIPR purpose it still works. Hakim: No it does not because it would create an issue when you match the ticket. Jon: What I am asking is about the 80/20 rule. Does it happen 20% of the time, 1% of the time or 0.1% of the time? Hakim: It's in the 20%. Dean: The majority of PBXs send their trunk number, so we are talking about how many PBXs versus SOHO devices. Jon: If it's 20% we need to do something, if it's 1% we should do something, if it's less than 1%, I do not care. Hakim: For sure it's not 1%, but somewhere close. Michael: For people that are making international calls, like videocalls to grandma, then using the CLI will fail more often than it succeeds. Daryl: Good point. Michael: If you are talking of calls between enterprises, then yes Caller-Id will work most of the time. Jon: I am not really sure that this is for grandmas, because things for grandmas do not have this property that VIPR has. But point taken about the international call issues. Marc: One thing I would like to add is that we are not reducing the user experience, because the 3 calls are at the beginning. So doing this is acceptable. What is unacceptable would be to switch back to PSTN after having video. Jon: I do think that it is a problem. It's not unacceptable, but it's undesirable. It's not just video, it's wideband audio, it's presence, and it's our job here to find the quickest way to enable this. And if the way is to have 3 PSTN calls, it's definitively undesirable. Hakim: I agree. It's the #1 complaint I see today. That it takes 24 hours, all these things. Marc: I agree that we need to design methods that does this faster. But we still need to have a bottom line which is method "b" because this is how we will have many people in the overlay. We should not require an SS7 connection to participate in VIPR. Marc: We need to decide if we want to talk about entropy or not at all. Hakim: Is it possible to keep the guidance here, and let the implementers decide? Marc: We still need a way to manage the entropy. It can be a PVP server side thing, where the server keeps a log of all the calls. Or it can be done on the PVP client side, in which case we have to define what is exchanged. Hakim: My preference would be server-side. Marc: My preference is client side. Jon: We need to think more about what we need to accomplish. Dean: Post the question on the mailing-list. Marc: OK, I'll do that. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6cTbgACgkQ9RoMZyVa61d1GwCfZdYZAScs6i5RddfNN54JVidQ HnUAn3i+Dg4F62dEaPyziwUTV5F5V69+ =XiDY -----END PGP SIGNATURE----- From petithug@acm.org Mon Oct 17 08:49:40 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA2E21F8CDE for ; Mon, 17 Oct 2011 08:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.036 X-Spam-Level: X-Spam-Status: No, score=-102.036 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kejyr0PH1Oe for ; Mon, 17 Oct 2011 08:49:40 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id DEA4B21F8CDD for ; Mon, 17 Oct 2011 08:49:39 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 853762025C for ; Mon, 17 Oct 2011 15:41:52 +0000 (UTC) Message-ID: <4E9C4E92.1060703@acm.org> Date: Mon, 17 Oct 2011 08:49:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Using only method "b" for privacy X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:49:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 During the conference call last Friday, we had a discussion on which the conclusion was that privacy conscious VIPR domains could simply require the use of method "b" for validation, as this method does not send the Caller-ID in the PVP login, and so does not disclose the phone number of the callers to VIPR domains that registers the phone number of one of their competitors. Unfortunately, I do not think that doing this would work. Here's a diagram explaining that: DomainA RELOAD DomainB DomainC | | Store| | 1 | |<-------| Store | 2 | |<-------------------| : : : : | SETUP | | | 3 |~~~~~~~~~~~~~~~~~~~~~| | | | | | 4 |<~~~~~~~~~~~~~~~~~~~~| | : : : : | Fetch | | | 5 |----------->| | | | PVP | | | 6 |::::::::::::::::::::::::::::::::X| | PVP | | | 7 |::::::::::::::::::::>| | | | | | In 1, the legitimate "owner" of the phone number registers a mapping between this number and its PVP server in the distributed RELOAD database. In 2, a competitor registers its own PVP server for the same phone number. In 3 and 4 we have the PSTN call itself, that generates the originating VCR in domain A and the terminating VCR in domain B. Shortly after this, 5 shows that DomainA retrieved the mappings for the called phone number, and so retrieved the address of the PVP servers from DomainB and DomainC, without knowing which one is the "owner". It starts a PVP transaction with both of them, with the transaction to DomainC failing because DomainC does not know the PVP secret, and the one with DomainB succeeding. Now even if DomainB is privacy conscious and refuses to process PVP transactions using methods "a", that does not prevent DomainC to accept transactions using methods "a", and so permitting it to learn the caller number. Even using the registration mechanism, where the Store also contains the list of methods supported by a specific endpoint, does not fix this problem. The problem here is that DomainA needs to be privacy conscious on behalf of the remote domains, and never use method "a". One simple solution is to never even define method "a", so it can never be used. That is a change from what was discussed during the conference call, which was to keep method "a" and "b" as they are, and to define better methods. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6cTpEACgkQ9RoMZyVa61cdlgCdEOdZT6gQbJcCWxXZr0CJOtxb KxEAnRAQGvMEVThQE+DrVP8JnPYVoy2X =h5qq -----END PGP SIGNATURE----- From petithug@acm.org Tue Oct 18 08:49:39 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE4521F8B88 for ; Tue, 18 Oct 2011 08:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zS3GNxJ45gc for ; Tue, 18 Oct 2011 08:49:38 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD6021F8B77 for ; Tue, 18 Oct 2011 08:49:38 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 623EB204AD for ; Tue, 18 Oct 2011 15:41:44 +0000 (UTC) Message-ID: <4E9DA00C.90704@acm.org> Date: Tue, 18 Oct 2011 08:49:32 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: vipr@ietf.org References: <4E63E52D.3020101@acm.org> In-Reply-To: <4E63E52D.3020101@acm.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [VIPR] PVP entropy X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 15:49:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The discussion on the subject of PVP entropy on the last conference call did not reach consensus. The -pvp draft already contains a placeholder for discussing entropy (section 10.1), so we need to do something about this. The various proposals were: 1. We do not need to manage entropy because we do not want to have the user making multiple PSTN calls before receiving a SIP route. 2. We need to manage entropy, but it is best managed completely in the PVP server. 3. We need to manage entropy, but it is best managed in both client and server by using something like a cookie. My proposal is 3, as detailed below. I think that 1 would exclude too many participants in VIPR, so I oppose it. On 09/04/2011 01:53 PM, Marc Petit-Huguenin wrote: > Section 10.1 of the -pvp draft is an empty section that is supposed to describe > how to aggregate entropy. The idea is that the fact that one validation > succeeds could not be enough for a remote VIPR server to give back routes and > ticket for this destination. For example a site could decide that 3 different > calls validated with method "b" are needed to let a SIP call reach the endpoint. > > This proposal describes a mechanism for PVP to implement this. The idea is that > when a PVP validation succeeds, the PVP server will return a ticket[1] but may > not return the list of routes if the entropy threshold is not reached. The > ticket will contain an opaque value set by the PVP server that contain the level > of entropy that this caller has reached. The PVP client stores the ticket but > does not notify the call agent as there is no routes available. The next time > the PVP client has a successful validation with the same destination, it sends > the saved ticket in addition to the domain. The PVP server then evaluates the > ticket, increases the entropy value stored and send back a new ticket back. If > the threshold has been reached, then the PVP server sends back the routes at the > same time, routes that the PVP client can now send with the ticket to the call > agent. > > When renewing the routes/ticket, the PVP client also sends the existing ticket, > so the PVP server can decide to lower the threshold based on the entropy > collected the previous time and the date of the ticket. > > This can be combined with my proposal for method priority. If multiple methods > are available for a destination but the first that succeeds does not return the > routes then the PVP client can use the next available methods in the list to try > to increase the entropy and receive them. > > A PVP server may even use different thresholds, depending on the domains to > validate. This become then an extension to the white/black list, where a > blacklist is implemented as a default threshold of X and a infinite threshold > for the domains blacklisted, and where a whitelist is implemented as a default > infinite threshold and a threshold of X for the domains whitelisted. > > > [1] Or a certificate if my other proposal is accepted. > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6doAoACgkQ9RoMZyVa61eFWQCgpPz2uKruKPkQlG0X9vMrppm8 ZMwAoKZ3VL1T7UtCEoHrrIKujEmxs4Ek =mVG9 -----END PGP SIGNATURE----- From petithug@acm.org Tue Oct 18 12:46:35 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159C221F8D14 for ; Tue, 18 Oct 2011 12:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3D0NIV95X9VP for ; Tue, 18 Oct 2011 12:46:34 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 4806C21F8CC9 for ; Tue, 18 Oct 2011 12:46:34 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 04B6A204AD for ; Tue, 18 Oct 2011 19:38:39 +0000 (UTC) Message-ID: <4E9DD795.2090603@acm.org> Date: Tue, 18 Oct 2011 12:46:29 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Hashing the Caller-ID to increase privacy in PVP X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 19:46:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 During the last conference call, the proposal for using hash to protect the privacy of the caller in VIPR was summarily dismissed. I would like to give it another shot. The idea is that when using method "a", the Caller-ID is hashed using the bcrypt hash algorithm[1], and the resulting hash is passed in the login of the SRP-TLS transaction. On the PVP server side the code retrieves the list of all calls made to the called number (which is in clear), extracts the salt from the hash, rehashes the Caller-ID of the calls selected, and selects the most recent call that have a Caller-ID that matches the hash received. Now a VIPR domain that would want to now the Caller-ID of the callers of a specific phone number will have to hash a good part of the E.164 space to have a chance to find the Caller-ID. If the target is a 1800 number, so the attacker can restrict the search space to the +1 prefix, it will need to hash in average half this space, which is something like 1.3 billion numbers. The beauty of the bcrypt algorithm is that the number of rekeying rounds is configurable, and so it can be increased as the hardware becomes faster. For example on my computer, it takes 1.3 ms to hash a US number when using 2^4 rounds, but 100 ms when using 2^10 rounds. That means that it will take 4 years to hash half of the USA phone numbers on one processor (adding more processors decreases the hash time linearly). The number of rounds could be a parameter of the VIPR overlay. Here's what the login could look like: a:vs=7f5a8630b6365bf2;op=$2a$10$uhNBlMT5O063n5/YMlg3Y.xTmZuHMeAFbSxhwSacX87aujFxPvoxG;tp=+16504614667;r=1000; Exercise for the skeptical: Make a phone call to the originating phone number in this example... [1] http://www.usenix.org/event/usenix99/provos/provos.pdf - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6d15QACgkQ9RoMZyVa61d02gCdFQ9UrUPImamyFj5XJTqUTY7R OFkAoI178ri6Mjpx32LDVtXpmYOb8ldM =Rvv3 -----END PGP SIGNATURE----- From petithug@acm.org Thu Oct 20 07:17:01 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF02421F8997 for ; Thu, 20 Oct 2011 07:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhQ5LhhHIv6b for ; Thu, 20 Oct 2011 07:17:01 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 4018A21F86AA for ; Thu, 20 Oct 2011 07:17:01 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 85ADC20878; Thu, 20 Oct 2011 14:08:58 +0000 (UTC) Message-ID: <4EA02D56.1020807@acm.org> Date: Thu, 20 Oct 2011 07:16:54 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Dean Willis , "Hakim Mehmood (naim)" , Michael Procter , John Ward , 'Mary Barnes' , "Muthu Arul Mozhi Perumal (mperumal)" , Daryl Malas , Jon Peterson , "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] No conference call tomorrow X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:17:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Been sick since yesterday, I am not able to work on the agenda and handout for tomorrow's meeting. So unless someone want to take over, I propose to cancel this call, and to resume the normal conference call next week. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6gLU8ACgkQ9RoMZyVa61cIZACfTbiMZZFj/O6DTuzAbqWrRaPG Wx0An2PEqZvjvOLGo8/SK9u7Fb30hbZ5 =9MYq -----END PGP SIGNATURE----- From naim@cisco.com Fri Oct 21 08:56:38 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9D11F0C62 for ; Fri, 21 Oct 2011 08:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srbZ1qqlzWNs for ; Fri, 21 Oct 2011 08:56:38 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1436721F8B04 for ; Fri, 21 Oct 2011 08:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naim@cisco.com; l=1404; q=dns/txt; s=iport; t=1319212598; x=1320422198; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=0K7GhPhNMrxugd40wCsbv8/0hDABdo13ZXM9RsN5uw4=; b=d4Rm2q3a4TkpefGQq+4lZDmGvbIrXEZd1DoTH3zT+cX2W6YGBABaIIFS Vtioxwa39FBiOCLq2SG7I9xbJtAPVVE5w7MIlBqN769jlZRTBCi0Ev0SV z7H7gWOpar+BfhccrBziHZ9z2OP8U4MoB/PpaPQfP9NdOtMFtZCjYWii+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAHaVoU6rRDoG/2dsb2JhbABDhHWUaY4/gQCBBYFuAQEBBBIBEA0ENB0EAgEIEQQBAQMCBgYXAQICAgEBRAkIAQEEARIIGodmlWEBjEWRe4EwhXwzYQSIA5EzjEU X-IronPort-AV: E=Sophos;i="4.69,386,1315180800"; d="scan'208";a="9407606" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 21 Oct 2011 15:56:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9LFubLi013957; Fri, 21 Oct 2011 15:56:37 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 08:56:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 21 Oct 2011 08:56:35 -0700 Message-ID: <3175C4C5F682C145B25808EB5737F16C0EEF32B7@xmb-sjc-21b.amer.cisco.com> In-Reply-To: <4EA02D56.1020807@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: No conference call tomorrow Thread-Index: AcyPMvYtjG9T9imFRka+Y4V6lwnirQA1wF1A References: <4EA02D56.1020807@acm.org> From: "Hakim Mehmood (naim)" To: "Marc Petit-Huguenin" , "Dean Willis" , "Michael Procter" , "John Ward" , "Mary Barnes" , "Muthu Arul Mozhi Perumal (mperumal)" , "Daryl Malas" , "Jon Peterson" , X-OriginalArrivalTime: 21 Oct 2011 15:56:37.0284 (UTC) FILETIME=[03AFFE40:01CC900A] Subject: Re: [VIPR] No conference call tomorrow X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:56:39 -0000 U28gc2hvdWxkIHRoZSBjYWxsIGJlIGNvbnNpZGVyZWQgY2FuY2VsbGVkIGZvciB0b2RheSA/DQoN Ckhha2ltDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJjIFBldGl0LUh1 Z3VlbmluIFttYWlsdG86cGV0aXRodWdAYWNtLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgT2N0b2Jl ciAyMCwgMjAxMSA5OjE3IEFNDQpUbzogRGVhbiBXaWxsaXM7IEhha2ltIE1laG1vb2QgKG5haW0p OyBNaWNoYWVsIFByb2N0ZXI7IEpvaG4gV2FyZDsgJ01hcnkgQmFybmVzJzsgTXV0aHUgQXJ1bCBN b3poaSBQZXJ1bWFsIChtcGVydW1hbCk7IERhcnlsIE1hbGFzOyBKb24gUGV0ZXJzb247IHZpcHJA aWV0Zi5vcmcNClN1YmplY3Q6IE5vIGNvbmZlcmVuY2UgY2FsbCB0b21vcnJvdw0KDQotLS0tLUJF R0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQpIYXNoOiBTSEExDQoNCkJlZW4gc2ljayBzaW5j ZSB5ZXN0ZXJkYXksIEkgYW0gbm90IGFibGUgdG8gd29yayBvbiB0aGUgYWdlbmRhIGFuZCBoYW5k b3V0IGZvcg0KdG9tb3Jyb3cncyBtZWV0aW5nLg0KDQpTbyB1bmxlc3Mgc29tZW9uZSB3YW50IHRv IHRha2Ugb3ZlciwgSSBwcm9wb3NlIHRvIGNhbmNlbCB0aGlzIGNhbGwsIGFuZCB0bw0KcmVzdW1l IHRoZSBub3JtYWwgY29uZmVyZW5jZSBjYWxsIG5leHQgd2Vlay4NCg0KLSAtLSANCk1hcmMgUGV0 aXQtSHVndWVuaW4NClBlcnNvbmFsIGVtYWlsOiBtYXJjQHBldGl0LWh1Z3VlbmluLm9yZw0KUHJv ZmVzc2lvbmFsIGVtYWlsOiBwZXRpdGh1Z0BhY20ub3JnDQpCbG9nOiBodHRwOi8vYmxvZy5tYXJj LnBldGl0LWh1Z3VlbmluLm9yZw0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNp b246IEdudVBHIHYxLjQuMTEgKEdOVS9MaW51eCkNCg0KaUVZRUFSRUNBQVlGQWs2Z0xVOEFDZ2tR OVJvTVp5VmE2MWNJWkFDZlRiaU1aWkZqL082RFR1ekFicVdyUmFQRw0KV3gwQW4yUEVxWnZqdk9M R284L1NLOXU3RmIzMGhiWjUNCj05TVlxDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== From michael@voip.co.uk Fri Oct 21 10:58:04 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA3421F8B57 for ; Fri, 21 Oct 2011 10:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCgXOHdErAt6 for ; Fri, 21 Oct 2011 10:58:03 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with SMTP id 3D87821F8B54 for ; Fri, 21 Oct 2011 10:58:02 -0700 (PDT) Received: from mail-qy0-f171.google.com ([209.85.216.171]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP; Fri, 21 Oct 2011 10:58:03 PDT Received: by mail-qy0-f171.google.com with SMTP id 33so976805qyk.2 for ; Fri, 21 Oct 2011 10:57:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.91.12 with SMTP id k12mr3486625qcm.25.1319219875520; Fri, 21 Oct 2011 10:57:55 -0700 (PDT) Received: by 10.229.45.8 with HTTP; Fri, 21 Oct 2011 10:57:55 -0700 (PDT) Date: Fri, 21 Oct 2011 18:57:55 +0100 Message-ID: From: Michael Procter To: vipr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [VIPR] Privacy concerns X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 17:58:04 -0000 I've just submitted a draft[0] which summarises most of the privacy concerns that have been raised in recent times, along with the suggested mitigations from the list. This is clearly not exhaustive, but I was losing track of which concerns we had addressed and which ones were still on the table. I thought a draft would be a good place to keep track of these issues for the time being. Comments, suggestions, text happily accepted. Regards, Michael [0] https://datatracker.ietf.org/doc/draft-procter-vipr-privacy-concerns/ From petithug@acm.org Sat Oct 22 10:52:28 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A70321F8672 for ; Sat, 22 Oct 2011 10:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.253 X-Spam-Level: X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk2fSFKxPPW2 for ; Sat, 22 Oct 2011 10:52:27 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 3C31721F85D1 for ; Sat, 22 Oct 2011 10:52:27 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 1C2C82043D; Sat, 22 Oct 2011 17:44:16 +0000 (UTC) Message-ID: <4EA302D5.6080904@acm.org> Date: Sat, 22 Oct 2011 10:52:21 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Michael Procter References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: vipr@ietf.org Subject: [VIPR] Mitigation: Hash the Caller ID [was Re: Privacy concerns] X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 17:52:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, On 10/21/2011 10:57 AM, Michael Procter wrote: > I've just submitted a draft[0] which summarises most of the privacy > concerns that have been raised in recent times, along with the > suggested mitigations from the list. This is clearly not exhaustive, > but I was losing track of which concerns we had addressed and which > ones were still on the table. I thought a draft would be a good place > to keep track of these issues for the time being. > > Comments, suggestions, text happily accepted. > > Regards, > > Michael > > [0] https://datatracker.ietf.org/doc/draft-procter-vipr-privacy-concerns/ in Section 1.1.1: Note that I refined and tested this proposal since I wrote the email that is the source for this section. My new proposal[1] is to use bcrypt for the Caller-ID alone, so rehashing on the PVP server side is limited to the calls made to the terminating phone number in the last 48 hours. The salt and the number of rounds is part of the hash string, so the only configuration parameter would be to have the minimal number of rounds under which a PVP server refuses a hash. The main problem is that the phone numbers that are the most interesting to attack are also the one that generates the most calls per 48 hours interval (e.g. 1-800 numbers). This means that the number of rounds must be balanced between the desire to made the hash practically unbreakable, and the time to rehash the phone numbers for the last 48 hours. Again we are in a situation where a VIPR domain registering a phone number may want that PVP clients use different algorithms depending on the phone number. So instead of having only the minimal number of rounds in the configuration file, we can have both the minimal number of rounds and the default number of rounds in the configuration, and let the VIPR domain change the default value for each registered number (down to the minimal value) inside the RELOAD registration. I used a 4 cores computer to crack a phone number hashed with 2^4 rounds, and it took 106 minutes (410 minutes of CPU) to crack it, *knowing* the area code. There is ~300 area codes in the USA, so if all area codes were tried in parallel, it would take 22 days. And it is for one phone call, and with only 2^4 rounds. With 2^10 rounds, it would take 6 years to crack this phone number with the same hardware. The bcrypt paper claims that "its inner loop relies exclusively on operations that are efficient on general-purpose CPUs, leaving little opportunity for specialized hardware to achieve dramatic improvements", so using GPU would not help much. But if we start with the smaller cost that one's would not pay for a phone number, then evaluate the CPU power this cost would buy on Amazon EC2[2], and then calculate the number of rounds that would use this CPU power, then we could assign a default minimal number of rounds in the global VIPR configuration file, and increase it as the cost of Amazon EC2 decreases. [1] http://www.ietf.org/mail-archive/web/vipr/current/msg00088.html [2] http://stacksmashing.net/2010/11/15/cracking-in-the-cloud-amazons-new-ec2-gpu-instances/ - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6jAtIACgkQ9RoMZyVa61ecYQCdEDABt/O4P6DwmwMH7+di87gF z5EAn1cPtK1wSzteaBgl/Rql7Y1iRuFq =PU8a -----END PGP SIGNATURE----- From petithug@acm.org Sun Oct 23 09:32:49 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7435D21F8ADE; Sun, 23 Oct 2011 09:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCI3YDvf2sQY; Sun, 23 Oct 2011 09:32:48 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id ACC2121F8564; Sun, 23 Oct 2011 09:32:48 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id EEB7720371; Sun, 23 Oct 2011 16:24:34 +0000 (UTC) Message-ID: <4EA4419B.1040908@acm.org> Date: Sun, 23 Oct 2011 09:32:27 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: [VIPR] Fwd: I-D Action: draft-petithuguenin-vipr-proportional-quota-00.txt X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 16:32:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As instructed by our AD[1] after the meeting in Quebec City, I moved this draft back to the VIPR WG. The main change in this version is that the quota does not apply to replicas (this change was made after discussion with the developers of the only known deployed implementation of this algorithm). The reason is that because there can be huge difference in the fraction of the overlay owned by each peer, entries are likely to be lost during replication. Because the storing peer of the replication verifies that the source of the replication is valid, this should not create the possibility to store more entries than permitted by the quota mechanism (see section 6.4.1.1 of draft-ietf-p2psip-base). Changelog: o The quota does not apply to replicas. o Draft moved to VIPR WG. o Nits. [1] http://www.ietf.org/mail-archive/web/vipr/current/msg00040.html - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-vipr-proportional-quota-00.txt Date: Sun, 23 Oct 2011 09:12:05 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proportional Quota in REsource LOcation And Discovery (RELOAD) Author(s) : Marc Petit-Huguenin Jonathan Rosenberg Cullen Jennings Filename : draft-petithuguenin-vipr-proportional-quota-00.txt Pages : 7 Date : 2011-10-23 This document defines an extension to RELOAD [I-D.ietf-p2psip-base] that limits the number of a specific kind element that can be stored by one RELOAD peer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-proportional-quota-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-vipr-proportional-quota-00.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6kQZoACgkQ9RoMZyVa61fx8QCfYzU6JROPZIA1xaZqpTXyp2Hb AdsAmgNInBLZBRIj43SDKdR9ebESHSqm =qgYL -----END PGP SIGNATURE----- From petithug@acm.org Thu Oct 27 08:20:49 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0124B21F8B53 for ; Thu, 27 Oct 2011 08:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.921 X-Spam-Level: X-Spam-Status: No, score=-99.921 tagged_above=-999 required=5 tests=[AWL=-2.121, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_SUMOF=5, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+hVfN828MnO for ; Thu, 27 Oct 2011 08:20:48 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 99D5621F8B7E for ; Thu, 27 Oct 2011 08:20:44 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 5270120878; Thu, 27 Oct 2011 15:12:14 +0000 (UTC) Message-ID: <4EA976C1.6030308@acm.org> Date: Thu, 27 Oct 2011 08:20:33 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Dean Willis , "Hakim Mehmood (naim)" , Michael Procter , John Ward , 'Mary Barnes' , "Muthu Arul Mozhi Perumal (mperumal)" , Daryl Malas , Jon Peterson X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: [VIPR] Agenda & Handout for 2011/10/28 X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:20:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A. Agenda - - Replacement ticket by client certificate (10 min) - - PVP privacy (10 min) - - PVP method entropy (10 min) - - Ticket renewal (10 min) - - Infrastructure overlays (10 min) - - VIPR troubleshooting (10 min) Note that the sum of the time allocated to each topic may exceeds the time allocated to the whole call. The topics that cannot make it to the discussion will be postponed to the next conference call if they are not subsequently decided in the mailing-list. Because the conference bridge as a limited capacity, an individual invitation to the conference will be sent shortly after this email to each member of the design team. Please send me an email if you are not on this list and want to receive an invitation. Note that the design team conference call is not a way to short-circuit the normal process, but a way to accelerate it by increasing face to face time. All decisions made must be confirmed on the mailing-list. This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). B. Handout (reading time: 10 min) B.1 Replacement ticket by client certificate The discussion did not progress since the previous call. Jon position is that there is ways to have distributed components that does not require replicating secrets, that TLS brings algorithm agility but we will still have to define a profile, and that using X.509 certificates does not add any value. My position is that an X.509 certificate with symmetrical keys is better than an adhoc cryptographic ticket. B.2. PVP Privacy Michael Procter published an Internet-Draft summarizing all the privacy issues. Two things were discussed on the mailing-list: First that restricting a domain to a particular list of methods does not prevents other domain to use less private methods. They need to be fixed or being removed. Second I proposed to hash the Caller-ID in method "a" in a way that make it difficult to retrieve, by using bcrypt. B.3. PVP Entropy The discussion at the end of the previous conference call stalled on what to do about entropy. There is 3 possibilities: 1. We do not need to manage entropy because we do not want to have the user making multiple PSTN calls before receiving a SIP route. 2. We need to manage entropy, but it is best managed completely in the PVP server. 3. We need to manage entropy, but it is best managed in both client and server by using something like a cookie. B.4. Ticket renewal Another thing that was discussed in Quebec City was the "First Call Problem", i.e. the problem that it takes up to 48 hours to verify a call and been able to use enhanced media. I think the conclusion of the discussion was that it was not too annoying for the first call, as it did not degrade the user experience. On the other hand, the cryptographic ticket granted after the first has an expiration date and so need to be renewed, and that will degrade the user experience as it would mean that for each destination, the end-user will periodically not be able to use enhanced media for the duration of a call. There was multiple proposals at the microphone to solve this problem, but I would like to detail the one I proposed. The idea is, sometimes before the expiration of the ticket, to make in parallel a PSTN call and a SIP call using the existing SIP route and ticket for the enhanced media (let's say video for the remaining of this discussion). There is already an existing I-D that can be use for this, draft-ietf-mmusic-sdp-cs. The way it could work is that the call agent, after retrieving the SIP route and ticket for a destination, will decide that it is time to re-validate the route, based for example on the frequency of calls to this number and the remaining validity of the ticket. The SIP element then adds an additional m= line to the SDP that contains a PSTN address. The offered SDP then looks something like this: v=0 o=- 2890844526 2890842807 IN IP4 10.47.16.5 s= c=IN IP4 10.47.16.5 t=0 0 m=audio 49170 RTP/AVP 0 m=audio 9 PSTN - c=PSTN - - a=setup:active a=connection:new a=cs-correlation: uuie callerid dtmf m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 The SIP element on the other side verifies the ticket then starts to process the SDP. If it does not support this feature then, as per the rules in RFC 3264, it will reject the second m= line by using port 0 in the answer SDP (In this case the end user will have to have PSTN only calls for the 48 hours after the expiration of the ticket). If the remote SIP element supports this extension then it will send back an offer like this: v=0 o=- 0 1 IN IP4 192.168.2.1 s= c=IN IP4 192.168.2.1 t=0 0 m=audio 8000 RTP/AVP 0 m=audio 9 PSTN - c=PSTN E164 +14085551234 a=setup:passive a=connection:new a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3 m=video 9000 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 The local SIP element checks that the c= line contains the right number, then establishes the audio and video media over IP, as usual, but also starts a PSTN call following the rules in draft-ietf-mmusic-sdp-cs (i.e. sending the correlation value as needed). The remote SIP element will receive the PSTN call, and correlate it with the existing SIP connection. Both parties must send audio on both the IP and the PSTN side, but the receivers can choose to play the audio coming from either the IP or PSTN connection (this is because we may want to use in the future fingerprint methods for the validation). The PSTN call is ended at the same time than the IP connection if the methods used for validation are based on the call duration (other methods may permit to end the call before), so the VCRs are processed as for an initial call. The local party marks the route as been under re-validation, so to not use the renewal method for the next 48 hours. The VIPR server will send a notification before the end of the 48 hours if there is still a PSTN route to this destination. B.5. Infrastructure overlays A new draft to discuss infrastructure overlays has been submitted to DISPATCH. "[RELOAD] is a peer to peer protocol developed by the P2PSIP Working Group. Each RELOAD instance has a unique name, which is used by the process in section 10.2 of this specification to find the configuration servers, enrollment servers and bootstrap servers needed to join the overlay. The process assumes that the RELOAD instance name is a FQDN, and uses the process in [RFC2782] (SRV RR) to find the IP address of the HTTPS server that serves the configuration document for this overlay. This process is adequate when the management of the overlay does not need to be distinguished from the owner of the FQDN used as the instance name, which is the case most of the time. But there is a special class of overlays that, by definition, requires to be unique on the Internet and for which having the possibility of create instances would defeat their very purpose. This specification calls the kind of overlays that are not domain specific, but application specific "infrastructure overlays". [VIPR] is a technology that is being standardized in the VIPR Working Group and that aims to build bridges between SIP islands by automatically provision SIP routes after the "ownership" of a PSTN phone number has been verified by an actual PSTN phone call. This technology uses an RELOAD overlay as a distributed database where mappings between phone numbers and servers responsible for the validation process are stored. The promise of VIPR to bridge these SIP islands cannot be fulfilled if there is more than one distributed database storing these mappings." B.6. VIPR troubleshooting One very important point made in draft-jennings-vipr-overview is the troubleshooting problem (section 2.4). Because the provisioning of SIP routes is automatic, there is no possibility to have a interop testing between two domains before the establishment of the fist call. This means two things: - - We will need in the future to define a SIP profile that defines exactly what SIP extensions and media are supported (I propose to call this profile SIPbeyond). I think that we have a common goal here with the RTCWEB WG, and should probably work with them on this. - - We need to provide help for debugging problems if things go wrong. For the latter, the main issue is that it is not always possible to troubleshoot a problem only by looking on the logs and traces on the sending side - some kind of cooperation is required by the receiving side. Having a way to retrieve the logs and traces automatically would be a good step in this direction, but we now have a security problem to take care of, as we certainly do not want anybody to be able to retrieve this information. Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6pdrwACgkQ9RoMZyVa61d3igCfTFT/y7CruJ6d8yh6cWr1ISHx a7QAn1UmIBobhAdgfjeJJ2XtuFx99Qgu =JReu -----END PGP SIGNATURE----- From petithug@acm.org Thu Oct 27 09:50:13 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2147221F8BA0 for ; Thu, 27 Oct 2011 09:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JULmXzrr5JBi for ; Thu, 27 Oct 2011 09:50:12 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 32BC621F8B92 for ; Thu, 27 Oct 2011 09:50:12 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 44C4820878 for ; Thu, 27 Oct 2011 16:41:44 +0000 (UTC) Message-ID: <4EA98BC1.8030401@acm.org> Date: Thu, 27 Oct 2011 09:50:09 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Mitigation: Anonymising the validation attempt X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:50:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Section 1.2.1 of draft-procter-vipr-privacy-concerns proposes to use TURN to anonymise the source of a PVP validation. This proposal is probably incomplete, but the main problem is that we still do not know what transports will be used on the RELOAD overlay used by VIPR. First here's a list of what we currently know about this overlay: - - The algorithm is RELOAD-CHORD - - The Node-ID size is 16 bytes (128 bits). - - Clients are not authorized because of the quota algorithm. - - Self-signed certificates are not authorized. - - There will be one or more root-certs. - - There will be one or more bootstrap peers (unicast or anycast - no multicast). - - Clients are not authorized because of the quota algorithm. - - Shared secret are not used. - - The overlay link protocol is TLS. - - There will be a list of kind and configuration signers. - - The urn:ietf:params:xml:ns:p2p:config-chord, urn:ietf:params:xml:ns:p2p:quota and urn:ietf:params:xml:ns:p2p:vipr extensions are mandatory. - - The Kind VIPR-REGISTRATION will be authorized. What we do not know yet: - - Do we need to authorize the CERTIFICATE-BY-NODE and CERTIFICATE-BY-USER Kinds? - - Will TURN server deployed in the overlay? - - Will ICE overlay link protocols be used? The important question for this topic is the support of ICE in the RELOAD overlay: Pros: With ICE support the RELOAD nodes, the PVP client and the PVP server can be installed behind a NAT/Firewall without having to put them on the DMZ or to open pinholes (the bootstrap servers will still need to be installed in the DMZ or on the Internet). TURN servers are required for ICE support, so they would also be available for anonymising the connections. Cons: ICE is complex to implement and debug. If we decide to exclude ICE, then the TURN servers are no longer available by default, and the idea of using them for anonymising the connections is moot. An additional consideration is that the RELOAD transports are currently limited to UDP and TCP, neither of them being really well suited to carry RELOAD or PVP messages. If we decide to exclude ICE support, I will then propose to use (D)TLS over SCTP instead (and write the I-D for this). So the initial question is: Do we need ICE or not? - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6pi78ACgkQ9RoMZyVa61cStwCfQrZuK6TCMxlshUpv11JnZMEH jP4AoJDR4LvuyRdCF/jyIQch7HwDcd+i =hoMO -----END PGP SIGNATURE----- From petithug@acm.org Mon Oct 31 06:27:49 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A0221F8C50 for ; Mon, 31 Oct 2011 06:27:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBCXdYgs2ozf for ; Mon, 31 Oct 2011 06:27:48 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6E29621F85AA for ; Mon, 31 Oct 2011 06:27:48 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id D086C2025C for ; Mon, 31 Oct 2011 13:19:04 +0000 (UTC) Message-ID: <4EAEA250.4070105@acm.org> Date: Mon, 31 Oct 2011 06:27:44 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [VIPR] Minutes for 2011/10/28 conference call delayed X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:27:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Exceptional circumstances prevented me to complete the minutes yesterday (a car hit a power pole, so no power and no access to the audio files Sunday). In a normal time I would have been able to finish this by noon, but today is also the cut-off for submitting I-Ds. I have another deadline tomorrow, so the minutes will not be published until Wednesday. Sorry for that. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6uok8ACgkQ9RoMZyVa61ea8QCeLfXAGoOLSOPINhO2KL6N7Yr9 cIwAnjTI7RIbSJ3pcLq6WMbyGXh8jiZZ =vS8x -----END PGP SIGNATURE----- From petithug@acm.org Mon Oct 31 15:20:11 2011 Return-Path: X-Original-To: vipr@ietfa.amsl.com Delivered-To: vipr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A3C1F0D0D for ; Mon, 31 Oct 2011 15:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afRk3fN1CnhE for ; Mon, 31 Oct 2011 15:20:10 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 80F761F0D01 for ; Mon, 31 Oct 2011 15:20:09 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 788892025C for ; Mon, 31 Oct 2011 22:11:24 +0000 (UTC) Message-ID: <4EAF1F15.9030102@acm.org> Date: Mon, 31 Oct 2011 15:20:05 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: "vipr@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------060802040702000801060504" Subject: [VIPR] Fwd: I-D Action: draft-petithuguenin-vipr-pvp-02.txt X-BeenThere: vipr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Verification Involving PSTN Reachability working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:20:11 -0000 This is a multi-part message in MIME format. --------------060802040702000801060504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So much efforts and so little progresses... Changelogs: draft-petithuguenin-vipr-reload-usage-03 o The E.164 number is no longer stored 3 times. o Moved the parameter under the element. o The VIPR registration now also contains the list of supported PVP methods. draft-petithuguenin-vipr-pvp-02 o The Calling number is method "a" is now hashed with the bcrypt hash. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6vHxQACgkQ9RoMZyVa61e2vwCfXkmbFTXd1qS+FX9Rs7Ole8Od cpMAoI433Lmdc9rc6R3LpBoaaxIJH9+T =pSes -----END PGP SIGNATURE----- --------------060802040702000801060504 Content-Type: message/rfc822; name="I-D Action: draft-petithuguenin-vipr-pvp-02_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="I-D Action: draft-petithuguenin-vipr-pvp-02_txt.eml" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: X-Original-To: marc@implementers.org Delivered-To: marc@implementers.org Received: by server.implementers.org (Postfix, from userid 1001) id 1282DDCC4018; Mon, 31 Oct 2011 21:22:31 +0000 (UTC) Received: from acm26-3.acm.org (acm26-3.acm.org [64.238.147.102]) by server.implementers.org (Postfix) with ESMTP id 95CDFDC4408E for ; Mon, 31 Oct 2011 21:22:30 +0000 (UTC) Received: from psmtp.com ([74.125.149.157]) by acm26-3.acm.org (ACM Email Forwarding Service) with SMTP id OFB90529; Mon, 31 Oct 2011 17:22:29 -0400 Received: from mail.ietf.org ([12.22.58.30]) by na3sys009amx176.postini.com ([74.125.148.10]) with SMTP; Mon, 31 Oct 2011 21:22:29 GMT Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2458B11E81F7; Mon, 31 Oct 2011 14:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320096129; bh=gC/rEvgCqN4Tke2MSOavk8/EZ9z6BhzL6CGBCKWMX8Y=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=plwCVNegfspwIFh24VQQfz3YNyfc6HY6tjSCruD8m1AAfCDbwqllczrpQ/amEkHsV rjGPplIFbnvL46Hmwy1/DEMCgpV0Jw5u2NI+tM/K2v4bDEe81zhzaDgJGrVqKw9yeZ SqVWsstvMro+k0sZe/YC4AHHu4p9QFjXhn76Kr3g= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FF411E81F7 for ; Mon, 31 Oct 2011 14:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7RQHgXrUmaO for ; Mon, 31 Oct 2011 14:22:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91BD11E81FA for ; Mon, 31 Oct 2011 14:22:06 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-petithuguenin-vipr-pvp-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031212206.19328.26122.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 14:22:06 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-pstn-neptune: 0/0/0.00/0 X-pstn-levels: (S:99.90000/99.90000 CV:99.9000 FC:95.5390 LC:95.5390 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Public Switched Telephone Network (PSTN) Validation Protocol (PVP) Author(s) : Marc Petit-Huguenin Jonathan Rosenberg Cullen Jennings Filename : draft-petithuguenin-vipr-pvp-02.txt Pages : 30 Date : 2011-10-31 One of the main challenges in inter-domain federation of Session Initiation Protocol (SIP) calls is that many domains continue to utilize phone numbers, and not email-style SIP URI. Consequently, a mechanism is needed that enables secure mappings from phone numbers to domains. The main technical challenge in doing this securely is to verify that the domain in question truly is the "owner" of the phone number. This specification defines the PSTN Validation Protocol (PVP), which can be used by a domain to verify this ownership by means of a forward routability check in the PSTN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------060802040702000801060504 Content-Type: message/rfc822; name="I-D Action: draft-petithuguenin-vipr-reload-usage-03_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="I-D Action: draft-petithuguenin-vipr-reload-usage-03_txt.eml" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: X-Original-To: marc@implementers.org Delivered-To: marc@implementers.org Received: by server.implementers.org (Postfix, from userid 1001) id EA2B2DCC4018; Mon, 31 Oct 2011 20:31:20 +0000 (UTC) Received: from acm26-4.acm.org (acm26-4.acm.org [64.238.147.103]) by server.implementers.org (Postfix) with ESMTP id 4F0FCDC4408E for ; Mon, 31 Oct 2011 20:31:20 +0000 (UTC) Received: from psmtp.com ([74.125.149.128]) by acm26-4.acm.org (ACM Email Forwarding Service) with SMTP id OEK01720; Mon, 31 Oct 2011 16:31:20 -0400 Received: from mail.ietf.org ([12.22.58.30]) by na3sys009amx244.postini.com ([74.125.148.10]) with SMTP; Mon, 31 Oct 2011 20:31:19 GMT Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1AF21F8DB2; Mon, 31 Oct 2011 13:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320093066; bh=pyELOvCAFkbG6IbBsnZauBFU4+Uua8nYXswCz7Wpzdk=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=rkRhWV0p1Y8qj8oz0oUnpN9QjEZBAESp5vrsq/4D9hqyX/l+FEqlHWUo50nlYFt1P F1Ng4jritP5sW150dgU6frx+yKC/6NrmJugN1fgw6RBYJM1GUYsxjOckU+AKG9mCG0 xO/puPmnKCP0FqsfQ2C+TptwBOO3MwD0sSHaf6kM= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3620721F8DB2 for ; Mon, 31 Oct 2011 13:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRCSkEzUwtaN for ; Mon, 31 Oct 2011 13:31:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9731021F8DAC for ; Mon, 31 Oct 2011 13:31:04 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-petithuguenin-vipr-reload-usage-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031203104.29325.90506.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 13:31:04 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-pstn-neptune: 0/0/0.00/0 X-pstn-levels: (S:99.90000/99.90000 CV:99.9000 FC:95.5390 LC:95.5390 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Usage of Resource Location and Discovery (RELOAD) for Public Switched Telephone Network (PSTN) Verification Author(s) : Marc Petit-Huguenin Jonathan Rosenberg Cullen Jennings Filename : draft-petithuguenin-vipr-reload-usage-03.txt Pages : 11 Date : 2011-10-31 Verification Involving PSTN Reachability (VIPR) is a technique for inter-domain SIP federation. VIPR makes use of the RELOAD protocol to store unverified mappings from phone numbers to RELOAD nodes, with whom a validation process can be run. This document defines the usage of RELOAD for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-reload-usage-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-vipr-reload-usage-03.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------060802040702000801060504--