Re: [stir] Draft STIR Charter

Russ Housley <housley@vigilsec.com> Tue, 16 July 2013 20:34 UTC

Return-Path: <housley@vigilsec.com>
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 D893421F9ED4 for <stir@ietfa.amsl.com>; Tue, 16 Jul 2013 13:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level:
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=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 mAa3apNXh-cO for <stir@ietfa.amsl.com>; Tue, 16 Jul 2013 13:34:05 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 58AF821F9EC2 for <stir@ietf.org>; Tue, 16 Jul 2013 13:34:02 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 6889CF240BA for <stir@ietf.org>; Tue, 16 Jul 2013 16:34:33 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id VO3uG1yZobU8 for <stir@ietf.org>; Tue, 16 Jul 2013 16:33:58 -0400 (EDT)
Received: from [192.168.2.109] (pool-96-241-212-98.washdc.fios.verizon.net [96.241.212.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 05B5AF2407E for <stir@ietf.org>; Tue, 16 Jul 2013 16:34:27 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/mixed; boundary="Apple-Mail-100-562644282"
Date: Tue, 16 Jul 2013 16:33:55 -0400
In-Reply-To: <DCFF8979-54B9-4529-93E4-5AD4CB269DA4@vigilsec.com>
To: IETF STIR Mail List <stir@ietf.org>
References: <CE046113.5AB06%jon.peterson@neustar.biz> <41CF0399-F2D6-4D5A-B241-B1C32297F4E2@neustar.biz> <51DFDB57.1040809@cs.tcd.ie> <51E01389.7090509@dcrocker.net> <30295148-F294-468C-A12A-1DD4ADEAC197@neustar.biz> <432A0CF3-A5FC-42EF-8336-7BA70B765E7D@vigilsec.com> <51E080BB.2060403@dcrocker.net> <B0EEB721-1B1C-4976-A2C7-1A406EBA6DC9@vigilsec.com> <51E094AB.4000105@dcrocker.net> <DCFF8979-54B9-4529-93E4-5AD4CB269DA4@vigilsec.com>
Message-Id: <457ED3A0-D8D1-4420-A2C3-5B07B16AE641@vigilsec.com>
X-Mailer: Apple Mail (2.1085)
Subject: Re: [stir] Draft STIR 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: Tue, 16 Jul 2013 20:34:11 -0000

I have tried to pull all of the discussion into an updated charter.  I have also attached a diff to make it easier to review.

Russ


= = = = = = = = = =


Name: Secure Telephone Identity Revisited (stir)
Area: RAI

Chairs: TBD
Area Advisor: Richard Barnes

Mailing list: stir@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/stir

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.  As with email, the claimed source identity of a SIP
request is not verified, and this permits unauthorized use of source
identities as part of deceptive and coercive activities, such as
robocalling (bulk unsolicited commercial communications), vishing
(voicemail hacking, and impersonating banks) and swatting (impersonating
callers to emergency services to stimulate unwarranted large scale law
enforcement deployments).  This working group will define a deployable
mechanism that verifies the authorization of the calling party to use
a particular telephone number.

SIP is one of the main VoIP technologies used by parties that want to
present an incorrect origin, in this context an origin telephone number.
Several previous efforts have tried to secure the origins of SIP
communications, including RFC 3325, RFC 4474, and the VIPR working group.
To date, however, true validation of the source of SIP calls has not seen
any appreciable deployment.  Several factors contributed to this lack of
success, including: failure of the problem to be seen as critical at the
time; lack of any technical means of producing a proof of authority over
telephone numbers; misalignment of the mechanisms proposed by RFC 4474
with the complex deployment environment that has emerged for SIP; lack of
end-to-end SIP session establishment; and inherent operational problems
with a transitive trust model.  To make deployment of this solution more
likely, consideration must be given to latency, real-time performance,
computational overhead, and administrative overhead for the legitimate
call source and all verifiers.

As its first work item, the working group will specify a SIP header-based
authorization mechanism to verify the originator of a SIP session is
authorized to use the claimed source telephone number, where the session
is established with SIP end to end.  This is called an in-band mechanism.
The mechanism will use a canonical telephone number representation
specified by the working group, including any mappings that might be
needed between the SIP header fields and the canonical telephone number
representation.  The working group will consider choices for protecting
identity information and credentials used, but will likely be based on a
digital signature mechanism that covers a set of information in the SIP
header fields, and verification will employ a credential that contains
the public key and is associated with the one or more telephone numbers.
In order to be authoritative, credentials used with this mechanism will
be derived from existing telephone number assignment and delegation
models.  That is, when a telephone number or range of telephone numbers
is delegated to an entity, relevant credentials will be generated (or
modified) to reflect such delegation.  The mechanism must allow parties
who are not delegated a telephone number, but are authorized by the
entity who is delegated the number, to place calls using the identity.

After completing the in-band mechanism, the working group will consider
session establishment where there are one or more non-SIP hops, most
likely using an out-of-band authorization mechanism.  However, the
in-band and the out-of-band mechanisms should share as much in common as
possible, especially the credentials.

Expansion of the authorization mechanism to identities using the
user@domain form deferred since the main focus of the working group is to
develop a solution for telephone numbers.

The working group will coordinate with the Security Area on credential
management.

The working group will coordinate with other working groups in the RAI
Area regarding signaling through existing deployments.

Authentication and authorization of identity is closely linked to
privacy, and these security features frequently come at the cost of
privacy.  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.

Input to working group discussions shall include:

  Private Extensions to the Session Initiation Protocol (SIP)
  for Asserted Identity within Trusted Networks
  RFC 3325

  Enhancements for Authenticated Identity Management in the
  Session Initiation Protocol (SIP)
  RFC 4474

  Secure Call Origin Identification
  http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00

  Secure Origin Identification: Problem Statement, Requirements,
  and Roadmap
  http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00

  Authenticated Identity Management in the Session Initiation
  Protocol (SIP)
  http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00

The working group will deliver the following:

  - A problem statement detailing the deployment environment and
    situation that motivate work on secure telephone identity

  - A mechanism document describing the SIP end-to-end with telephone
     number-based identities 

  - A document describing the credentials required to support
    telephone number identity authentication

  - A fallback mechanism to allow out-of-band identity establishment
    during call setup

Milestones

Sep 2013   Submit problem statement for Informational
Nov 2013   Submit in-band mechanism for Proposed Standard
Feb 2014   Submit credential specification for Proposed Standard
Jun 2014   Submit fallback for Proposed Standard