Re: [stir] current draft charter
Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 12 June 2013 10:22 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F58121F9C1B for <stir@ietfa.amsl.com>; Wed, 12 Jun 2013 03:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 m1B65O94wyXi for <stir@ietfa.amsl.com>; Wed, 12 Jun 2013 03:21:53 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7FD21F9A31 for <stir@ietf.org>; Wed, 12 Jun 2013 03:21:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 182D9BEAA; Wed, 12 Jun 2013 11:21:30 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8OCY6EHmO8A; Wed, 12 Jun 2013 11:21:30 +0100 (IST)
Received: from [IPv6:2001:770:10:203:24c6:3ab1:3e3d:b83f] (unknown [IPv6:2001:770:10:203:24c6:3ab1:3e3d:b83f]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E1F59BEA4; Wed, 12 Jun 2013 11:21:29 +0100 (IST)
Message-ID: <51B84BAA.8020004@cs.tcd.ie>
Date: Wed, 12 Jun 2013 11:21:30 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
References: <CDDD28BB.1F0A5%jon.peterson@neustar.biz>
In-Reply-To: <CDDD28BB.1F0A5%jon.peterson@neustar.biz>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc: "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] current draft charter
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stir>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jun 2013 10:22:05 -0000
Hi Jon, On 06/12/2013 03:28 AM, Peterson, Jon wrote: > > > On 6/11/13 6:46 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote: > >> >> So based on many recent mails, I'd suggest adding "and threat model" >> to the problem statement deliverable and s/certificate/key management/g >> might be better so as not to preclude a non-certificate based >> solution. > > Fine with adding a threat model to the problem statement. Lovely. > > And non-certificate based key management solutions are in scope, sure. > RFC4474bis lists in its action items studying how to point at DANE from > the Identity-Info header, and this could extend to alternatives for > credentials in the DNS. Ironically, back when we wrote RFC4474, we assumed > there would be keys in public ENUM and that we'd solve the problem this > way eventually. Lack of public ENUM (and to a lesser extent, tardiness of > DNSSEC) back-burnered that plan. I'm personally less concerned about the > syntax of the credentials than the authority structures behind them. That's a fair point. However, I'd argue that the difference between a DKIM-like and RPKI-like approach is far from just syntax. For example, in an RPKI-like approach the callee has to verify who delegated what to whom in order to check the signature (e.g. via 5280 NameConstraints). With a DKIM-like approach, that's done in some un- or differently-specified way by some infrastructure (before making the public key available) and isn't directly visible to the callee. That's definitely not just syntax I reckon. >> And one near-nit: I think the term "identity" generates quite a bit >> of confusion and its generally better to talk about identifiers and >> not identities. In other cases that's more of a deal but since we're >> only dealing with phone numbers here its almost a nit. > > I hesitate to back out the term "identity" given that it's what we've used > for more than ten years for this. I'm fine with that in this case. It'll probably come up though so just as well to try get it out of the way:-) S. > The header even in RFC4474 is called > Identity. The RFC3325 header is P-Asserted-Identity. I hear what you're > saying - this signature is over an identifier - but it's pretty clear that > this identifier serves as an identity. The calling TN, or a derivative > from it, is what telephony UIs show their users when alerting for an > incoming call. Whether CNAM does it in the PSTN, or your address book does > on your smart phone, applications translate callings TNs into proper names > of various kind to represent callers. To secure calling TNs is to secure > the identity of the caller. > > Jon Peterson > Neustar, Inc. > >> >> Cheers, >> S. >> >> On 06/12/2013 02:02 AM, Peterson, Jon wrote: >>> >>> Below is the current draft of the charter, based on our prior >>> discussions. >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> ---- >>> >>> Name: Secure Telephone Identity Revisited (stir) >>> Area: RAI >>> >>> Chairs: TBD >>> Area Advisor: TBD (Barnes) >>> >>> Mailing list: (current source-auth) >>> To Subscribe: -- >>> >>> Over the last decade, a growing set of problems have resulted from the >>> lack of security mechanisms for attesting the origins of real-time >>> communications. Many of these problems are familiar from our experience >>> with email: bulk unsolicited commercial communications remain a >>> challenge for the traditional telephone network largely because the >>> source of calls can be hidden. Others are potentially more serious: >>> voicemail hacking, impersonating banks and similar attacks are becoming >>> commonplace. The technologies that obscure the caller¹s identity are >>> frequently gateways between the telephone network and the Internet. >>> >>> SIP is one of the main VoIP technologies employed by these gateways. A >>> number of previous efforts have attacked the problem of securing the >>> origins of SIP communications, including RFC3325, RFC4474 and the VIPR >>> WG. To date, however, true cryptographic authentication of the source of >>> SIP calls has not seen any appreciable deployment. While several factors >>> contributed to this lack of success, two seem like the largest culprits: >>> 1) the lack of any real means of asserting authority over telephone >>> numbers on the Internet; and 2) a misalignment of the integrity >>> mechanisms proposed by RFC4474 with the highly interworked, mediated and >>> policy-driven deployment environment that has emerged for SIP. The VIPR >>> alternative, while promising, faced apparently unavoidable privacy >>> problems and other significant deployment hurdles. >>> >>> Given the pressing difficulties caused by the lack of a useful identity >>> solution, the problem of securing the origins of SIP communication must >>> be revisited. Because SIP deployments are so closely tied to the >>> telephone network, we moreover must investigate solutions that can work >>> when one side of a call is in the PSTN or potentially even both. This >>> will require a two-pronged approach: one prong relying on information >>> carried in SIP signaling; the other prong relying on forming out-of-band >>> connections between IP endpoints that are participating in a call. >>> >>> The changes to the RFC4474 approach to SIP signaling must include a new >>> capability for Identity assertions to cover telephone numbers, rather >>> than domain names. To conform with realistic deployments, we must also >>> study ways to rebalance the requirements for the scope of RFC4474¹s >>> integrity protection to emphasize preventing third-party impersonation >>> over preventing men-in-the-middle from capturing media. >>> >>> Finally, the solution must encompass an out-of-band means for endpoints >>> to establish identity when there is no direct SIP signaling path between >>> them available, due to interworking or similar factors. This working >>> group will investigate a means for Internet endpoints to discover one >>> another in real time to verify that a telephone call between them is in >>> progress based on minimal evidence or configuration. This architecture >>> will, to the degree that is possible, reuse the credentials defined for >>> telephone numbers for the in-band signaling solution, and define a >>> discovery mechanism that provides better than hop-by-hop security. >>> >>> The working group will coordinate with the security area on certificate >>> management. >>> >>> The working group will coordinate with RAI area groups studying the >>> problem of signaling through existing deployments, including INSIPID. >>> >>> Identity is closely linked to privacy, and frequently one comes at the >>> cost of the other. This working group is not chartered to mandate the >>> presence of identity in SIP requests, and to the extent feasible it will >>> find privacy-friendly solutions that leak minimal information about >>> calls to third parties. >>> >>> The working group will deliver the following: >>> >>> - A problem statement detailing the deployment environment and >>> difficulties motivate work on secure origins >>> >>> - A revision to SIP¹s identity features to provide several fixes: >>> Changes to support certification for telephone numbers >>> Changes to the signature >>> >>> - A document describing the certificate profile required to support >>> telephone numbers in certificates >>> >>> - A fallback mechanism to allow out-of-band identity establishment >>> during call setup >>> >>> Milestones >>> >>> Sep 2013 Submit problem statement for Info >>> Nov 2013 Submit RFC4474bis for PS >>> Jan 2013 Submit TN cert profile for Info >>> Mar 2014 Submit fallback for PS >>> >>> >>> >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>> > >
- [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Stephen Farrell
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter Wilhelm Wimmreuter
- Re: [stir] current draft charter Stephen Farrell
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Wendt, Chris
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Wendt, Chris
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- [stir] Nature vs. nurture -- semantics vs. encodi… Dave Crocker
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- [stir] Not just "called party" - Re: current draf… Dan York
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] Not just "called party" - Re: current … Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] Not just "called party" - Re: current … Peterson, Jon
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Michael Hammer
- Re: [stir] Not just "called party" - Re: current … Hadriel Kaplan
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Paul Kyzivat
- Re: [stir] Not just "called party" - Re: current … Dan York
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] Not just "called party" - Re: current … Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Richard Barnes
- Re: [stir] current draft charter - ENUM and datab… Dave Crocker
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Brian Rosen
- Re: [stir] current draft charter - ENUM and datab… Wendt, Chris
- Re: [stir] current draft charter - ENUM and datab… Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter - ENUM and datab… Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Wendt, Chris
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter Wilhelm Wimmreuter