Re: [stir] Moving from BOF to Charter

Eric Burger <eburger@standardstrack.com> Fri, 09 August 2013 22:45 UTC

Return-Path: <eburger@standardstrack.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 80BF011E8130 for <stir@ietfa.amsl.com>; Fri, 9 Aug 2013 15:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.052
X-Spam-Level:
X-Spam-Status: No, score=-102.052 tagged_above=-999 required=5 tests=[AWL=0.547, 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 lYcBDhQRk1Hj for <stir@ietfa.amsl.com>; Fri, 9 Aug 2013 15:45:03 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id CE56821F9B25 for <stir@ietf.org>; Fri, 9 Aug 2013 15:37:42 -0700 (PDT)
Received: from ip68-100-74-194.dc.dc.cox.net ([68.100.74.194]:60233 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger@standardstrack.com>) id 1V7vJT-0008Uo-TL for stir@ietf.org; Fri, 09 Aug 2013 15:37:40 -0700
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_A91672EB-7A8B-4FDD-9404-329A459527AE"; protocol="application/pkcs7-signature"; micalg="sha1"
Message-Id: <5B9C030E-E44F-4194-9B5D-99413C6B24EA@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Date: Fri, 09 Aug 2013 18:37:45 -0400
References: <61480B59-61DC-48A1-9D82-336838C22548@vigilsec.com> <27422711-5E4B-4DE4-820A-A9FD395278FD@vigilsec.com> <CB4F45DE-7275-4A0E-AE68-D24CB028C227@vigilsec.com> <5201649F.3050701@bbn.com> <34CCEB09-BD08-485F-924F-45972785F612@vigilsec.com> <alpine.BSF.2.00.1308081219000.6303@hiroshima.bogus.com> <CAOPrzE0fZwgSWsHuOzAw25_mAxQ5XN6d+St1fyL_=4jkTdtGpw@mail.gmail.com> <3DA449D9-79DB-4A9A-827C-D7D9777FDFA9@vigilsec.com> <8D4524DD-F5BD-482C-835B-B9DB2D154B4D@georgetown.edu>
To: IETF STIR Mail List <stir@ietf.org>
In-Reply-To: <8D4524DD-F5BD-482C-835B-B9DB2D154B4D@georgetown.edu>
X-Mailer: Apple Mail (2.1508)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [stir] Moving from BOF to 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: Fri, 09 Aug 2013 22:45:08 -0000

I still think it is insane to say we will deliver the threat model and the solution in parallel, but Hadriel and I have a $2 vs $20M side bet going on :-)  10,000,000:1 odds is pretty good.

I also think it is silly to have a year of work (really three) on in band and have out of band be in the charter. Just say no and do that later or as individual work. If the individual work matures faster than in-band, they get their own group and I can have another side bet (like XCON and MEDIACTRL) that I can make book on. [Although admittedly, the XCON versus MEDIACTRL was the *ONLY* bet I have lost so far.]

Let's stop pontificating and get to work. Your AD's can beat you about the head about insane dates. The work is what is important.

On Aug 9, 2013, at 11:58 AM, Russ Housley <housley@vigilsec.com> wrote:

> I have updated the text based on the comments from EKR and Hadriel.  Is it ready for the IESG?
> 
> I am not going to bet on the Nov 2013 milestones.  It is too easy yo delay the chartering ...
> 
> 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
> 
> The STIR working group will specify mechanisms for the validation of
> the source 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.  This working group will define
> mechanisms that allow verification of 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 priority mechanism work item, the working group will specify a SIP
> header-based mechanism for verification of 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 that 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 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 are 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 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
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir