Re: [stir] WG Action: Formed Secure Telephone Identity Revisited (stir)

Richard Barnes <rlb@ipv.sx> Fri, 30 August 2013 16:41 UTC

Return-Path: <rlb@ipv.sx>
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 A464921E80EF for <stir@ietfa.amsl.com>; Fri, 30 Aug 2013 09:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 G5FTMZfcclLP for <stir@ietfa.amsl.com>; Fri, 30 Aug 2013 09:41:50 -0700 (PDT)
Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id E6A0521E80E7 for <stir@ietf.org>; Fri, 30 Aug 2013 09:41:46 -0700 (PDT)
Received: by mail-oa0-f49.google.com with SMTP id i7so2562402oag.8 for <stir@ietf.org>; Fri, 30 Aug 2013 09:41:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=wKHCwFIsa0hlTPIl3+w028Vy5atD8YJFat9tX1dTpSM=; b=RqPfZVJDU0cKCNoL9X8qYNApnuzL439YtEWmJohFmtJ6hLWhsNT9bzhoLT+auIpWa3 NFCied/3X90u7PvZFn2Fr5hsoWrJLEbjND9y7Q4Xhn+rGyAJOvGAWsrEFeOjVooGkSd9 bSouBumpZlHlDKH9AMkdDaLfAF59eEFPRKItA/7/vSto+iOtEH/61FolqiqWmyhE4mVQ TEwV1O0vgK1T+GJYAppJvpCb0/jzlgWamSFhrLL5rW4dixE6nnSL278IBGbNH5BnpYZB BiWB+6mI7nNY92U0kEwwvDMN8PQFEaih+X9ycC1JsJcL0N94g2zB+sVx3Gqpy6IL7UBk /zEw==
X-Gm-Message-State: ALoCoQn0c7P2iKCsjOMChumQGmpyKd+NzwcYDzJ5hwEvH3u4pzdBs3sjT8EedS8SvF1WZz7s/IAs
MIME-Version: 1.0
X-Received: by 10.60.135.196 with SMTP id pu4mr965926oeb.89.1377880906444; Fri, 30 Aug 2013 09:41:46 -0700 (PDT)
Received: by 10.60.31.74 with HTTP; Fri, 30 Aug 2013 09:41:46 -0700 (PDT)
X-Originating-IP: [192.1.51.95]
In-Reply-To: <20130830162243.20403.56703.idtracker@ietfa.amsl.com>
References: <20130830162243.20403.56703.idtracker@ietfa.amsl.com>
Date: Fri, 30 Aug 2013 12:41:46 -0400
Message-ID: <CAL02cgTtR000W+r-8fnVN5yfHvyAwxwS5_qs21oq8GNuss+gYQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: stir WG <stir@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b3a975cf8c2ac04e52ce5c8"
Subject: Re: [stir] WG Action: Formed Secure Telephone Identity Revisited (stir)
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: Fri, 30 Aug 2013 16:41:57 -0000

We officially have a working group!  Thanks to Russ and Robert for agreeing
to chair.

Now let's get to work!


On Fri, Aug 30, 2013 at 12:22 PM, The IESG <iesg-secretary@ietf.org> wrote:

> A new IETF working group has been formed in the Real-time Applications
> and Infrastructure Area. For additional information please contact the
> Area Directors or the WG Chairs.
>
> Secure Telephone Identity Revisited (stir)
> ------------------------------------------------
> Current Status: Proposed WG
>
> Chairs:
>   Robert Sparks <RjS@nostrum.com>
>   Russ Housley <housley@vigilsec.com>
>
> Assigned Area Director:
>   Richard Barnes <rlb@ipv.sx>
>
> Mailing list
>   Address: stir@ietf.org
>   To Subscribe: https://www.ietf.org/mailman/listinfo/stir
>   Archive: http://www.ietf.org/mail-archive/web/stir/
>
> Charter:
>
> The STIR working group will specify Internet-based mechanisms that allow
> verification of the calling party's authorization to use a particular
> telephone number for an incoming call.  Since it has  become fairly easy
> to present an incorrect source telephone number, a growing set of
> problems have emerged over the last decade.  As with email, the claimed
> source identity of a SIP request is not verified, permitting
> unauthorized use of the source identity 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).  In addition, use
> of an incorrect source telephone number facilitates wire fraud or can
> lead to a return call at premium rates.
>
> 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 authorization to use 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 priority mechanism work item, the working group will specify a
> SIP header-based mechanism for verification that 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.  This
> protection 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 that is associated
> with the one or more telephone numbers.  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 a telephone number holder to further delegate and revoke use
> of a telephone number without compromising the global delegation scheme.
>
> In addition to its priority mechanism work item, the working group will
> consider a mechanism for verification of the originator during session
> establishment in an environment with one or more non-SIP hops, most
> likely requiring 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.  The in-band mechanism must be
> sent to the IESG for approval and publication prior to the out-of-band
> mechanism.
>
> The work of this group is limited to developing a solution for telephone
> numbers. Expansion of the authorization mechanism to identities using the
>
> user@domain or other name forms is out of scope.
>
> The working group will coordinate with the Security Area on credential
> management and signature mechanics.
>
> The working group will coordinate with other working groups in the RAI
> Area regarding signaling through existing deployments.
>
> The working group welcomes input from potential implementors or
> operators of technologies developed by this working group.  For example,
> national numbering authorities might consider acting as credential
> authorities for telephone numbers within their purview.
>
> It is important to note that while the main focus of this working group
> is telephone numbers, the STIR working group will not develop any
> mechanisms that require changes to circuit-switched technologies.
>
> Authentication and authorization of identity is closely linked to
> privacy, and these security features sometimes come at the cost of
> privacy.  Anonymous calls are already defined in SIP standards, and this
> working group will not propose changes to these standards.  In order to
> support anonymity, the working group will provide a solution in which
> the called party receives an indication that the source telephone number
> is unavailable.  This working group, to the extent feasible, will
> specify privacy-friendly mechanisms that do not reveal any more
> information to user agents or third parties than a call that does not
> make use of secure telephone identification mechanisms.
>
> 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
>     [draft-cooper-iab-secure-origin-00]
>
>   - Secure Origin Identification: Problem Statement, Requirements,
>     and Roadmap
>     [draft-peterson-secure-origin-ps-00]
>
>   - Authenticated Identity Management in the Session Initiation
>     Protocol (SIP)
>     [draft-jennings-dispatch-rfc4474bis-00]
>
> The working group will deliver the following:
>
>   - A problem statement detailing the deployment environment and
>     situations that motivate work on secure telephone identity
>
>   - A threat model for the secure telephone identity mechanisms
>
>   - A privacy analysis of the secure telephone identity mechanisms
>
>   - A document describing the SIP in-band mechanism for telephone
>     number-based identities during call setup
>
>   - A document describing the credentials required to support
>     telephone number identity authentication
>
>   - A document describing the out-of-band mechanism for telephone
>     number-based identities during call setup
>
> Milestones:
>   Sep 2013 - Submit problem statement for Informational
>   Nov 2013 - Submit threat model for Informational
>   Nov 2013 - Submit in-band mechanism for Proposed Standard
>   Feb 2014 - Submit credential specification for Proposed Standard
>   Apr 2014 - Submit Privacy analysis for Informational
>   Jun 2014 - Submit out-of-band mechanism for Proposed Standard
>
>
>