Subject: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Nov 2018 15:17:16 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-stir-passport-shaken-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5207

I would like to discuss the privacy properties of origids. As I read
this text, it does not actually require them to be unlinkable or that
it not be possible to determine whether two ids represent the same
person behind the origid generator, and I believe it should do so.
Practically implementing that may require an ID that is longer than a
UUID.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

>   
>      This document extends PASSporT, which is a token object that conveys
>      cryptographically-signed information about the participants involved
>      in communications.  The extension is defined, corresponding to the
>      SHAKEN specification, to provide both a specific set of levels-of-
>      confidence to the correctness of the originating identity for a SIP

Nit: confidence of or confidence in

>      in communications.  The extension is defined, corresponding to the
>      SHAKEN specification, to provide both a specific set of levels-of-
>      confidence to the correctness of the originating identity for a SIP
>      based Communication Service Provider (CSP) telephone network
>      originated call as well as an identifier that allows the CSP to
>      uniquely identify the origination of the call within its network.

Nit: originator

S 1.
>      need to be accounted for where PASSporT signatures may represent
>      either direct or indirect call origination scenarios.  The SHAKEN
>      [ATIS-1000074] specification defines levels of attestation of the
>      origination of the call as well as an origination identifier that can
>      help create a unique association with the origination of calls from
>      various parts of the VoIP or TDM telephone network.  This document

I can't read this. What is the association between?

S 2.
>      capitals, as shown here.
>   
>      In addition, the following terms are used in this document:
>   
>      o  Verified association: is typically defined as an authenticated
>         relationship with a device that initiated a call, for example, a

relationship between the call and the device?

S 4.
>   
>      o  Has a direct authenticated relationship with the initiator of the
>         call and can identify the customer associated with the initiator.
>   
>      o  Has NOT established a verified association with the calling party
>         telephone number being used for the call.

For those who aren't; voice experts, can you give an example of when
this would happen?

S 10.
>      integrity protection and non-repudiation properties as the base
>      claims in the PASSporT.
>   
>   10.  Privacy Considerations
>   
>      As detailed in [RFC3261] Section 26, SIP messages inherently carry

Thanks for including this section.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 18 Nov 2018 19:34:22 -0600

> https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/

Some notes I took while performing my own review of the doc...

Section 5 of the doc says:

   SHAKEN isn't prescriptive in the exact usage of origid other than the
   UUID format as a globally unique identifier representing the
   originator of the call to whatever granularity the PASSporT signer
   determines is sufficient for the ability to trace the original
   origination point of the call.

The ATIS doc only says that 'origid' "should" be a UUID, so there is some
freedom to use other formats.

They also give different guidelines for the granularity of origination,
allowing the provider to provide an anonymity shield for 'A'-level
originations but indicating very fine-grained tracing for 'B'-level
origination (e.g., for fraud detection).  For 'C'-level attestation there
isn't enough information available to make fine-grained tracking worthwhile
so a coarser identifier is okay there.  The recommended 'B'-level behavior
is probably worrisome from a user privacy perspective, as Ekr notes.

One thing that seems missing from the document is to back up the "opaque"
nature of the origid (which just means that recipients aren't expected to
look inside it) with a stronger notion that it should not have discernable
internal structure, whether by virtue of being a random value or by being a
token self-encrypted at the originating device for later decryption.  (Of
course, self-encryption brings with it requirements on key management,
which may be undesirable.)

While it's unclear that we have much room here to provide normative
guidance for origid generation, there does seem to be plenty of space for a
more in-depth discussion of the privacy landscape, what factors might go
into the decision of what granularity of origid to use, possible techniques
for generating origids that preserve various privacy properties, etc.

-Benjamin

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Nov 2018 11:00:48 -0600

> For those who aren't; voice experts, can you give an example of when

There are some uncommon but valid cases in which Voice ISPs may allow a 
calling party to specify a calling number that the Voice ISP can't 
verify as being assigned to the calling user.

Consider, for example, a service like Google Voice, which provides a 
single number that forwards to multiple destinations. I may want to be 
able to make calls from my Voice ISP (who has no association with 
Google) with my Google Voice number as the originating number. While my 
Voice ISP has authenticated me and knows who I am, it has no way to 
validate that I have control of that number; so, if it is signing a 
Shaken token with that number, it would have to mark it as Partial 
Attestation.

There are similar situations that can be employed for whole-PBX failover 
when multiple Voice ISPs are used for high-availability purposes.

We can debate whether these use cases are good to have in the world, but 
that won't change that they are currently in use; and I think it's clear 
that using Passport with them is an improvement over the status quo.

/a

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Nov 2018 09:59:58 -0800

On Mon, Nov 19, 2018 at 9:00 AM Adam Roach <[email-masked]> wrote:

> calling party to specify a calling number that the Voice ISP can't verify
> as being assigned to the calling user.
>
> single number that forwards to multiple destinations. I may want to be able
> to make calls from my Voice ISP (who has no association with Google) with
> my Google Voice number as the originating number. While my Voice ISP has
> authenticated me and knows who I am, it has no way to validate that I have
> control of that number; so, if it is signing a Shaken token with that
> number, it would have to mark it as Partial Attestation.
>
OK.

> that using Passport with them is an improvement over the status quo.

I'm not arguing against it, I'm just trying to get clarity on what these
levels mean.

-Ekr

---

From: "David Frankel" <[email-masked]>
Date: Mon, 19 Nov 2018 10:30:34 -0800

Eric,

I agree with (what I think) you are saying – it is difficult to know how a call recipient or their agent should treat Partial Attestation.

As Adam explained, this means that the originating provider “knows the customer” but can’t “vouch for the specific telephone number.”

This is problematic because what it means to “know the customer” may be quite different depending on who the provider is. To one provider, it may mean “I have a long-term established and trusted business relationship with the originating customer, and I have explicitly permitted them to use third-party numbers.” Another provider may say, “I know this customer’s IP address, and not much else, and my policy is to pass onward whatever telephone number is delivered to me.”

Perhaps that second category of provider will earn a “bad reputation” across the industry and that will result in differential treatment at the receiving end. That presumes that there will be a provider reputation database (or multiple databases) that will no doubt engender its own set of controversies.

Even without STIR, providers have always had the opportunity to be discriminating about the originating telephone numbers they allow their customers to use. In SS7/ISDN, there was the concept of “network provided” numbers (inserted by the provider and known to belong to the calling party); “customer-provided, network-screened” (number supplied by the customer, but checked against a list of known-OK numbers for that customer maintained by the provider), and “not screened” (provider basically says “I have no clue” when it comes to the validity of the calling number).

Today, there are some providers that are quite diligent about only allowing their customers to use “network-screened” numbers; they have a variety of approaches for validating those numbers (for example, by calling each number and making sure the customer answers). But obviously illegal robocallers use providers that operate in the “I have no clue” regime.

Ofcom, the UK regulator, recently published a paper describing proper provider treatment of what they call Presentation Number (our Caller-ID or FROM number), and the Network Number (what used to be our Charge Number or Billing Telephone Number or P-Charge-Info). In the Ofcom model, the Network Number is always supplied by the provider and is always a telephone number that is serviced by that provider and is known to be assigned to the originating caller.

The Ofcom Guide, which I think is excellent, can be downloaded from here:

https://www.ofcom.org.uk/phones-telecoms-and-internet/information-for-industry/telecoms-industry-guidance/calling-line-identification

What would be great in the STIR context you are discussing is if the provider, when signing the call, could insert something equivalent to the UK “network number” so that the receiving end of the call could have more certainty about the origin of the call. This would greatly limit the prevalence of “anonymous” calls flooding our network, and would reduce the necessity of a provider reputation database. There would still be mechanisms for making calls anonymously, but the recipient could then make an explicit choice to reject such calls.

David

David Frankel

ZipDX® LLC

Monte Sereno, CA USA

Tel: 1-800-FRANKEL (1-800-372-6535)

 <http://www.zipdx.info/features/> Watch Our Video!

From: stir <[email-masked]> On Behalf Of Eric Rescorla
Sent: Monday, November 19, 2018 10:00 AM
To: Adam Roach <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>; Robert Sparks <[email-masked]>; [email-masked]; IESG <[email-masked]>; [email-masked]
Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT)

On Mon, Nov 19, 2018 at 9:00 AM Adam Roach <[email-masked] <mailto:[email-masked]> > wrote:

S 4.

There are some uncommon but valid cases in which Voice ISPs may allow a calling party to specify a calling number that the Voice ISP can't verify as being assigned to the calling user.

Consider, for example, a service like Google Voice, which provides a single number that forwards to multiple destinations. I may want to be able to make calls from my Voice ISP (who has no association with Google) with my Google Voice number as the originating number. While my Voice ISP has authenticated me and knows who I am, it has no way to validate that I have control of that number; so, if it is signing a Shaken token with that number, it would have to mark it as Partial Attestation.

OK.

There are similar situations that can be employed for whole-PBX failover when multiple Voice ISPs are used for high-availability purposes.

We can debate whether these use cases are good to have in the world, but that won't change that they are currently in use; and I think it's clear that using Passport with them is an improvement over the status quo.

I'm not arguing against it, I'm just trying to get clarity on what these levels mean.

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2018 16:23:56 -0500

> Shaken token with that number, it would have to mark it as Partial 

I don't find this a sufficient justification to allow this behavior. 
Rather, in this case I think it should be necessary to involve the owner 
of the claimed number in the call path so that it can attest to the 
number. IIUC that is what Google Voice does today.

	Thanks,
	Paul

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Nov 2018 15:49:07 -0800

> number. IIUC that is what Google Voice does today.

I want to emphasize that I'm not arguing about this behavior (my DISCUSS
was about
a specific technical point). I just wanted to get an explanation. I would,
however,
encourage the authors to add an example to the spec.

-Ekr

---

From: "Rosbotham, Paul, Vodafone UK" <[email-masked]>
Date: Tue, 20 Nov 2018 08:01:28 +0000

To be clear (for the UK at least), the SS7 concept "unscreened" doesn't mean that the originating network doesn't have a clue about the validity of the CLI, it means it's not been checked on a per-call basis by the network  - we have a legal requirement to have a contractual agreement with our originating customers in this scenario that any CLIs they send into the network will be valid.  So "not screened by the network" would be better terminology.

At this stage - and we're behind SHAKEN on implementation timelines - in the UK we are planning to make use of partial attestation for the unscreened scenario.  As David says, we have a Network Number that's injected by the originating network and represents where the call came into the network (the number displayed to the called party may be the same thing in the case of residential or mobile, but for the originating enterprise case will instead be the number the enterprise customer provided).

Our current plan is that it's the Network Number that we'll sign, but whether that's full or partial will depend on whether the *display* (in our terms Presentation Number) has been statically built in the network or provided by an enterprise customer.  Practicably we have to do it that way, because we can't link the Presentation Number back to a single originating network to create a certificate hierarchy, only the Network Number...the same CLI can be used as a Presentation Number from multiple originating networks, because enterprises & call-centres typically send their calls out via multiple providers (or at least the alternative is signing by the enterprise customer, which would be complex).

At the terminating end, there is the issue of whether to trust partial attestation.  However, as the terminating network will know who signed with partial attestation, they can take a view.  Originating operator they trust, partial would get the green light.  Originating network they know has been doing inadequate due diligence and sending spam calls...draw your own conclusions.

Regards

[Vodafone]<http://vodafone.co.uk/>

Paul Rosbotham
Senior Regulatory Manager
Regulatory Policy

Vodafone HQ, The Connection, Newbury, Berkshire, RG14 2FN
Registered in England No 1471587

07957805573

[email-masked]<mailto:[email-masked]>
vodafone.co.uk<http://vodafone.co.uk/>

The future is exciting.
Ready?

C2 General
From: stir <[email-masked]> On Behalf Of David Frankel
Sent: 19 November 2018 18:31
To: 'Eric Rescorla' <[email-masked]>; 'Adam Roach' <[email-masked]>
Cc: 'IESG' <[email-masked]>; 'IETF STIR Mail List' <[email-masked]>; [email-masked]; [email-masked]; 'Robert Sparks' <[email-masked]>
Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT)

Eric,

I agree with (what I think) you are saying - it is difficult to know how a call recipient or their agent should treat Partial Attestation.

As Adam explained, this means that the originating provider "knows the customer" but can't "vouch for the specific telephone number."

This is problematic because what it means to "know the customer" may be quite different depending on who the provider is. To one provider, it may mean "I have a long-term established and trusted business relationship with the originating customer, and I have explicitly permitted them to use third-party numbers." Another provider may say, "I know this customer's IP address, and not much else, and my policy is to pass onward whatever telephone number is delivered to me."

Perhaps that second category of provider will earn a "bad reputation" across the industry and that will result in differential treatment at the receiving end. That presumes that there will be a provider reputation database (or multiple databases) that will no doubt engender its own set of controversies.

Even without STIR, providers have always had the opportunity to be discriminating about the originating telephone numbers they allow their customers to use. In SS7/ISDN, there was the concept of "network provided" numbers (inserted by the provider and known to belong to the calling party); "customer-provided, network-screened" (number supplied by the customer, but checked against a list of known-OK numbers for that customer maintained by the provider), and "not screened" (provider basically says "I have no clue" when it comes to the validity of the calling number).

Today, there are some providers that are quite diligent about only allowing their customers to use "network-screened" numbers; they have a variety of approaches for validating those numbers (for example, by calling each number and making sure the customer answers). But obviously illegal robocallers use providers that operate in the "I have no clue" regime.

What would be great in the STIR context you are discussing is if the provider, when signing the call, could insert something equivalent to the UK "network number" so that the receiving end of the call could have more certainty about the origin of the call. This would greatly limit the prevalence of "anonymous" calls flooding our network, and would reduce the necessity of a provider reputation database. There would still be mechanisms for making calls anonymously, but the recipient could then make an explicit choice to reject such calls.

David

David Frankel
ZipDX(r) LLC
Monte Sereno, CA USA
Tel: 1-800-FRANKEL (1-800-372-6535)
Watch Our Video!<http://www.zipdx.info/features/>

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Rescorla
Sent: Monday, November 19, 2018 10:00 AM
To: Adam Roach <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>; Robert Sparks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT)

On Mon, Nov 19, 2018 at 9:00 AM Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:
On 11/17/18 5:17 PM, Eric Rescorla wrote:

S 4.

this would happen?

-Ekr

---

From: Chris Wendt <[email-masked]>
Date: Tue, 20 Nov 2018 12:19:23 -0500

Hi Eric,

Answers inline.

> On Nov 17, 2018, at 6:17 PM, Eric Rescorla <[email-masked]> wrote:
> 

fixed

>>     uniquely identify the origination of the call within its network.

I believe this should be origination, because it’s not identifying the “user” or “account” it’s identifying either a network element or some network region or whatever the CSP needs to use to identify where the call came from, rather than “who” the call came from.  This is for traceback purposes and to avoid the issue of having unique identifiers that are specifically associated with users or accounts.

> I can't read this. What is the association between?

Similar to above, the concept is that a CSP maps a unique identifier to a network element or part of a CSP network that would facilitate the ability to trace the origination of the call.  It is defined to be intentionally abstract to allow for various ways CSP manage their networks and for example trunk associations to various network elements.

> relationship between the call and the device?

No, the point is that to provide this level of attestation, you need to have a “verified” authentication of the device/user into your network.  Typical example is a cell phone has SIM authentication, or a SIP digest authentication.  A scenario where you don’t have an authenticated relationship is if you are a wholesale provider or transit provider or other scenarios where you are receiving an unsigned call.

> For those who aren't; voice experts, can you give an example of when

See above answer, i can see if i can integrate that explanation in the text, if you think that covers it.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Nov 2018 11:02:50 -0800

On Tue, Nov 20, 2018 at 9:19 AM Chris Wendt <[email-masked]>
wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> I believe this should be origination, because it’s not identifying the
> “user” or “account” it’s identifying either a network element or some
> network region or whatever the CSP needs to use to identify where the call
> came from, rather than “who” the call came from.  This is for traceback
> purposes and to avoid the issue of having unique identifiers that are
> specifically associated with users or accounts.
>

I understand, but origination if a funny term here. Perhaps "origin"

> Similar to above, the concept is that a CSP maps a unique identifier to a
> network element or part of a CSP network that would facilitate the ability
> to trace the origination of the call.  It is defined to be intentionally
> abstract to allow for various ways CSP manage their networks and for
> example trunk associations to various network elements.
>

Right, but associations are between things. What are the two things.

> No, the point is that to provide this level of attestation, you need to
> have a “verified” authentication of the device/user into your network.
> Typical example is a cell phone has SIM authentication, or a SIP digest
> authentication.  A scenario where you don’t have an authenticated
> relationship is if you are a wholesale provider or transit provider or
> other scenarios where you are receiving an unsigned call.
>

Here too, relationships are between things. What are the two things.

-Ekr

---

From: Chris Wendt <[email-masked]>
Date: Mon, 26 Nov 2018 11:42:06 -0500

Hi Eric,

Responses inline.

> On Nov 20, 2018, at 2:02 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Nov 20, 2018 at 9:19 AM Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Eric,
> 
> Answers inline.
> 
> > On Nov 17, 2018, at 6:17 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ <https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/>
> > 
> > 
> > 
> > https://mozphab-ietf.devsvcdev.mozaws.net/D5207 <https://mozphab-ietf.devsvcdev.mozaws.net/D5207>
> > 
> > 
> I understand, but origination if a funny term here. Perhaps "origin” 

ok, that works, will change that in the document

> Right, but associations are between things. What are the two things. 

How about this:

The SHAKEN  [ATIS-1000074] specification defines levels of attestation of the origination of the call as well as an origination identifier that can help create a unique association between the origin of a particular call to the point in the VoIP or TDM telephone network the call came from to identify, for example, either a customer or class of service that call represents.

> Here too, relationships are between things. What are the two things.

How about this:

Verified association: is typically defined as an authenticated relationship between a customer and a device that initiated a call on behalf of that customer, for example, a

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Nov 2018 08:45:10 -0800

This works. Thanks

On Mon, Nov 26, 2018 at 8:42 AM Chris Wendt <[email-masked]>
wrote:

> The SHAKEN  [ATIS-1000074] specification defines levels of attestation of
> the origination of the call as well as an origination identifier that can
> help create a unique association between the origin of a particular call to
> the point in the VoIP or TDM telephone network the call came from to
> identify, for example, either a customer or class of service that call
> represents.
>
>
>
>> >
>> >
>> > S 2.
>> >>     capitals, as shown here.
>> >>
> Verified association: is typically defined as an
> authenticated relationship between a customer and a device that initiated a
> call on behalf of that customer, for example, a
>
>
> -Ekr
>
>
>> >
>> >
>> > S 4.
>> >>

---

From: Chris Wendt <[email-masked]>
Date: Mon, 26 Nov 2018 11:58:19 -0500

Great, @all will update with a consolidated 06 with all comments addressed once i get feedback about Ben’s comments from Adam.

> On Nov 26, 2018, at 11:45 AM, Eric Rescorla <[email-masked]> wrote:
> 
> This works. Thanks
> 
> On Mon, Nov 26, 2018 at 8:42 AM Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Eric,
> 
> Responses inline.
> 
>> On Nov 20, 2018, at 2:02 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>