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

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Aug 2013 12:07:02 -0700

The following mostly are points that I raised within the group's mailing 
list discussion, during charter development.  In my view, they have not 
yet been adequately resolved:

On 8/21/2013 10:52 AM, The IESG wrote:
>    Please send your comments to the IESG mailing list (iesg
> at ietf.org) by 2013-08-28.
...
> 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.

"use a particular telephone number for an incoming call" has no obvious 
and unambiguous technical meaning.  In fact, it seems to imply the 
meaning of "authorization to call a particular number".  However of 
course that's not the intended meaning.  Since this is the only text in 
this paragraph that says what the working group will /do/ it should make 
its statement with clarity and technical substance.

That is, the charter needs to use a precise term for specifying the 
specific role of the number of interest.  In earlier drafts, "caller id" 
was used.  The next sentence uses "source telephone number".  Perhaps 
that is acceptable.

> 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

As a matter of form, I'll note the SIP's community's use of "identity" 
is what is called "identifier" in the identity community.

...

> As its priority mechanism work item, the working group will specify a SIP

Reference to work priority is only meaningful in the face of a list of 
tasks that will be considered simultaneously and what it means to give 
priority to one over another.  Based on the lengthy mailing list 
discussion of in-band vs. out-of-band, it appears that the current 
charter is actually intended to support simultaneous work on alternative 
mechanisms, rather than pursuing them sequentially.

This should be made explicit.  If the requirement is to work on them 
sequentially, then state that.  If the intent is to work on both 
approaches simultaneously, then say that.

...

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

"in-band and the out-of-band mechanisms should share as much in common 
as possible"

This is the essential text that mandates working on both approaches 
simultaneously and makes the earliet assertion about priority moot. 
(Note how far down in the charter this is buried, yet how fundamental a 
requirement is establishes.)

...

> Input to working group discussions shall include:
>

That's a lengthy list of documents.  Why has it left out other documents 
discussed during charter development and clearly of continuing interest 
to the effort, namely:

    A proposal for Caller Identity in a DNS-based Entrusted Registry
    (CIDER)
    draft-kaplan-stir-cider-00

    An Identity Key-based and Effective Signature for Origin-Unknown
    Types
    draft-kaplan-stir-ikes-out-00

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Aug 2013 15:18:18 -0400

On Wed, Aug 21, 2013 at 3:07 PM, Dave Crocker <[email-masked]> wrote:
> list discussion, during charter development.  In my view, they have not yet
> been adequately resolved:
>
>
> "use a particular telephone number for an incoming call" has no obvious and

it'd actually be kind of nice if the focus was NOT on the (us)
10-digit "number", but instead on the 'identity' making the call.
There's a real chance to move beyond the '10-digit number' and to some
stronger, wider, richer sense of 'identity'... we should take that
opportunity and run with it.

> unambiguous technical meaning.  In fact, it seems to imply the meaning of
> "authorization to call a particular number".  However of course that's not
> the intended meaning.  Since this is the only text in this paragraph that
> says what the working group will /do/ it should make its statement with
> clarity and technical substance.
>
> That is, the charter needs to use a precise term for specifying the specific
> role of the number of interest.  In earlier drafts, "caller id" was used.

s/number/identity/

> The next sentence uses "source telephone number".  Perhaps that is
> acceptable.

no... focus on 'telephone number' is broken. Hell, it's not even
what's used in the phone system anyway... not really.

> As a matter of form, I'll note the SIP's community's use of "identity" is
> what is called "identifier" in the identity community.
>
> ...
>
> Reference to work priority is only meaningful in the face of a list of tasks
> that will be considered simultaneously and what it means to give priority to
> one over another.  Based on the lengthy mailing list discussion of in-band
> vs. out-of-band, it appears that the current charter is actually intended to
> support simultaneous work on alternative mechanisms, rather than pursuing
> them sequentially.
>
> sequentially, then state that.  If the intent is to work on both approaches
> simultaneously, then say that.
>
> ...
>
>
> "in-band and the out-of-band mechanisms should share as much in common as
> possible"
>
> simultaneously and makes the earliet assertion about priority moot. (Note
> how far down in the charter this is buried, yet how fundamental a
> discussed during charter development and clearly of continuing interest to
> the effort, namely:
>

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Aug 2013 15:25:20 -0400

+ iesg
-iesg-secretary

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Aug 2013 15:34:36 -0400

> opportunity and run with it.

To be clear, the focus is not on a 10-digit number nor numbers for any specific country-code.  It's for the global E.164 number space.

With regard to other 'identities', if you mean non-telephone-number-based SIP user@domain type names, the IETF has a PS RFC for that: RFC 4474.  Its adoption rate requires double floating-point precision to detect it not being 0%. ;)

This proposed-WG is due to real-world issues in deployments using telephone numbers, so that's been our focus scope to "fix".  As it happens, both of the proposed STIR solutions so far have in fact addressed more than just telephone numbers, including the user@domain type.  I've been told so long as we get it "for free" so-to-speak, we can address them as well in our deliverables - we just need to focus on telephone numbers since that's the problem that needs fixin'.

> what's used in the phone system anyway... not really.

Ummm... ok, what is it you think is used in the phone system really?  Or what better word/term would you use to label what's used in the phone system?

-hadriel

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Aug 2013 21:34:53 +0200

I noticed in a few places the suggestion to replace telephone number 
with 'identity'.

I think that this is a particularly bad enhancement given how widely the 
term identity is understood by most people.

In RFC 6973 we defined the term (which is inline with many of the 
identity management efforts) as:

    $ Identity:  Any subset of an individual's attributes, including
       names, that identifies the individual within a given context.
       Individuals usually have multiple identities for use in different
       contexts.

I don't think that this is what the work is about.

Let's keep the charter text concise and enhance it later once work gets 
done.

Ciao
Hannes

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 22 Aug 2013 14:53:38 +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 <[email-masked]> 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
> Secure Telephone Identity Revisited (stir)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Chairs:
>  TBD
> 
> Assigned Area Director:
>  Richard Barnes <[email-masked]>
> 
> Mailing list
>  Address: [email-masked]
>  To Subscribe: https://www.ietf.org/mailman/listinfo/stir
>  Archive: http://www.ietf.org/mail-archive/web/stir/
> 
> Charter:
> 
> telephone number for an incoming call.  Since it has  become fairly easy 
> 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.
> 
> 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.
> 
> 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.
> 
>  - 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
>