From petithug@acm.org Mon Jul 4 11:22:59 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 44BD31F0C37; Mon, 4 Jul 2011 11:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.657 X-Spam-Level: X-Spam-Status: No, score=-101.657 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb7C-lWg5NNh; Mon, 4 Jul 2011 11:22:58 -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 503371F0C34; Mon, 4 Jul 2011 11:22:51 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 7A0062199E; Mon, 4 Jul 2011 20:21:56 +0200 (CEST) Message-ID: <4E1204F5.3080808@acm.org> Date: Mon, 04 Jul 2011 11:22:45 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: [VIPR] Fwd: I-D Action: draft-petithuguenin-p2psip-proportional-quota-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: Mon, 04 Jul 2011 18:22:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This new version fixes some issues in the draft. Also a reference implementation is now available. Comments, suggestions and questions are welcome. Please follow-up in the p2psip mailing-list. Changelog: o Changed "storing peer" to "signer" as this works also for replica peers. o The default quota algorithm is per peer, not per Resource-ID. o Changed the constants in the XML extension accordingly. o Added running code considerations for reference implementation. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-p2psip-proportional-quota-01.txt Date: Mon, 04 Jul 2011 11:18:41 -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) : Jonathan Rosenberg Cullen Jennings Marc Petit-Huguenin Filename : draft-petithuguenin-p2psip-proportional-quota-01.txt Pages : 7 Date : 2011-07-04 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-p2psip-proportional-quota-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-p2psip-proportional-quota-01.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4SBPQACgkQ9RoMZyVa61dG4QCgq03U4tYWhRjlMUbQaVQetPnk D7IAn0rnNzp1nR6k7AXh7IsvZfHk1ML2 =L8VG -----END PGP SIGNATURE----- From petithug@acm.org Sun Jul 10 11:34:34 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 F0F9321F8776 for ; Sun, 10 Jul 2011 11:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJHp0pw5xunI for ; Sun, 10 Jul 2011 11:34: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 825C921F8772 for ; Sun, 10 Jul 2011 11:34:33 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id B43292199E for ; Sun, 10 Jul 2011 20:33:15 +0200 (CEST) Message-ID: <4E19F0B2.5040107@acm.org> Date: Sun, 10 Jul 2011 11:34:26 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 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-reload-usage-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: Sun, 10 Jul 2011 18:34:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Changelog: - - Made clear in the access control policy that exists is always equal to TRUE. - - Updated with new version of proportional-quota. - - The access control code now uses the configuration parameter. - - Assigned values to Application-ID and Kind-ID. - - Added running code section. - - Nits. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-vipr-reload-usage-02.txt Date: Sun, 10 Jul 2011 11:24:11 -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 : A Usage of Resource Location and Discovery (RELOAD) for Public Switched Telephone Network (PSTN) Verification Author(s) : Jonathan Rosenberg Cullen Jennings Marc Petit-Huguenin Filename : draft-petithuguenin-vipr-reload-usage-02.txt Pages : 11 Date : 2011-07-10 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-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-reload-usage-02.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4Z8LAACgkQ9RoMZyVa61fBVACghUV6xy96SqmtCChjm9AlEhEK Ch8Anj7SXgb4dtOHfyR8Mv+GwAefgDyn =I8ev -----END PGP SIGNATURE----- From fluffy@cisco.com Mon Jul 11 11:54:09 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 08B2521F8E64 for ; Mon, 11 Jul 2011 11:54:09 -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=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5diZEuwnDgm for ; Mon, 11 Jul 2011 11:54:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 12AAA21F8DB5 for ; Mon, 11 Jul 2011 11:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3535; q=dns/txt; s=iport; t=1310410448; x=1311620048; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nSadaOuSr8SRlSxn00RrOaAnuuV10OW9/HIQ/sCfR70=; b=Sj84+CZE86o+fTDkkb/BUvpCGg8xRy+JbUoLYJHjr3trp1tuV3aY5ppg yO9gs4BX6sNWyRHNT7xEciSOmvqkX0CwEmwyLBCLmLgeU5+pl9I6t5i0q /cXL8MZmGSeS1j3jec2fsLB9RdmOvlhqnYYupnUCI6BJJ4Ga/m9UDBESZ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA1GG06tJV2a/2dsb2JhbABTpxx3iHqhXp4OhVtfBIdOiwaEfotp X-IronPort-AV: E=Sophos;i="4.65,516,1304294400"; d="scan'208";a="1827685" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jul 2011 18:54:07 +0000 Received: from [10.21.75.103] ([10.21.75.103]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6BIs7sT028733; Mon, 11 Jul 2011 18:54:07 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 11 Jul 2011 11:54:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2D5E1705-DC64-42CE-AB73-5B99F44AECB0@cisco.com> References: To: Michael Procter X-Mailer: Apple Mail (2.1084) Cc: vipr@ietf.org Subject: Re: [VIPR] Review of draft-jennings-vipr-overview-01 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, 11 Jul 2011 18:54:09 -0000 Thee are excellent points. The first few were easy and fixed in next = version but on to some of the harder issues you raised ... On May 13, 2011, at 1:37 , Michael Procter wrote: >=20 > Section 8.2 > The TLS-SRP uses the caller ID and called number as a "username" >=20 > This seems to open up an interesting information leak, since the > username is sent in the clear. Let's assume EvilCorp registers its > node-id against the hash of the sales number of its competitor, > VictimCorp. Then, whenever a ViPR-enabled caller tries to call > VictimCorp to buy something, a few hours later their ViPR server will > attempt to establish a connection to EvilCorp. Even assuming that > EvilCorp can't complete the handshake because it has no idea of the = call > details, EvilCorp still ends up with a list of CLIs for people who > called their competitor's sales line. I'm not a salesperson, but I > believe that supplying a list of 'hot leads' like this would make > EvilCorp's sales team quite happy. I think we need to protect against the attack you describe. It's been = awhile since have looked at SRP. Perhaps hashing the username would = solve this? =20 >=20 >=20 > Section 9.2: 3rd attack > "the TTL for cached routes is set to match the > duration that carriers typically hold numbers." >=20 > I understand the reason for this, but I think it might lead to a poor > user experience. If someone becomes accustomed to having a videocall > / wideband audio with a regular recipient, and then finds that one day > it falls back to PSTN, I doubt that "ViPR cached route TTL expiry" = will > be the first thing that springs to mind. If you have a moderate = number > of ViPR-connected regular destinations, and a cache time of 3-6 = months, > then you will find that this happens quite often, which will lead to a > perception of unreliability for the technology. Once a fallback call > is made, it will take up to 12 hours (from my reading of the PVP = draft) > to refresh the SIP route, which essentially means it won't be 'fixed' > on the same day. It might help if there were a faster way to = revalidate > routes that have expired recently, or a way to qualify a route for > continued use whilst still protecting against this attack. total agree. I'd like to see a better way of doing validation for video = calls.=20 >=20 >=20 > Section 9.2: 5th attack >=20 > I think you may be understating the risk here. An environment that = uses > phones supporting the dialog event package, for example, will allow > mischievous colleagues to mount this attack. Even someone sitting in = the > next cubical to the caller, wielding a stop watch, probably stands a = good > chance of mounting this attack. Rather than recommending that ViPR is = not > deployed in enterprises with moderately clueful staff, is there > something that can be done to tighten up the defences to this attack? >=20 again I agree. Of course the guy in the next cube could probably just = walk over and forward the phone too. One things that can be done is not = share the validation you learn for one phone in an enterprise with other = phones in the enterprise.=20 > Best regards, >=20 > Michael > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Mon Jul 11 11:54:18 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 C082121F8E63 for ; Mon, 11 Jul 2011 11:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajVM74F9zQeP for ; Mon, 11 Jul 2011 11:54:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 41EA921F8DB5 for ; Mon, 11 Jul 2011 11:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1357; q=dns/txt; s=iport; t=1310410458; x=1311620058; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Ad92SgKg1sJFTr7GfPRRd/n9Lzkam7XuPxl7o8Qb2w4=; b=CGQac6kFsadS7g8y7qT4jeI6YXuC0ykDMMhQLy1//4kwlNYqQpH68Xov rMkWRQby7eavPw1hRLD9J/mR8Tzn3Ln9redx2qRB8M+/m8t+gO69WZt/m 66SffcjljzxZDYcvFcXwOlBYIG94VTUZZiRPMIOUuK/UgzDb8DtqzCRZ6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMtFG06tJV2a/2dsb2JhbABTpxx3iHqhXJ4OhVtfBIdOiwaEfotp X-IronPort-AV: E=Sophos;i="4.65,516,1304294400"; d="scan'208";a="1826838" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 11 Jul 2011 18:54:17 +0000 Received: from [10.21.75.103] ([10.21.75.103]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6BIs7sU028733; Mon, 11 Jul 2011 18:54:17 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 11 Jul 2011 11:54:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <024B1D39-C444-4F22-BE48-92ED3A8525F8@cisco.com> References: To: Ken Fischer X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" Subject: Re: [VIPR] draft-jennings-vipr-overview-00, Clarification Suggestion for Introduction 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, 11 Jul 2011 18:54:18 -0000 makes sense - thanks for sending text - I made this change.=20 On Apr 28, 2011, at 8:55 , Ken Fischer wrote: >=20 >=20 > In Prague I agreed to review the overview draft, and provide = comments/changes. Based on some of the discussions at the meeting, I = think we should add something to Page 5, paragraph 3. The private = federations are good, but limit innovation. I think the private = federation sentence should be re-written to something like: >=20 > Though SIP is used between domains, it is typically through = private federation agreements. While such agreements are positive, they = cause a "least common denominator" problem, which has limited the growth = of advanced SIP features,=20 > and prevented the innovation that we expected SIP to drive. >=20 >=20 > Maybe this belongs some other place in the introduction, but I think = this is about more than just any-to-any for the sake of any-to-any. Its = about the feature improvement that can flourish when non-supportive = intermediaries are removed from the path. >=20 >=20 > Ken >=20 > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From petithug@acm.org Mon Jul 11 14:15:08 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 CBAFA11E827A for ; Mon, 11 Jul 2011 14:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtPD-tz0zhQK for ; Mon, 11 Jul 2011 14:15:08 -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 0CB9B11E8278 for ; Mon, 11 Jul 2011 14:15:08 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 1E6272199E for ; Mon, 11 Jul 2011 23:13:47 +0200 (CEST) Message-ID: <4E1B67D9.2060900@acm.org> Date: Mon, 11 Jul 2011 14:15:05 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 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-antispam-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, 11 Jul 2011 21:15:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Changelog: - - Renamed Ticket to ViPR-Ticket to synchronize with -overview. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-vipr-sip-antispam-02.txt Date: Mon, 11 Jul 2011 14:13:23 -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 : Session Initiation Protocol (SIP) Extensions for Blocking VoIP Spam Using PSTN Validation Author(s) : Jonathan Rosenberg Cullen Jennings Marc Petit-Huguenin Filename : draft-petithuguenin-vipr-sip-antispam-02.txt Pages : 10 Date : 2011-07-11 Verification Involving PSTN Reachability (ViPR) is a new technique for inter-domain federation of SIP calls. ViPR makes use of the PSTN as an introduction mechanism to verify the correctness of mappings from phone numbers to domains. The PSTN introduction mechanism can also be used as a technique for blocking spam - a SIP caller is only authorized when its calling domain has previously called that same number over the PSTN. This document describes an extension to SIP which enables authorization of SIP calls based on a prior PSTN introduction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-sip-antispam-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-sip-antispam-02.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4bZ9cACgkQ9RoMZyVa61ctNACgghSDjitbCHp+xwUlnv667W6y BWoAniG5CGtDAnLmGmV6Z4+keuAJ4MZ9 =jLDq -----END PGP SIGNATURE----- From fluffy@cisco.com Thu Jul 14 17:51:53 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 9EB2521F86D6 for ; Thu, 14 Jul 2011 17:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.408 X-Spam-Level: X-Spam-Status: No, score=-104.408 tagged_above=-999 required=5 tests=[AWL=-1.809, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq76TQxHuqWZ for ; Thu, 14 Jul 2011 17:51:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EDD4321F86D2 for ; Thu, 14 Jul 2011 17:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1181; q=dns/txt; s=iport; t=1310691113; x=1311900713; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kniBV3/EpzqgESa6OqwQptGN7aequb8Kbp02KCa9HE0=; b=So1FRHmBnQuEA4Tuu7rPo/vOqjJMI4nP86FFkyymb/A2pALBOilnODDK xJBhq7eIJjpnL9fh9n6RmgChdCHE53u1/QGqkw+Yxx5ti1zvlCPT+zyVL 9pr47AfMI1U9Rqa2EO3mvCbL2UjX4JnXZqWt/EuXml8IhT3P327mb+bRf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQHANWOH06rRDoJ/2dsb2JhbABUmGWOe3eIeqVHngmFW18Eh1OLEZBx X-IronPort-AV: E=Sophos;i="4.65,532,1304294400"; d="scan'208";a="3127243" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 15 Jul 2011 00:51:51 +0000 Received: from sjc-vpn6-1818.cisco.com (sjc-vpn6-1818.cisco.com [10.21.127.26]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6F0poRr030693; Fri, 15 Jul 2011 00:51:50 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <1892288606.4720447.1304009158854.JavaMail.root@sz0129a.emeryville.ca.mail.comcast.net> Date: Thu, 14 Jul 2011 17:51:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C405FE9-0B0A-40DE-A789-552585A84066@cisco.com> References: <1892288606.4720447.1304009158854.JavaMail.root@sz0129a.emeryville.ca.mail.comcast.net> To: rob.maidhof@comcast.net X-Mailer: Apple Mail (2.1084) Cc: vipr@ietf.org Subject: Re: [VIPR] [ViPR] draft-jennings-vipr-overview-00, Clarification on Ticket verification 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, 15 Jul 2011 00:51:53 -0000 On Apr 28, 2011, at 9:45 , rob.maidhof@comcast.net wrote: > I was looking for some clarification on whether the intent is for the = Border Element or Call Agent on the terminating side of the call to = verify the ticket?=20 >=20 > For example, the last paragraph of section 8.4 page36, states that the = terminating call agent verifies the ticket, then at the end of the = paragraph it states that the call is then forwarded to the terminating = call agent. Was the intent to say the BE verifies and then forwards to = the CA? > In relation to this, section 6.3 page 27 states that a responsibility = of the BE is to perform ticket verification, while the call agent = section 6.2 does not list this as a responsibility. Page 22 states that = the CA performs ticket verification. =20 > I understand an individual network element could perform both CA and = BE functions, if it is simply a terminology issue, perhaps we could = structure the text to insure consistency. >=20 Good catches. The intention is the BE would verify the ticket. A single = device could be both the BE and CA but clearly we have text out of sync = here. I tried to update it.=20 From D.Malas@cablelabs.com Thu Jul 21 08:35: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 A257521F899D for ; Thu, 21 Jul 2011 08:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.463 X-Spam-Level: X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xiv0IdJW54N0 for ; Thu, 21 Jul 2011 08:35:10 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1189821F8906 for ; Thu, 21 Jul 2011 08:35:09 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p6LFZ8I9029293 for ; Thu, 21 Jul 2011 09:35:08 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 21 Jul 2011 09:35:08 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 21 Jul 2011 09:35:09 -0600 From: Daryl Malas To: "vipr@ietf.org" Date: Thu, 21 Jul 2011 09:35:08 -0600 Thread-Topic: [VIPR] IETF 81 Draft Agenda Posted Thread-Index: AcxHu8WqKEhT22ZaQhilkNOoNzb8Kg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA4DA34C19F93dmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [VIPR] IETF 81 Draft Agenda Posted 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, 21 Jul 2011 15:35:10 -0000 --_000_CA4DA34C19F93dmalascablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The draft agenda has been posted for the ViPR working group at the 81st IET= F meeting. We look forward to seeing you there. http://tools.ietf.org/wg/vipr/agenda?item=3Dagenda81.html In addition, you can review the notes from the last IETF ViPR meeting here: http://www.ietf.org/proceedings/80/minutes/vipr.txt Regards, Daryl --_000_CA4DA34C19F93dmalascablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,

The draft agenda has been posted for the ViPR working group at the 81= st IETF meeting.  We look forward to seeing you there.
In addition, you can review the notes from the last IETF V= iPR meeting here:


Regards,

Dar= yl
--_000_CA4DA34C19F93dmalascablelabscom_-- From michael@voip.co.uk Fri Jul 22 10:42:54 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 AEBE921F8B18 for ; Fri, 22 Jul 2011 10:42:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hhV6RHXfC4B for ; Fri, 22 Jul 2011 10:42:54 -0700 (PDT) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with SMTP id B99F821F8B0E for ; Fri, 22 Jul 2011 10:42:53 -0700 (PDT) Received: from mail-yi0-f44.google.com ([209.85.218.44]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKTim2nM/RpG8CInnt//vpeNnVZn8xfKGb@postini.com; Fri, 22 Jul 2011 10:42:53 PDT Received: by yie30 with SMTP id 30so1583084yie.31 for ; Fri, 22 Jul 2011 10:42:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.174.12 with SMTP id w12mr916974ane.50.1311356571915; Fri, 22 Jul 2011 10:42:51 -0700 (PDT) Received: by 10.100.189.8 with HTTP; Fri, 22 Jul 2011 10:42:51 -0700 (PDT) In-Reply-To: <2D5E1705-DC64-42CE-AB73-5B99F44AECB0@cisco.com> References: <2D5E1705-DC64-42CE-AB73-5B99F44AECB0@cisco.com> Date: Fri, 22 Jul 2011 18:42:51 +0100 Message-ID: From: Michael Procter To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vipr@ietf.org Subject: Re: [VIPR] Review of draft-jennings-vipr-overview-01 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, 22 Jul 2011 17:42:54 -0000 On 11 July 2011 19:54, Cullen Jennings wrote: > > Thee are excellent points. The first few were easy and fixed in next vers= ion but on to some of the harder issues you raised ... > > On May 13, 2011, at 1:37 , Michael Procter wrote: > >> Section 8.2 >> =A0The TLS-SRP uses the caller ID and called number as a "username" [Discussion of CLI leaks of callers to a specific number] > I think we need to protect against the attack you describe. It's been > awhile since have looked at SRP. Perhaps hashing the username would > solve this? I don't think hashing would be enough. I hashed the entire UK number space in a few hours using a naive piece of Python and my not-exactly-state-of-the-art computer. Then I googled and found out about using graphics cards for number crunching, which apparently can do the same job in a couple of seconds. Hashing the CLI doesn't sound like a sufficient deterrent to me. In fact, whatever technique used to obscure the CLI is probably only slightly helpful as the source IP address of the validation attempt would probably leak too much information for larger users (I accept that smaller users will probably have fairly generic reverse IP information and probably their ISP's info in whois). Going a step further, even without knowing the source IP (validation over TOR anyone?), I still think there is a worrying leak. Spotting a noticeable spike in competitor's sales line traffic following this ad campaign, but not that one, is perfectly doable once you have a statistically significant number of calls. No doubt far more information can be extracted given time and inspiration. >> Section 9.2: 3rd attack >> =A0"the TTL for cached routes is set to match the >> =A0 duration that carriers typically hold numbers." [Description of route expiry leading to poor user experience] > total agree. I'd like to see a better way of doing validation for video c= alls. Not thought of any bright ideas here, sorry! >> Section 9.2: 5th attack [Discussion of falsely claiming a number by knowing the start and end times of a call] > again I agree. Of course the guy in the next cube could probably just > walk over and forward the phone too. One things that can be done is > not share the validation you learn for one phone in an enterprise with > other phones in the enterprise. That restriction isn't enough to stop the attack if you time the victim making the call on their own phone, which wouldn't take too much social engineering. Remember that you only need to get the timings accurate to 2 seconds, which I think sounds fairly straightforward. Actually, you can handle a looser tolerance if you register multiple times. For each registration in the DHT, the original caller will attempt a validation, giving you another guess at the times, so you can use your best guesses (Tb and Te) for the first go, (Tb, Te+2) for the second, (Tb+2, Te) for the third and (Tb+2, Te+2) for the fourth. 4 registrations and you have doubled the tolerance to timing errors to 4 seconds for both call beginning and end. More registrations would allow you to relax the tolerances further. You could even defeat Hadriel's "You expect accurate call lengths?" attack like this! And once you have had a correct with the caller, you can use your new accurate times to talk to the real registered owner of the number and set up a MITM for the next few months. Best regards, Michael From petithug@acm.org Mon Jul 25 12:39:46 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 5072F21F884F for ; Mon, 25 Jul 2011 12:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1hkiLJUss8J for ; Mon, 25 Jul 2011 12:39:45 -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 8C88321F8ABD for ; Mon, 25 Jul 2011 12:39:41 -0700 (PDT) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) by implementers.org (Postfix) with ESMTPS id 1362420136; Mon, 25 Jul 2011 21:37:24 +0200 (CEST) Message-ID: <4E2DC67B.6060805@acm.org> Date: Mon, 25 Jul 2011 15:39:39 -0400 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 MIME-Version: 1.0 To: Michael Procter References: <2D5E1705-DC64-42CE-AB73-5B99F44AECB0@cisco.com> 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] Review of draft-jennings-vipr-overview-01 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, 25 Jul 2011 19:39:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2011 01:42 PM, Michael Procter wrote: > On 11 July 2011 19:54, Cullen Jennings wrote: >> >> Thee are excellent points. The first few were easy and fixed in next version but on to some of the harder issues you raised ... >> >> On May 13, 2011, at 1:37 , Michael Procter wrote: >> >>> Section 8.2 >>> The TLS-SRP uses the caller ID and called number as a "username" > [Discussion of CLI leaks of callers to a specific number] > >> I think we need to protect against the attack you describe. It's been >> awhile since have looked at SRP. Perhaps hashing the username would >> solve this? > > I don't think hashing would be enough. I hashed the entire UK number > space in a few hours using a naive piece of Python and my > not-exactly-state-of-the-art computer. Then I googled and found out > about using graphics cards for number crunching, which apparently can > do the same job in a couple of seconds. Hashing the CLI doesn't sound > like a sufficient deterrent to me. But I am not a security specialist, but here's an idea: VIPR servers on both side use bcrypt to hash the phone numbers, using a key common to everybody, and a salt that is derived from the time of the day, modulo 48 hours. Because the complexity of the bcrypt hash (and so the time it takes to generate it) can be increased as the processing power becomes available, we can define a minimum time that it will take to generate all the hashes for the E.164 space. Changing the salt each 48 hours increases the difficulty of precomputing the hashes. The key itself and bcrypt complexity can be stored in the RELOAD config file, and be changed in a safe way from time to time. > > In fact, whatever technique used to obscure the CLI is probably only > slightly helpful as the source IP address of the validation attempt > would probably leak too much information for larger users (I accept > that smaller users will probably have fairly generic reverse IP > information and probably their ISP's info in whois). It should not be too difficult to define a RELOAD Link Layer that use TURN TCP to hide the source of a PVP connection. As the PVP stream will go over TURN node susceptible to eavesdropping, we may want to be sure that there is no difference between a successful and a failed validation when looking at the encrypted stream (packet length for example). > > Going a step further, even without knowing the source IP (validation > over TOR anyone?), I still think there is a worrying leak. Spotting a > noticeable spike in competitor's sales line traffic following this ad > campaign, but not that one, is perfectly doable once you have a > statistically significant number of calls. No doubt far more > information can be extracted given time and inspiration. An additional protection could be that VIPR servers have a standard process that randomly select VIPR registrations and try to establish a PVP connection that will always fail. That should add enough noise so the real origin of a validation cannot be pinpointed. The reverse is problably also useful: VIPR servers would want to randomly register E.164 phone numbers from other providers, so the real owner of a phone number cannot be discovered by looking at the messages in transit through peers. This two techniques obviously increase the load on the VIPR servers, but as long this is specified from the beginning the cost is known so it should be fine to do so. - -- 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) iEUEARECAAYFAk4txnYACgkQ9RoMZyVa61f4ywCYrARc0E6wl/otnQx90/FTGntZ /wCfX2NJnlUD4jarmS/fvYRSlKKxxkY= =vqLY -----END PGP SIGNATURE-----