[stir] current draft charter

"Peterson, Jon" <jon.peterson@neustar.biz> Wed, 12 June 2013 01:03 UTC

Return-Path: <jon.peterson@neustar.biz>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8470821F9B8C for <stir@ietfa.amsl.com>; Tue, 11 Jun 2013 18:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id y+nJWQT4bb5o for <stir@ietfa.amsl.com>; Tue, 11 Jun 2013 18:03:13 -0700 (PDT)
Received: from neustar.com (smartmail.neustar.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6F47D21F9B8B for <stir@ietf.org>; Tue, 11 Jun 2013 18:03:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370999474; x=1686352102; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=kuRLpaW3n5OiM2gil7na3LWi9KJm8g6JvCzLIHxAE60=; b=mjYHslJXWFd+bWlii4CaZ9hqEFTPr2wiaktQetETqo8rhAh2gQu5xCUefht8bF JPZUpMjsXFUR8Q//x/vHVWaQ==
Received: from ([]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26140688; Tue, 11 Jun 2013 21:11:13 -0400
Received: from STNTEXCHCASHT05.cis.neustar.com ( by STNTEXCHHT01.cis.neustar.com ( with Microsoft SMTP Server (TLS) id; Tue, 11 Jun 2013 21:03:01 -0400
Received: from stntexmb12.cis.neustar.com ([]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 21:03:01 -0400
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "stir@ietf.org" <stir@ietf.org>
Thread-Topic: current draft charter
Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gmw==
Date: Wed, 12 Jun 2013 01:02:59 +0000
Message-ID: <CDDD16D0.1EE9D%jon.peterson@neustar.biz>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: AbSpviMhW3q0TdZYyisypA==
Content-Type: multipart/alternative; boundary="_000_CDDD16D01EE9Djonpetersonneustarbiz_"
MIME-Version: 1.0
Subject: [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 01:03:17 -0000

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


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