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

From: Russ Housley <[email-masked]>
Date: Tue, 6 Aug 2013 15:46:55 -0400

I have tried to take the comments that I have heard to dat into this draft.  Some people that were very vocal prior to the BOF have gone quiet, so I expect that some people are on holiday.

Please review and comment.

Russ

= = = = = = = = = = 

Name: Secure Telephone Identity Revisited (stir)
Area: RAI

Chairs: TBD
Area Advisor: Richard Barnes

Mailing list: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/stir

The STIR working group will specify mechanisms that greatly increase
confidence in 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 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
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.

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Aug 2013 13:17:01 -0700

On 8/6/2013 12:46 PM, Russ Housley wrote:
> 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

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

> place calls using the identity.

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

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

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

> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Aug 2013 17:07:13 -0400

Dave:

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

How about:

The STIR working group will specify mechanisms for the validation of source telephone number for an incoming call.

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

Yes.  My take of the discussion is that the group want to write a problem statement and a threat model before any mechanisms.

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

Agreed.  I'll delete it.

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

That does not match the discussion on the list.   Below are exact words to the list on the day after the BOF.  Many people said they could live with this approach.
!
! That is, the proposed WG will deliver an in-band mechanism first, and then
! deliver an out-of-band mechanism.  Notice that this does not prevent the WG
! from working on them at the same time, but ti does speak directly to the order
! that they will be sent to the IESG.

I tried to capture that in the charter text, which includes:
!
! 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.
> 
> 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.

And, many people supported this difference.

Russ

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 6 Aug 2013 17:18:49 -0400

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: [email-masked] [mailto:[email-masked]] 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

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.

So:

---

From: Brian Rosen <[email-masked]>
Date: Wed, 7 Aug 2013 08:41:33 -0400

yah, and i want to get the charter off to the IESG soon.

On Tuesday, August 6, 2013, Richard Shockey wrote:

> guarantee;
> > modifi

---

From: Eric Burger <[email-masked]>
Date: Thu, 8 Aug 2013 19:54:16 -0400

I know, we are doing the threat model first and then the mechanism. And yes, that work will be in parallel. However, is it realistic to say that by the time one has consensus on the threat model the work on in-band will be fully baked and unchanged from the threat analysis?

On the other hand, specifying November 2013 as a delivery date for in-band could be an easy $100 for me (anyone want to take that bet?).