Re: [stir] Next Draft of the Charter -- 6-Aug-2013

["Richard Shockey" <[e-mail]>]

Dave nit picking .. the language is fine with me.  Increased confidence is
IMHO a goal.  We know we do not possess silver bullets. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Dave
Crocker
Sent: Tuesday, August 06, 2013 4:17 PM
To: Russ Housley
Cc: IETF STIR Mail List
Subject: Re: [stir] Next Draft of the Charter -- 6-Aug-2013

On 8/6/2013 12:46 PM, Russ Housley wrote:
>
> The STIR working group will specify mechanisms that greatly increase 
> confidence in the source telephone number for an incoming call.

Replace this first sentence.

In its current form:  1) It is purely marketing language, with a tone
approaching hype; 2) it guarantees a human outcome that we cannot guarantee;
3) there's actually some evidence that it won't affect confidence at all; 4)
it's vague.

Let's keep this an engineering exercise, rather than a human
attitudes/opinions exercise.

So:

      The STIR working group will specify mechanisms to validate the
presented source telephone number for an incoming SIP 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 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.
>
> 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

"Priority mechanism work item"?  That's rather strange phrasing.

Is there something wrong with simpler, more-direct language:

     The first work item will specify a SIP header-based...


> 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.
>
> 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.

This sentence appears to be wholly redundant with the sentence before 
it, at the end of the preceding paragraph.


> 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.  However, the in-band and the

This sounds remarkably as if there has been a basic change from doing 
in-band first, to doing in-band and out-of-band together, albeit giving 
"priority" (whatever that means) to in-band.

Please revert to the previous clear, simple, and more-typical sequencing.


> 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.

Which, of course, continues to imply a finesse of how the work is 
actually done.  For example:

      The in-band-mechanism must be sent to the IESG for approval, 
before work will begin on the out-of-band mechanism.

The project management difference in this wording is fundamental.

If there is a group insistence on doing in-band and out-of-band 
simultaneously -- which is really what this new language implies -- 
please make the consensus for this explicit.


> 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.  Anonymous calls are already defined in SIP standards, and this
> working group will not propose changes to these standards.  Of course, an
> anonymous call will not have a verifiable identity.  This working group,
> to the extent feasible, will specify privacy-friendly mechanisms that do
> not reveal any more information to third parties than a call that does
> not make use of these 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
>


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
stir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/stir