Re: WG Review: Secure Telephone Identity Revisited (stir)

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Thu, 22 August 2013 14:53 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A0D21F8C65; Thu, 22 Aug 2013 07:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.566
X-Spam-Level:
X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 hRnuKol527+9; Thu, 22 Aug 2013 07:53:54 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC4911E814C; Thu, 22 Aug 2013 07:53:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8522; q=dns/txt; s=iport; t=1377183233; x=1378392833; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=f+RmQwZtHNuntTRrbzz1nY1goo82KHanVN/FKGv9lwA=; b=eoR3I9OM/LNm5eQQsHcvB5EO1dAkUDzOicWMWYF4DLHzTcXPh/5xVo+c /TYNbnyUvGo+J2+Emn3HZAM5tNqnESDCMH4xApEidecD3lPMip+8DWRJl mOjdNmam8Qf7v2szfU8iGteoCsa1MiT2RRLzWQjwgAkiYWsgeKAPXtpZf c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao0FANwlFlKtJXG//2dsb2JhbABOAwmDBTVRwAiBHBZtB4IkAQEBAwEBAQEaHR8VCwULAgEIIgISECcLJQIEDgMCCAESh28GDK8PjxgBBAcDBoEGAjEHgxt7A5NMQZUzgx9AgSkCBxcCBBw
X-IronPort-AV: E=Sophos;i="4.89,934,1367971200"; d="scan'208";a="250458678"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 22 Aug 2013 14:53:39 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7MErdno007150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 14:53:39 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.221]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 09:53:38 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: WG Review: Secure Telephone Identity Revisited (stir)
Thread-Topic: WG Review: Secure Telephone Identity Revisited (stir)
Thread-Index: AQHOn0diLpFeqm1CkkWDY3sxz5Amcg==
Date: Thu, 22 Aug 2013 14:53:38 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11491F2E2@xmb-aln-x02.cisco.com>
References: <20130821175202.24713.10458.idtracker@ietfa.amsl.com>
In-Reply-To: <20130821175202.24713.10458.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D4FE62ADDE630C41A76CDB4E49BF950A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: stir WG <stir@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2013 14:53:59 -0000

This looks reasonable to me and given how much effort it has taken to get agreement on theses words, I am not keen on any of the material changes I have seen proposed.


On Aug 21, 2013, at 11:52 AM, The IESG <iesg-secretary@ietf.org> wrote:

> A new IETF working group has been proposed in the Real-time Applications
> and Infrastructure Area. The IESG has not made any determination yet. The
> following draft charter was submitted, and is provided for informational
> purposes only. Please send your comments to the IESG mailing list (iesg
> at ietf.org) by 2013-08-28.
> 
> Secure Telephone Identity Revisited (stir)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Chairs:
>  TBD
> 
> 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.
> 
> Expansion of the authorization mechanism to identities using the
> user@domain form is out of scope.  The work of this group is limited to
> developing 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.
> 
> 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
>