Re: [stir] Moving from BOF to Charter

[Hadriel Kaplan <[e-mail]>]

SHIP IT.


-hadriel
p.s. I too just sent some grammatical nits to Russ directly, but don't care if they don't get done - just a Type A personality issue.


On Aug 9, 2013, at 10:29 AM, Eric Rescorla <[e-mail]> wrote:

> This looks basically good to me. Some wordsmithing below.
> 
> -Ekr
> 
> On Fri, Aug 9, 2013 at 7:00 AM, Russ Housley <[e-mail]> wrote:
> Below is the current charter text.  Is it ready for the IESG?
> 
> Russ
> 
> > Thanks.
> >
> > Is that it?  Is everyone okay with the charter language now?  Russ will post a new complete version just to make sure, but can we send this to the IESG and ask for the work group?
> >
> > Brian
> 
> = = = = = = = =
> 
> Name: Secure Telephone Identity Revisited (stir)
> Area: RAI
> 
> Chairs: TBD
> Area Advisor: Richard Barnes
> 
> Mailing list: [e-mail]
> To Subscribe: https://www.ietf.org/mailman/listinfo/stir
> 
> The STIR working group will specify mechanisms for the validation of
> 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)
> 
> this may need an e.g.,
> 
> 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 lead to
> 
> maybe "or can lead to"
>  
> a return call at premium rates.  This working group will define
> mechanisms that verify the authorization of the calling party to use a
> particular telephone number.
> 
> Do the mechanisms verify or "allow verification of..."
> 
>  
> 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 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 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 session establishment where there are one or more non-SIP hops,
> most likely using an out-of-band mechanism.
> 
> I feel like some words are missing here. Perhaps
> "providing authorization for session establishment...."
> "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 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.  A called
> party will receive an indication that the source telephone number is
> unavailable in order to provide anonymity.
> 
> Perhaps:
> "In order to support anonymity, the output of the WG will provide a mode
> in which the called party receives an indication..."
> 
> 
>  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
>     situation 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 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 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir