Subject: [stir] STIR 4474bis-10 comments

From: Alex Bobotek <[email-masked]>
Date: Wed, 3 Aug 2016 08:35:36 -0700

1.       Permit authorization without authentication

In the current telephony network practice, some service provider implementations choose not to authenticate identity, but simply facilitate the use of an arbitrary or selected user-provided identity.  Are there legitimate use cases for this?  Has anyone established that there are not?  How can the industry reasonably expect to end this (often bad) practice?  If it can't be ended, there's value in at least identifying the originating service provider (i.e., the signer/authorizer).  Given the prevalence of abuse using telephone numbers assigned to a sometimes-anonymous abuser, it becomes critically important to identify the service provider(s) closest to the abuser.  Based on the assumption that it's better to ID service providers than unreasonably expect a ban of the use of unauthenticated (and therefore unsigned) SIP requests, STIR signing should support authorization without authentication.  The practice of authorizing unauthenticated use exists, and there is benefit to signing in these cases (service provider identification).  The language of the ID should permit this use.  4474bis-10 should NOT require or assume that  that authentication will precede authorization. Of course there may be other use cases where signing includes authentication and may not include a specific service provider's authorization.

2.       Improve replay prevention

Proximate replay is possible while complying with this spec.  First, one or more proximate (e.g., within 60 seconds) SIP requests using the same token are legal and subject to replay in many cases.  An SDP body's mky may not be present and if present its use is optional.  Some sort of mandatory new or existing signed sequence, random # or request ID (e.g., Call-ID or CSeq) and a 1-time use policy on the receiving end of the request (e.g., tokens only good for 1 use) could prevent replay.  Different methods (e.g., INVITE vs MESSAGE) might be handled by different receiving infrastructure, and therefore difficulties with 'it's been used already' coordination allow a faked MESSAGE based on a captured request. This might include an mkey from a captured INVITE.   So it may be possible to DOS, spam or text-bomb a recipient using a captured identity.  While large-scale or distributed implementations may make the enforcement difficult, there is little cost to signing and decoding a method and possibly a numeric ID.   Some sort of '1-use' practice should at least be discussed while perhaps not required.

Specific markup suggestions:

NITS

   The verifier MUST inspect any optional "ppt" parameter appearing in the

   Identity request.  If no "ppt" parameter is present, then the

   verifier proceeds normally below.  If a "ppt" parameter value is

   present, and the verifier does not support it, it MUST ignore the

   Identity header.  If a supported "ppt" parameter value is present,

   the verifier follows the procedures below, including the variations

   described in Step 5.

3<file:///C:\Users\ab3778\Documents\IETF\draft-ietf-stir-rfc4474bis-10%20-%20Authenticated%20Identity%20Management%20in%20the%20Session%20Initiation%20Protocol%20%28SIP%29.htm#section-3>.  Background

[...]

   Per [RFC7340<https://tools.ietf.org/html/rfc7340>], problems such as robocalling, voicemail hacking, and

   swatting are enabled by an attacker's ability to impersonate someone

   else.  The secure operation of most SIP applications and services

   depends on authenticating and/or authorizing the source of communications as it is

   represented in a SIP request.

   This identity architecture for SIP depends on includes provisions for a logical

   "authentication service" which validates caller identity at or near origination.  outgoing requests.  An

   authentication service may be implemented either as part of a user

   agent or as a proxy server; typically, it is a component of a network

   intermediary like a proxy to which originating user agents send

   unsigned requests.  Once the sender of the message has been

   This document specifies a means of sharing a cryptographic assurance

   of authenticity of and/or authorization to use end-user SIP identity in an interdomain or intradomain context.

   It relies on the authentication service constructing tokens based on [...]

   To maximize end-to-end security, it is typically obviously

   preferable for end-users to acquire their own credentials; if they

   do, their user agents can act as authentication services.  However,

   for some deployments, [...]

Regards,

Alex

Alex Bobotek

---

From: Brian Rosen <[email-masked]>
Date: Thu, 4 Aug 2016 10:01:49 -0400

There are reasonable circumstances where a party placing a call is not the authorized entity assigned the telephone number used in From/PAI, and in such circumstances the service provider servicing the entity placing the call may or may not be the same as the service provider serving the entity that is assigned the TN.  In all such cases, the entity that is assigned the TN explicitly authorizes calls placed using it’s TN.  The design accommodates such use cases.  It’s not a blanket authorization without authentication.   We’re not aware of any cases where there is an actual requirement for legitimate calling without explicit authorization from the assigned entity, although we certainly are aware that various parts of various service providers don’t bother to check. At this point, at least in some countries, there is a realization that the laxity of allowing unchecked spoofing is not acceptable any more.

Brian

> On Aug 3, 2016, at 8:35 AM, Alex Bobotek <[email-masked]> wrote:
> 
> In the current telephony network practice, some service provider implementations choose not to authenticate identity, but simply facilitate the use of an arbitrary or selected user-provided identity.  Are there legitimate use cases for this?  Has anyone established that there are not?  How can the industry reasonably expect to end this (often bad) practice?  If it can’t be ended, there’s value in at least identifying the originating service provider (i.e., the signer/authorizer).  Given the prevalence of abuse using telephone numbers assigned to a sometimes-anonymous abuser, it becomes critically important to identify the service provider(s) closest to the abuser.  Based on the assumption that it’s better to ID service providers than unreasonably expect a ban of the use of unauthenticated (and therefore unsigned) SIP requests, STIR signing should support authorization without authentication.  The practice of authorizing unauthenticated use exists, and there is benefit to signing in these cases (service provider identification).  The language of the ID should permit this use.  4474bis-10 should NOT require or assume that  that authentication will precede authorization. Of course there may be other use cases where signing includes authentication and may not include a specific service provider’s authorization.
>  
>  
> Proximate replay is possible while complying with this spec.  First, one or more proximate (e.g., within 60 seconds) SIP requests using the same token are legal and subject to replay in many cases.  An SDP body’s mky may not be present and if present its use is optional.  Some sort of mandatory new or existing signed sequence, random # or request ID (e.g., Call-ID or CSeq) and a 1-time use policy on the receiving end of the request (e.g., tokens only good for 1 use) could prevent replay.  Different methods (e.g., INVITE vs MESSAGE) might be handled by different receiving infrastructure, and therefore difficulties with ‘it’s been used already’ coordination allow a faked MESSAGE based on a captured request. This might include an mkey from a captured INVITE.   So it may be possible to DOS, spam or text-bomb a recipient using a captured identity.  While large-scale or distributed implementations may make the enforcement difficult, there is little cost to signing and decoding a method and possibly a numeric ID.   Some sort of ‘1-use’ practice should at least be discussed while perhaps not required.  
>  
>  
>  <>3 <file:///C:/Users/ab3778/Documents/IETF/draft-ietf-stir-rfc4474bis-10%20-%20Authenticated%20Identity%20Management%20in%20the%20Session%20Initiation%20Protocol%20%28SIP%29.htm#section-3>.  Background
> 
> […]
>  
>    Per [RFC7340 <https://tools.ietf.org/html/rfc7340>], problems such as robocalling, voicemail hacking, and
>    It relies on the authentication service constructing tokens based on […] 
>  
>  
>  
>    for some deployments, […]
>  
>  
> Regards,
>  
> Alex 
>  
> Alex Bobotek
>  
>  
> _______________________________________________
> stir mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 4 Aug 2016 16:41:13 +0000

Fraud from compromised PBXes is common.  And even where a PBX is not compromised, a carrier has no practical way of knowing whether the calling number is properly assigned and valid from the perspective of the Enterprise.  Therefore, checking whether the calling number was from an assigned range might be possible (and fraught with administrative challenges), but of limited value.  And in the consumer market, there are calling products which support a parent subscriber number and “companion” devices (e.g., tablets) which can place a call using the MDN of the parent subscriber.  These are examples of where the authenticity of the calling number won’t necessarily mean the same thing as the authenticity of a call from a single subscriber with a single MDN regardless of “laxity” of spoof checking.

In another forum and anticipating calling number authentication mandates from Congress and/or FCC, I suggested using carrier-specific certs and encoding specificity of authenticity, and calling number.  This provides the identity of the originating carrier, some idea as to the accuracy or specificity of the calling number, and validty of the calling number (assuming nonce and replay issues can be addressed as reasonably suggested below by Alex).

The representation of orig-carrier and trustworthiness could be as follows:

Regulated/mandated Carrier Class Use Case:

00 - No Credentials

Use case example(s): Pre-IMS, legacy circuit-switched networks that don't natively support SIP or which don't choose to sign calls.  E.g., international carriers.

Trust Estimate:  Good luck.  Carrier_orig and CgPN entirely untrustworthy.

01 - Carrier signed, no authentication of CgPN

Use case example(s): E911 on visited network w/o roaming agreement, manual roaming.

Trust Estimate:  Carrier_orig trustworthy, CgPN entirely untrustworthy

10 - Carrier signed, semi-authenticated CgPN

Use case example(s): Number block delegated from OCN, but no per-TN screen (SIP trunks).

Trust Estimate:  Carrier_orig trustworthy, CgPN less than most trustworthy but not entirely untrustworthy.

11 - Carrier signed, authenticated CgPN

Use case example(s): Bread-and-butter 95%+ of calls from subscriber lines (IMS-based and otherwise).

Trust Estimate:  Carrier_orig trustworthy, CgPN most trustworthy

Public Use Case:

Undefined but assumed to use public or commercially available authentication services resources.  e.g., nomorobo-like crowd-sourced accept/deny lists, et cetera.  Could/would pass credentials down to SIP-aware devices which would process them according to the rules of the Public Class application(s).

Pierce

From: Brian Rosen [mailto:[email-masked]]
Sent: August 04, 2016 9:02 AM
To: Alex Bobotek <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] STIR 4474bis-10 comments

Brian

On Aug 3, 2016, at 8:35 AM, Alex Bobotek <[email-masked]<mailto:[email-masked]>> wrote:

NITS

   described in Step 5.

[…]

Regards,

Alex

Alex Bobotek

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

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 4 Aug 2016 13:24:06 -0400

First of all, we would want the PBX to generate the signature, but the service provider can do that.  It should not add a valid signature to a call from a number it did not assign to the trunk group connecting to the PBX, although it could support the extra delegation required to support “authorized spoofing”.  The companion devices I’m aware of always send calls from the same service provider and should not present any issue. 

Everyone will have to do work they don’t do now to implement stop spoofed calls. TANSTAAFL

Brian

> On Aug 4, 2016, at 12:41 PM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
> 
> On Aug 3, 2016, at 8:35 AM, Alex Bobotek <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 4 Aug 2016 18:22:33 +0000

You want IP PBXes to sign calls?  Won’t that make it extraordinarily easy to commit fraud with authenticated numbers?

From: Brian Rosen [mailto:[email-masked]]
Sent: August 04, 2016 12:24 PM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Alex Bobotek <[email-masked]>; [email-masked]
Subject: Re: [stir] STIR 4474bis-10 comments

Brian

On Aug 4, 2016, at 12:41 PM, Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>> wrote:

00 - No Credentials

Public Use Case:

Pierce

From: Brian Rosen [mailto:[email-masked]]
Sent: August 04, 2016 9:02 AM
To: Alex Bobotek <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] STIR 4474bis-10 comments

Brian

NITS

   described in Step 5.

[…]

Regards,

Alex

Alex Bobotek

---

From: Brian Rosen <[email-masked]>
Date: Thu, 4 Aug 2016 14:34:18 -0400

Of course I want PBXs to sign calls.  As well as smart phones and any other devices that can be programmed to do so.
They will be given credentials that only are valid for the TNs they are authorized to sign for.  They can try to sign any call, but the validity of the credential would make such a signature fail the checking.

Getting service providers to sign on behalf of devices is a reasonable way to deploy quickly, but I expect many SPs will want to get out of the liability of signing on behalf of their customers.  If they can push of that responsibility to their customer, only being responsible for getting the customer an appropriate credential when they assign TNs, then I would expect them to want to do so.  That means the devices have to be able to sign, but I understand many of the PBX vendors think that’s something they could provide in a future release.

Brian

> On Aug 4, 2016, at 2:22 PM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
> 
> On Aug 4, 2016, at 12:41 PM, Gorman, Pierce A [CTO] <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: Brian Rosen [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Alex Bobotek <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 4 Aug 2016 18:52:30 +0000

Thanks Brian.  I’m afraid we’re straying into a policy discussion.  Regardless, I do appreciate your explanation.  I would like to continue the discussion, but I’m pretty sure this isn’t the right forum.

Pierce

Sent: August 04, 2016 1:34 PM

Brian

On Aug 4, 2016, at 2:22 PM, Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>> wrote:

From: Brian Rosen [mailto:[email-masked]]
Sent: August 04, 2016 12:24 PM
To: Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>>
Cc: Alex Bobotek <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] STIR 4474bis-10 comments

Brian

00 - No Credentials

Public Use Case:

Pierce

Brian

NITS

   described in Step 5.

[…]

Regards,

Alex

Alex Bobotek

---

From: Brian Rosen <[email-masked]>
Date: Thu, 4 Aug 2016 15:02:35 -0400

Well, the mechanisms are designed so that they could be deployed on devices and PBXs.  Whether they will be is a policy issue.

The notion of credentials that are traceable to a delegation of a TN is a mechanism that is part of the design of stir, and the design allows delegation of one TN (to one device, although a device like a PBX would have more than one TN per “device”, and something like a dual NAM phone could have more than one credential.  For the use case we’ve discussed, a mobile phone may also have a credential for, say, a TN that is delegated to a landline, to cover the example case of a doctor placing a call on his mobile, but getting his office number to show up as the calling party.  Use of such mechanisms is policy.

Brian

> On Aug 4, 2016, at 2:52 PM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
> 
> On Aug 4, 2016, at 2:22 PM, Gorman, Pierce A [CTO] <[email-masked] <mailto:[email-masked]>> wrote:
>  
> To: Gorman, Pierce A [CTO] <[email-masked] <mailto:[email-masked]>>
> Cc: Alex Bobotek <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 4 Aug 2016 20:53:37 +0000

OK, you talked me into indulging in one more message on policy and use cases.

I agree that the STIR/PASSporT mechanisms could be deployed on individual devices as well as multi-device and multi-number platforms.

Number delegation (and sub-delegation), and business relationships are two additional factors which affect trustworthiness of a given calling number authentication.

Inherent variable trustworthiness of a calling number was my reason for suggesting a way to qualify the signature to reflect that variability.

Originating carriers are in a position to know if a call is coming from a device assigned a single number, or from “trunk group” which could originate calls using multiple numbers, and can qualify to some degree the trustworthiness of number authenticity accordingly.

My suggestion was qualifying calling number authenticity into categories of carrier-signed (or not), and unauthenticated, semi-authenticated, and most-authenticated.  There can be more granularity, but it implies additional operational complexity (both for the carriers and the consumers) and I assume diminishes value.

My reason for adding the authenticity of the originating carrier is typical trustworthiness of a carrier business relationship with typical consumers adds to the trustworthiness assessment and partially because carriers are a regulated point of forensic inquiry for CALEA and fraud.  Additionally, most calls originate and terminate between mobile consumers where their carriers are able to usefully authenticate their device and have a high degree of confidence of the authenticity of the calling number.

I think billions of per-TN certs of varying usability (revoked, not revoked) for authenticating calling number will not work well.

Conversely, I think billions of per-TN certs will work well, if the calling party has to sign a call with a per-TN cert provided by the called party.  No called party cert to include?  Then the calling party does not have a trusted relationship with the called party, and the call can be authorized/treated accordingly.  (I’ve made similar, mostly ignored comments in MODERN.)

Pierce

Sent: August 04, 2016 2:03 PM

Brian

On Aug 4, 2016, at 2:52 PM, Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>> wrote:

Pierce

Brian

Brian

00 - No Credentials

Public Use Case:

Pierce

Brian

NITS

   described in Step 5.

[…]

Regards,

Alex

Alex Bobotek

---

From: Brian Rosen <[email-masked]>
Date: Thu, 4 Aug 2016 17:14:27 -0400

I think all we need is to have credentials follow the delegation path, plus the option to add another level (not delegation) for authorized spoofers.

I don’t think it matters who the delegator or delegatee are as long as the delegator is willing to take the heat for delegating to someone who sends a lot of bad calls.  They can pass the buck (“I delegated the TN to him, and now I’m not responsible”), but only if the SP knows who they delegated to, so authorities can follow the delegation path.  There are plenty of certificated carriers who are willing to not care who they delegate to.  The fact that there are some who do doesn’t change much.  Making stir work means knowing who you are delegating to, so that you can pass the hot potato.

It’s perfectly reasonable for a carrier to be able to sign for any calls placed on its network on any number it has been delegated.  If it does, it’s asserting that the calls are from who they are supposed to be from.  That should be straightforward, but we know it’s not always, and that represents the hard part of deployment in my opinion.  But once they delegate, they can hand responsibility to sign to the delegatee.  But, that only works if they know who they are delegating to.

The root of the whole model is that there is a formal or informal delegation path for telephone numbers in every country, and we can build a chain of trust from that delegation path.  If you propose to alter that model, then we get into (policy) issues of which carriers/entities we trust and which we don’t.  Our model is that you know who you delegate to, and once you do that delegation, it’s their problem.  That’s pretty appealing I think, even if it’s a change in some business practices.

The mechanism is chaining credentials in a form of a PKI and having a way to know which TNs are covered by a credential.  That’s what we have, and I’m loath to change it.

Brian

> On Aug 4, 2016, at 4:53 PM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
> 
> On Aug 4, 2016, at 2:52 PM, Gorman, Pierce A [CTO] <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 4 Aug 2016 17:37:16 -0400

+1, but with one question below:

On 8/4/16 5:14 PM, Brian Rosen wrote:
> I think all we need is to have credentials follow the delegation path,

> plus the option to add another level (not delegation) for authorized
> spoofers.

I don't understand "authorized spoofers" in this context, as contrasted 
to "spoofers" who have been delegated their authority.

	Thanks,
	Paul

> I don’t think it matters who the delegator or delegatee are as long as
> the delegator is willing to take the heat for delegating to someone who
> sends a lot of bad calls.  They can pass the buck (“I delegated the TN
> to him, and now I’m not responsible”), but only if the SP knows who they
> delegated to, so authorities can follow the delegation path.  There are
> plenty of certificated carriers who are willing to not care who they
> delegate to.  The fact that there are some who do doesn’t change much.
>  Making stir work means knowing who you are delegating to, so that you
> can pass the hot potato.
>
> It’s perfectly reasonable for a carrier to be able to sign for any calls
> placed on its network on any number it has been delegated.  If it does,
> it’s asserting that the calls are from who they are supposed to be from.
>  That should be straightforward, but we know it’s not always, and that
> represents the hard part of deployment in my opinion.  But once they
> delegate, they can hand responsibility to sign to the delegatee.  But,
> that only works if they know who they are delegating to.
>
> The root of the whole model is that there is a formal or informal
> delegation path for telephone numbers in every country, and we can build
> a chain of trust from that delegation path.  If you propose to alter
> that model, then we get into (policy) issues of which carriers/entities
> we trust and which we don’t.  Our model is that you know who you
> delegate to, and once you do that delegation, it’s their problem.
>  That’s pretty appealing I think, even if it’s a change in some business
> practices.
>
> The mechanism is chaining credentials in a form of a PKI and having a
> way to know which TNs are covered by a credential.  That’s what we have,
> and I’m loath to change it.
>
> Brian
>
>
>> On Aug 4, 2016, at 4:53 PM, Gorman, Pierce A [CTO]
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> I agree that the STIR/PASSporT mechanisms could be deployed on
>> individual devices as well as multi-device and multi-number platforms.
>>
>> Number delegation (and sub-delegation), and business relationships are
>> two additional factors which affect trustworthiness of a given calling
>> number authentication.
>>
>> Inherent variable trustworthiness of a calling number was my reason
>> for suggesting a way to qualify the signature to reflect that variability.
>>
>> Originating carriers are in a position to know if a call is coming
>> from a device assigned a single number, or from “trunk group” which
>> could originate calls using multiple numbers, and can qualify to some
>> degree the trustworthiness of number authenticity accordingly.
>>
>> My suggestion was qualifying calling number authenticity into
>> categories of carrier-signed (or not), and unauthenticated,
>> semi-authenticated, and most-authenticated.  There can be more
>> granularity, but it implies additional operational complexity (both
>> for the carriers and the consumers) and I assume diminishes value.
>>
>> My reason for adding the authenticity of the originating carrier is
>> typical trustworthiness of a carrier business relationship with
>> typical consumers adds to the trustworthiness assessment and partially
>> because carriers are a regulated point of forensic inquiry for CALEA
>> and fraud.  Additionally, most calls originate and terminate between
>> mobile consumers where their carriers are able to usefully
>> authenticate their device and have a high degree of confidence of the
>> authenticity of the calling number.
>>
>> I think billions of per-TN certs of varying usability (revoked, not
>> revoked) for authenticating calling number will not work well.
>>
>> Conversely, I think billions of per-TN certs will work well, if the
>> calling party has to sign a call with a per-TN cert provided by the
>> called party.  No called party cert to include?  Then the calling
>> party does not have a trusted relationship with the called party, and
>> the call can be authorized/treated accordingly.  (I’ve made similar,
>> mostly ignored comments in MODERN.)
>>
>> Pierce
>>
>> *From:* Brian Rosen [mailto:[email-masked]]
>> *Sent:* August 04, 2016 2:03 PM
>> *To:* Gorman, Pierce A [CTO] <[email-masked]
>> <mailto:[email-masked]>>
>> *Cc:* Alex Bobotek <[email-masked] <mailto:[email-masked]>>;
>> *Subject:* Re: [stir] STIR 4474bis-10 comments
>>
>> Well, the mechanisms are designed so that they could be deployed on
>> devices and PBXs.  Whether they will be is a policy issue.
>>
>> The notion of credentials that are traceable to a delegation of a TN
>> is a mechanism that is part of the design of stir, and the design
>> allows delegation of one TN (to one device, although a device like a
>> PBX would have more than one TN per “device”, and something like a
>> dual NAM phone could have more than one credential.  For the use case
>> we’ve discussed, a mobile phone may also have a credential for, say, a
>> TN that is delegated to a landline, to cover the example case of a
>> doctor placing a call on his mobile, but getting his office number to
>> show up as the calling party.  Use of such mechanisms is policy.
>>
>> Brian
>>
>>
>>     On Aug 4, 2016, at 2:52 PM, Gorman, Pierce A [CTO]
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Thanks Brian.  I’m afraid we’re straying into a policy
>>     discussion.  Regardless, I do appreciate your explanation.  I
>>     would like to continue the discussion, but I’m pretty sure this
>>     isn’t the right forum.
>>
>>     Pierce
>>
>>     *From:* Brian Rosen [mailto:[email-masked]]
>>     *Sent:* August 04, 2016 1:34 PM
>>     *To:* Gorman, Pierce A [CTO] <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Cc:* Alex Bobotek <[email-masked]
>>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>     *Subject:* Re: [stir] STIR 4474bis-10 comments
>>
>>     Of course I want PBXs to sign calls.  As well as smart phones and
>>     any other devices that can be programmed to do so.
>>     They will be given credentials that only are valid for the TNs
>>     they are authorized to sign for.  They can try to sign any call,
>>     but the validity of the credential would make such a signature
>>     fail the checking.
>>
>>     Getting service providers to sign on behalf of devices is a
>>     reasonable way to deploy quickly, but I expect many SPs will want
>>     to get out of the liability of signing on behalf of their
>>     customers.  If they can push of that responsibility to their
>>     customer, only being responsible for getting the customer an
>>     appropriate credential when they assign TNs, then I would expect
>>     them to want to do so.  That means the devices have to be able to
>>     sign, but I understand many of the PBX vendors think that’s
>>     something they could provide in a future release.
>>
>>     Brian
>>
>>
>>         On Aug 4, 2016, at 2:22 PM, Gorman, Pierce A [CTO]
>>         <[email-masked] <mailto:[email-masked]>>
>>         wrote:
>>
>>         You want IP PBXes to sign calls?  Won’t that make it
>>         extraordinarily easy to commit fraud with authenticated numbers?
>>
>>
>>         *From:* Brian Rosen [mailto:[email-masked]]
>>         *Sent:* August 04, 2016 12:24 PM
>>         *To:* Gorman, Pierce A [CTO] <[email-masked]
>>         <mailto:[email-masked]>>
>>         *Cc:* Alex Bobotek <[email-masked]
>>         <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>         *Subject:* Re: [stir] STIR 4474bis-10 comments
>>
>>         First of all, we would want the PBX to generate the signature,
>>         but the service provider can do that.  It should not add a
>>         valid signature to a call from a number it did not assign to
>>         the trunk group connecting to the PBX, although it could
>>         support the extra delegation required to support “authorized
>>         spoofing”.  The companion devices I’m aware of always send
>>         calls from the same service provider and should not present
>>         any issue.
>>
>>             On Aug 4, 2016, at 12:41 PM, Gorman, Pierce A [CTO]
>>             <[email-masked]
>>             <mailto:[email-masked]>> wrote:
>>
>>             Fraud from compromised PBXes is common.  And even where a
>>             PBX is not compromised, a carrier has no practical way of
>>             knowing whether the calling number is properly assigned
>>             and valid from the perspective of the Enterprise.
>>             Therefore, checking whether the calling number was from an
>>             assigned range might be possible (and fraught with
>>             administrative challenges), but of limited value.  And in
>>             the consumer market, there are calling products which
>>             support a parent subscriber number and “companion” devices
>>             (e.g., tablets) which can place a call using the MDN of
>>             the parent subscriber.  These are examples of where the
>>             authenticity of the calling number won’t necessarily mean
>>             the same thing as the authenticity of a call from a single
>>             subscriber with a single MDN regardless of “laxity” of
>>             spoof checking.
>>
>>             In another forum and anticipating calling number
>>             authentication mandates from Congress and/or FCC, I
>>             suggested using carrier-specific certs and encoding
>>             specificity of authenticity, and calling number.  This
>>             provides the identity of the originating carrier, some
>>             idea as to the accuracy or specificity of the calling
>>             number, and validty of the calling number (assuming nonce
>>             and replay issues can be addressed as reasonably suggested
>>             below by Alex).
>>
>>             *Regulated/mandated Carrier Class Use Case:*
>>
>>             *00 - No Credentials*
>>             Use case example(s): Pre-IMS, legacy circuit-switched
>>             networks that don't natively support SIP or which don't
>>             choose to sign calls.  E.g., international carriers.
>>             *01 - Carrier signed, no authentication of CgPN*
>>             *10 - Carrier signed, semi-authenticated CgPN*
>>             Trust Estimate:  Carrier_orig trustworthy, CgPN less than
>>             most trustworthy but not entirely untrustworthy.
>>
>>             *11 - Carrier signed, authenticated CgPN*
>>             Use case example(s): Bread-and-butter 95%+ of calls from
>>             subscriber lines (IMS-based and otherwise).
>>             *Public Use Case:*
>>             Undefined but assumed to use public or commercially
>>             available authentication services resources.  e.g.,
>>             nomorobo-like crowd-sourced accept/deny lists, et cetera.
>>             Could/would pass credentials down to SIP-aware devices
>>             which would process them according to the rules of the
>>             Public Class application(s).
>>
>>             Pierce
>>
>>             *From:* Brian Rosen [mailto:[email-masked]]
>>             *Sent:* August 04, 2016 9:02 AM
>>             *To:* Alex Bobotek <[email-masked]
>>             <mailto:[email-masked]>>
>>             *Cc:* [email-masked] <mailto:[email-masked]>
>>             *Subject:* Re: [stir] STIR 4474bis-10 comments
>>
>>             There are reasonable circumstances where a party placing a
>>             call is not the authorized entity assigned the telephone
>>             number used in From/PAI, and in such circumstances the
>>             service provider servicing the entity placing the call may
>>             or may not be the same as the service provider serving the
>>             entity that is assigned the TN.  In all such cases, the
>>             entity that is assigned the TN explicitly authorizes calls
>>             placed using it’s TN.  The design accommodates such use
>>             cases.  It’s not a blanket authorization without
>>             authentication.   We’re not aware of any cases where there
>>             is an actual requirement for legitimate calling without
>>             explicit authorization from the assigned entity, although
>>             we certainly are aware that various parts of various
>>             service providers don’t bother to check. At this point, at
>>             least in some countries, there is a realization that the
>>             laxity of allowing unchecked spoofing is not acceptable
>>             any more.
>>
>>             Brian
>>
>>
>>                 On Aug 3, 2016, at 8:35 AM, Alex Bobotek
>>                 <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                 In the current telephony network practice, some
>>                 service provider implementations choose not to
>>                 authenticate identity, but simply facilitate the use
>>                 of an arbitrary or selected user-provided identity.
>>                 Are there legitimate use cases for this?  Has anyone
>>                 established that there are not?  How can the industry
>>                 reasonably expect to end this (often bad) practice?
>>                 If it can’t be ended, there’s value in at least
>>                 identifying the originating service provider
>>                 (i.e., the signer/authorizer).  Given the prevalence
>>                 of abuse using telephone numbers assigned to a
>>                 sometimes-anonymous abuser, it becomes critically
>>                 important to identify the service provider(s) closest
>>                 to the abuser.  Based on the assumption that it’s
>>                 better to ID service providers than unreasonably
>>                 expect a ban of the use of unauthenticated (and
>>                 therefore unsigned) SIP requests, STIR signing should
>>                 support authorization without authentication.  The
>>                 practice of authorizing unauthenticated use exists,
>>                 and there is benefit to signing in these cases
>>                 (service provider identification).  The language of
>>                 the ID should permit this use.  4474bis-10 should NOT
>>                 require or assume that  that authentication will
>>                 precede authorization. Of course there may be other
>>                 use cases where signing includes authentication and
>>                 may not include a specific service provider’s
>>                 authorization.
>>
>>
>>                 Proximate replay is possible while complying with this
>>                 spec.  First, one or more proximate (e.g., within 60
>>                 seconds) SIP requests using the same token are legal
>>                 and subject to replay in many cases.  An SDP body’s
>>                 mky may not be present and if present its use is
>>                 optional.  Some sort of mandatory new or existing
>>                 signed sequence, random # or request ID (e.g., Call-ID
>>                 or CSeq) and a 1-time use policy on the receiving end
>>                 of the request (e.g., tokens only good for 1
>>                 use) could prevent replay.  Different methods (e.g.,
>>                 INVITE vs MESSAGE) might be handled by different
>>                 receiving infrastructure, and therefore difficulties
>>                 with ‘it’s been used already’ coordination allow a
>>                 faked MESSAGE based on a captured request. This might
>>                 include an mkey from a captured INVITE.   So it may be
>>                 possible to DOS, spam or text-bomb a recipient using a
>>                 captured identity.  While large-scale or distributed
>>                 implementations may make the enforcement difficult,
>>                 there is little cost to signing and decoding a method
>>                 and possibly a numeric ID.   Some sort of ‘1-use’
>>                 practice should at least be discussed while perhaps
>>                 not required.
>>
>>
>>                    The verifier MUST inspect any optional "ppt" parameter appearing *in*the
>>
>>                     3
>>                     <file:///C:/Users/ab3778/Documents/IETF/draft-ietf-stir-rfc4474bis-10%20-%20Authenticated%20Identity%20Management%20in%20the%20Session%20Initiation%20Protocol%20%28SIP%29.htm#section-3>.
>>                     Background
>>
>>                 […]
>>
>>
>>
>>                 * *
>>                 *Alex Bobotek*
>>             ------------------------------------------------------------------------
>>
>>             This e-mail may contain Sprint proprietary information
>>             intended for the sole use of the recipient(s). Any use by
>>             others is prohibited. If you are not the intended
>>             recipient, please contact the sender and delete all copies
>>             of the message.
>
>
>
> [email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Thu, 4 Aug 2016 17:43:15 -0400

In my jargon an “authorized spoofer” is the doctor who is calling from his mobile, but sending the TN of his office phone as calling party.  The delegation to his office phone was made by his landline carrier to him.  He then creates another credential, which he signs with his office phone credential that authorizes his mobile to send calls from his office number.  He is spoofing (because the call is coming from his mobile’s TN but claims to be from his office), but it’s authorized spoofing.  The doc could give the credential to his mobile SP if they sign on his behalf.

Some folks don’t like attaching the “spoofing” label to a legitimate use.

But that’s how I describe it.

Brian

> On Aug 4, 2016, at 5:37 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> I don't understand "authorized spoofers" in this context, as contrasted to "spoofers" who have been delegated their authority.
> 
> 	Thanks,
> 	Paul
> 
>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>> *From:* Brian Rosen [mailto:[email-masked] <mailto:[email-masked]>]
>>> *To:* Gorman, Pierce A [CTO] <[email-masked] <mailto:[email-masked]>
>>> <mailto:[email-masked] <mailto:[email-masked]>>>
>>> *Cc:* Alex Bobotek <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>;
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>    <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>>    *From:* Brian Rosen [mailto:[email-masked] <mailto:[email-masked]>]
>>>    *To:* Gorman, Pierce A [CTO] <[email-masked] <mailto:[email-masked]>
>>>    <mailto:[email-masked] <mailto:[email-masked]>>>
>>>    *Cc:* Alex Bobotek <[email-masked] <mailto:[email-masked]>
>>>    <mailto:[email-masked] <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>        <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>>        wrote:
>>> 
>>>        *From:* Brian Rosen [mailto:[email-masked] <mailto:[email-masked]>]
>>>        *To:* Gorman, Pierce A [CTO] <[email-masked] <mailto:[email-masked]>
>>>        <mailto:[email-masked] <mailto:[email-masked]>>>
>>>        *Cc:* Alex Bobotek <[email-masked] <mailto:[email-masked]>
>>>        <mailto:[email-masked] <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>            <[email-masked] <mailto:[email-masked]>
>>>            <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>>            *From:* Brian Rosen [mailto:[email-masked] <mailto:[email-masked]>]
>>>            *To:* Alex Bobotek <[email-masked] <mailto:[email-masked]>
>>>            <mailto:[email-masked] <mailto:[email-masked]>>>
>>>            *Cc:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>                <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>>                    <file:///C:/Users/ab3778/Documents/IETF/draft-ietf-stir-rfc4474bis-10%20-%20Authenticated%20Identity%20Management%20in%20the%20Session%20Initiation%20Protocol%20%28SIP%29.htm#section-3 <file:///C:/Users/ab3778/Documents/IETF/draft-ietf-stir-rfc4474bis-10%20-%20Authenticated%20Identity%20Management%20in%20the%20Session%20Initiation%20Protocol%20%28SIP%29.htm#section-3>>.
>>>                    Background
>>> 
>>>                […]
>>> 
>>> 
>>> 
>>>                   Per [RFC7340 <https://tools.ietf.org/html/rfc7340 <https://tools.ietf.org/html/rfc7340>>], problems such as robocalling, voicemail hacking, and
>>> 
>>>                [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 4 Aug 2016 17:51:10 -0400

On 8/4/16 5:43 PM, Brian Rosen wrote:
> In my jargon an “authorized spoofer” is the doctor who is calling from
> his mobile, but sending the TN of his office phone as calling party.
>  The delegation to his office phone was made by his landline carrier to
> him.  He then creates another credential, which he signs with his office
> phone credential that authorizes his mobile to send calls from his
> office number.  He is spoofing (because the call is coming from his
> mobile’s TN but claims to be from his office), but it’s authorized
> spoofing.  The doc could give the credential to his mobile SP if they
> sign on his behalf.

I don't understand how that is different from regular delegation.

When his landline carrier gave him a delegated certificate for his 
landline number, he should be able to install that in whatever devices 
he wants - his landline UA, his mobile phone, etc. It is still delegated 
from his landline carrier, even when used with calls via his mobile carrier.

	Thanks,
	Paul

>> On Aug 4, 2016, at 5:37 PM, Paul Kyzivat <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> I don't understand "authorized spoofers" in this context, as
>> contrasted to "spoofers" who have been delegated their authority.
>>
>> Thanks,
>> Paul
>>
>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>> wrote:
>>>>
>>>> <mailto:[email-masked]>
>>>> <mailto:[email-masked]> <mailto:[email-masked]>>;
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>> wrote:
>>>>
>>>> <mailto:[email-masked]>
>>>>    <mailto:[email-masked]>>; [email-masked]
>>>> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>        wrote:
>>>>
>>>> <mailto:[email-masked]>
>>>>        <mailto:[email-masked]>>; [email-masked]
>>>> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> <mailto:[email-masked]>
>>>>            *Cc:* [email-masked]
>>>> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>                <[email-masked]
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>
>>>>                   Per [RFC7340
>>>> <https://tools.ietf.org/html/rfc7340>], problems such as
>>>> robocalling, voicemail hacking, and
>>>>
>>>>                   "authentication service" which validates caller
>>>> identity at or near origination.  outgoing
>>>>                requests.  An
>>>>
>>>>                   of authenticity of and/or authorization to use
>>>> end-user SIP identity in an interdomain or intradomain context.
>>>>
>>>> <mailto:[email-masked]> <mailto:[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 4 Aug 2016 18:02:36 -0400

I think it’s not a delegation.  The mobile phone is not being delegated the TN, it’s being authorized to place calls that are not from that TN, but appear to be.

The mechanism to handle the credential is exactly the same as a delegation, so if you want to call it delegation, go ahead, but I prefer to call it authorized spoofing.

Brian

> On Aug 4, 2016, at 5:51 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> When his landline carrier gave him a delegated certificate for his landline number, he should be able to install that in whatever devices he wants - his landline UA, his mobile phone, etc. It is still delegated from his landline carrier, even when used with calls via his mobile carrier.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 4 Aug 2016 18:11:48 -0400

> The mechanism to handle the credential is exactly the same as a delegation, so if you want to call it delegation, go ahead, but I prefer to call it authorized spoofing.

IIUC the delegation is to a responsible entity (something that can be 
held legally accountable - e.g. a person), not to a device. The entity 
can then "use" the credential via any device(s) it chooses. In the case 
of the mobile, the device then becomes a two-line phone.

	Thanks,
	Paul

---

From: "Rosbotham, Paul, Vodafone UK" <[email-masked]>
Date: Fri, 5 Aug 2016 07:46:25 +0000

Jumping in now that we're on European working time, +1 on Paul's observation.

Here in the UK, we've got 2 numbers carried as calling line IDs....one (we term the Network Number, carried in PAID) uniquely identifies the line, the other (we term Presentation Number, carried in From) is used for display purposes.

Only the carrier has the authority to set the Network Number so only they could sign it.  

But - subject to regulatory restrictions which are well documented - the number sent for display purposes belongs to the customer.  For blue-chip customers, I can allow them to send their Presentation Numbers into the network, and can't readily check at a network level that they're theirs (I do have contractual safeguards).  The number may have been allocated by me, or could be allocated by a third party provider.  If it's a call-centre they'll be making outbound calls for lots of different customers which will change on day-by-day basis.  This is business as usual.  I don't like the term "authorised spoofing" because it implies that the CLI is in some way being rigged: it's not, it's the corporate customer or their subcontractor using the number that's been assigned (so in internet terms delegated) to them via a chain of trust from the regulator.

What I want is the ability for customers to use their credentials to sign the CLIs they send me so that at the terminating end it can be checked (or indeed somewhere en-route if that's the business model).  I can and would sign for customers on my mobile business since I'm driving what number is presented, but that's by-the-by because they aren't the ones who generate millions of nuisance calls.  If the signing only occurs at the originating carrier level for corporate/call-centre customers that's no use because I'm not in a position to do that for these type of customers...and the whole system becomes a waste of time. I'd also highlight there are many more of my large customers that I'd trust more than a far end originating carrier that could be anywhere in the world (though we have no shortage of small carriers that I wouldn't know from Adam more locally in the UK....)

Regards

Paul

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 04 August 2016 23:12
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [stir] STIR 4474bis-10 comments

On 8/4/16 6:02 PM, Brian Rosen wrote:
> I think it's not a delegation.  The mobile phone is not being delegated the TN, it's being authorized to place calls that are not from that TN, but appear to be.
>

IIUC the delegation is to a responsible entity (something that can be held legally accountable - e.g. a person), not to a device. The entity can then "use" the credential via any device(s) it chooses. In the case of the mobile, the device then becomes a two-line phone.

	Thanks,
	Paul

>>> In my jargon an "authorized spoofer" is the doctor who is calling 
>>> from his mobile, but sending the TN of his office phone as calling party.
>>> The delegation to his office phone was made by his landline carrier 
>>> to him.  He then creates another credential, which he signs with his 
>>> office phone credential that authorizes his mobile to send calls 
>>> from his office number.  He is spoofing (because the call is coming 
>>> from his mobile's TN but claims to be from his office), but it's 
>>> authorized spoofing.  The doc could give the credential to his 
>>> mobile SP if they sign on his behalf.
>>
>>> Some folks don't like attaching the "spoofing" label to a legitimate use.
>>>
>>> But that's how I describe it.
>>>
>>> Brian
>>>
>>>>> plus the option to add another level (not delegation) for 
>>>>> authorized spoofers.
>>>>
>>>>> I don't think it matters who the delegator or delegatee are as 
>>>>> long as the delegator is willing to take the heat for delegating 
>>>>> to someone who sends a lot of bad calls.  They can pass the buck 
>>>>> ("I delegated the TN to him, and now I'm not responsible"), but 
>>>>> only if the SP knows who they delegated to, so authorities can 
>>>>> follow the delegation path.  There are plenty of certificated 
>>>>> carriers who are willing to not care who they delegate to.  The fact that there are some who do doesn't change much.
>>>>> Making stir work means knowing who you are delegating to, so that 
>>>>> you can pass the hot potato.
>>>>>
>>>>> It's perfectly reasonable for a carrier to be able to sign for any 
>>>>> calls placed on its network on any number it has been delegated.  
>>>>> If it does, it's asserting that the calls are from who they are supposed to be from.
>>>>> That should be straightforward, but we know it's not always, and 
>>>>> that represents the hard part of deployment in my opinion.  But 
>>>>> once they delegate, they can hand responsibility to sign to the 
>>>>> delegatee.  But, that only works if they know who they are delegating to.
>>>>>
>>>>> delegation path for telephone numbers in every country, and we can 
>>>>> build a chain of trust from that delegation path.  If you propose 
>>>>> to alter that model, then we get into (policy) issues of which 
>>>>> carriers/entities we trust and which we don't.  Our model is that 
>>>>> you know who you delegate to, and once you do that delegation, it's their problem.
>>>>> That's pretty appealing I think, even if it's a change in some 
>>>>> business practices.
>>>>>
>>>>> The mechanism is chaining credentials in a form of a PKI and 
>>>>> having a way to know which TNs are covered by a credential.  
>>>>> That's what we have, and I'm loath to change it.
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>>> Number delegation (and sub-delegation), and business 
>>>>>> relationships are two additional factors which affect 
>>>>>> trustworthiness of a given calling number authentication.
>>>>>>
>>>>>> Inherent variable trustworthiness of a calling number was my 
>>>>>> reason for suggesting a way to qualify the signature to reflect 
>>>>>> that variability.
>>>>>>
>>>>>> Originating carriers are in a position to know if a call is 
>>>>>> coming from a device assigned a single number, or from "trunk 
>>>>>> group" which could originate calls using multiple numbers, and 
>>>>>> can qualify to some degree the trustworthiness of number authenticity accordingly.
>>>>>>
>>>>>> granularity, but it implies additional operational complexity 
>>>>>> (both for the carriers and the consumers) and I assume diminishes value.
>>>>>>
>>>>>> My reason for adding the authenticity of the originating carrier 
>>>>>> is typical trustworthiness of a carrier business relationship 
>>>>>> with typical consumers adds to the trustworthiness assessment and 
>>>>>> partially because carriers are a regulated point of forensic 
>>>>>> inquiry for CALEA and fraud.  Additionally, most calls originate 
>>>>>> and terminate between mobile consumers where their carriers are 
>>>>>> able to usefully authenticate their device and have a high degree 
>>>>>> of confidence of the authenticity of the calling number.
>>>>>>
>>>>>> Conversely, I think billions of per-TN certs will work well, if 
>>>>>> the calling party has to sign a call with a per-TN cert provided 
>>>>>> by the called party.  No called party cert to include?  Then the 
>>>>>> calling party does not have a trusted relationship with the 
>>>>>> called party, and the call can be authorized/treated accordingly.  
>>>>>> (I've made similar, mostly ignored comments in MODERN.)
>>>>>>
>>>>>> Pierce
>>>>>>
>>>>>> <mailto:[email-masked]>
>>>>>> Well, the mechanisms are designed so that they could be deployed 
>>>>>> on devices and PBXs.  Whether they will be is a policy issue.
>>>>>>
>>>>>> The notion of credentials that are traceable to a delegation of a 
>>>>>> TN is a mechanism that is part of the design of stir, and the 
>>>>>> design allows delegation of one TN (to one device, although a 
>>>>>> device like a PBX would have more than one TN per "device", and 
>>>>>> something like a dual NAM phone could have more than one 
>>>>>> credential.  For the use case we've discussed, a mobile phone may 
>>>>>> also have a credential for, say, a TN that is delegated to a 
>>>>>> landline, to cover the example case of a doctor placing a call on 
>>>>>> his mobile, but getting his office number to show up as the calling party.  Use of such mechanisms is policy.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>
>>>>>>   Thanks Brian.  I'm afraid we're straying into a policy
>>>>>>   would like to continue the discussion, but I'm pretty sure this
>>>>>>   isn't the right forum.
>>>>>>
>>>>>>   Pierce
>>>>>>
>>>>>>   sign, but I understand many of the PBX vendors think that's
>>>>>>       You want IP PBXes to sign calls?  Won't that make it
>>>>>>       support the extra delegation required to support "authorized
>>>>>>       spoofing".  The companion devices I'm aware of always send
>>>>>>       Everyone will have to do work they don't do now to implement
>>>>>>       stop spoofed calls. TANSTAAFL
>>>>>>
>>>>>>       Brian
>>>>>>
>>>>>>
>>>>>>           support a parent subscriber number and "companion" devices
>>>>>>           authenticity of the calling number won't necessarily mean
>>>>>>           subscriber with a single MDN regardless of "laxity" of
>>>>>>           spoof checking.
>>>>>>
>>>>>>           placed using it's TN.  The design accommodates such use
>>>>>>           cases.  It's not a blanket authorization without
>>>>>>           authentication.   We're not aware of any cases where there
>>>>>>           service providers don't bother to check. At this point, at
>>>>>>               If it can't be ended, there's value in at least
>>>>>>               to the abuser.  Based on the assumption that it's
>>>>>>               may not include a specific service provider's
>>>>>>               authorization.
>>>>>>
>>>>>>
>>>>>>               and subject to replay in many cases.  An SDP body's
>>>>>>               with 'it's been used already' coordination allow a
>>>>>>               and possibly a numeric ID.   Some sort of '1-use'

---

From: Brian Rosen <[email-masked]>
Date: Fri, 5 Aug 2016 09:43:35 -0400

You can use any term you want, it’s not in the documents.  It’s how I explain how we handle cases like the call center or the doctor.

Jon/Chris his example is where PAI is different from From:, and both should be signed, PAI by the SP, From: by the enterprise.  Can we do that in a way that it is clear what happened?

Brian

> On Aug 5, 2016, at 3:46 AM, Rosbotham, Paul, Vodafone UK <[email-masked]> wrote:
>

---

From: Richard Shockey <[email-masked]>
Date: Fri, 05 Aug 2016 10:36:57 -0400

Humm this is getting interesting.  Its my understanding that the display number aka “presentation number” in the US context is the one carried in the PAI.  Martin, Pierce? 

On 8/5/16, 3:46 AM, "stir on behalf of Rosbotham, Paul, Vodafone UK" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    Regards
    
    Paul
    
    -----Original Message-----
    From: stir [mailto:[email-masked]] On Behalf Of Paul Kyzivat
    Sent: 04 August 2016 23:12
    To: Brian Rosen
    Cc: [email-masked]
    Subject: Re: [stir] STIR 4474bis-10 comments

    
    	Thanks,
    	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 5 Aug 2016 14:53:46 +0000

Yes if PAI present

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards 
AT&T
Cell: 609-903-3360
Email: [email-masked]

> On Aug 5, 2016, at 10:42 AM, Richard Shockey <[email-masked]> wrote:
> 
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 5 Aug 2016 11:16:08 -0400

Right, but we really don’t have a concept of “Display Numbers” vs “Network Numbers” in the US.  We do have cases where a call center would want to use the main number of an enterprise when it calls on behalf of that enterprise.  I would call that “authorized spoofing”, especially when the carrier for the enterprise is different from the carrier for the call center, but it doesn’t matter what we call it, we would have one number, and it probably would be in PAI (From would be ignored).  The call center could sign the call using a credential issued by the enterprise base on the credential it’s carrier issued to it.  Or, the call center’s carrier could sign using a credential issued by the enterprise carrier based on a request to the enterprise, or some other similar path.

In the UK case, they have two numbers, both of which are carried in the signaling, and Paul seemed to indicate that the network number was carried in PAI.

Brian

> On Aug 5, 2016, at 10:53 AM, DOLLY, MARTIN C <[email-masked]> wrote:
> 
> Yes if PAI present
> 
> Martin C Dolly

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 5 Aug 2016 15:26:54 +0000

P-Asserted-Identity is supposed to operate "among trusted SIP entities" and therefore some specifications (e.g., 3GPP TS 24.607) assume P-Asserted-Identity is stripped by border controller functions and is not to be used in inter-carrier inter-connection (although it commonly shows up anyway).  My opinion is the "From" header is likely used more often for presentation.

Pierce

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]]
Sent: August 05, 2016 9:37 AM
To: Rosbotham, Paul, Vodafone UK <[email-masked]>; Paul Kyzivat <[email-masked]>; Brian Rosen <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] STIR 4474bis-10 comments

    Regards

    Paul

    -----Original Message-----
    From: stir [mailto:[email-masked]] On Behalf Of Paul Kyzivat
    Sent: 04 August 2016 23:12
    To: Brian Rosen
    Cc: [email-masked]
    Subject: Re: [stir] STIR 4474bis-10 comments

    Thanks,
    Paul

---

From: "Rosbotham, Paul, Vodafone UK" <[email-masked]>
Date: Fri, 5 Aug 2016 15:34:42 +0000

Your interpretation's correct Brian - the UK spec is at http://www.niccstandards.org.uk/files/current/ND1035V2.1.1.pdf?type=pdf with Section 7 referring.  Looks like opposite way to you guys.

The details of protocol aren't really my thing & I'd need to check with the group that wrote that spec, but my interpretation is that we couldn't use PAI for display in our context because it's coming from the customer and (absent a STIR-type mechanism) the customer PBX is outside the trust domain so we can't paste anything they send into a PAI.  The first node in the regulated public network inserts the PAI under our implementation and we'll flow through whatever the customer sends us in the From.

Could make for some interesting interworking challenges at the international boundary!

Incidentally, another not uncommon use case is a customer dual parented to two service providers for resilience....the Presentation/display number is the same for both, but because we need to be able to trace back to a particular network ingress there'd be a separate Network Number (as we call it) for each.

Paul

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 05 August 2016 16:16
To: DOLLY, MARTIN C
Cc: Richard Shockey; Rosbotham, Paul, Vodafone UK; Paul Kyzivat; [email-masked]
Subject: Re: [stir] STIR 4474bis-10 comments

Right, but we really don't have a concept of "Display Numbers" vs "Network Numbers" in the US.  We do have cases where a call center would want to use the main number of an enterprise when it calls on behalf of that enterprise.  I would call that "authorized spoofing", especially when the carrier for the enterprise is different from the carrier for the call center, but it doesn't matter what we call it, we would have one number, and it probably would be in PAI (From would be ignored).  The call center could sign the call using a credential issued by the enterprise base on the credential it's carrier issued to it.  Or, the call center's carrier could sign using a credential issued by the enterprise carrier based on a request to the enterprise, or some other similar path.

Brian

> Core & Government/Regulatory Standards AT&T
> Cell: 609-903-3360
> Email: [email-masked]
> 
>> Humm this is getting interesting.  Its my understanding that the display number aka "presentation number" in the US context is the one carried in the PAI.  Martin, Pierce? 
>> 
>> 
>> 
>> 
>>   What I want is the ability for customers to use their credentials 
>> to sign the CLIs they send me so that at the terminating end it can 
>> be checked (or indeed somewhere en-route if that's the business 
>> model).  I can and would sign for customers on my mobile business 
>> since I'm driving what number is presented, but that's by-the-by 
>> because they aren't the ones who generate millions of nuisance calls.  
>> If the signing only occurs at the originating carrier level for 
>> corporate/call-centre customers that's no use because I'm not in a 
>> position to do that for these type of customers...and the whole 
>> system becomes a waste of time. I'd also highlight there are many 
>> more of my large customers that I'd trust more than a far end 
>> originating carrier that could be anywhere in the world (though we 
>> have no shortage of small carriers that I wouldn't know from Adam 
>> more locally in the UK....)
>> 
>>   Regards
>> 
>>   Paul
>> 
>>>>> The delegation to his office phone was made by his landline 
>>>>> carrier to him.  He then creates another credential, which he 
>>>>> signs with his office phone credential that authorizes his mobile 
>>>>> to send calls from his office number.  He is spoofing (because the 
>>>>> call is coming from his mobile's TN but claims to be from his 
>>>>> office), but it's authorized spoofing.  The doc could give the 
>>>>> credential to his mobile SP if they sign on his behalf.
>>>> 
>>>>>>> Making stir work means knowing who you are delegating to, so 
>>>>>>> that you can pass the hot potato.
>>>>>>> 
>>>>>>> It's perfectly reasonable for a carrier to be able to sign for 
>>>>>>> any calls placed on its network on any number it has been delegated.
>>>>>>> The root of the whole model is that there is a formal or 
>>>>>>> informal delegation path for telephone numbers in every country, 
>>>>>>> and we can build a chain of trust from that delegation path.  If 
>>>>>>> you propose to alter that model, then we get into (policy) 
>>>>>>> issues of which carriers/entities we trust and which we don't.  
>>>>>>> Our model is that you know who you delegate to, and once you do that delegation, it's their problem.
>>>>>>>> My reason for adding the authenticity of the originating 
>>>>>>>> carrier is typical trustworthiness of a carrier business 
>>>>>>>> relationship with typical consumers adds to the trustworthiness 
>>>>>>>> assessment and partially because carriers are a regulated point 
>>>>>>>> of forensic inquiry for CALEA and fraud.  Additionally, most 
>>>>>>>> calls originate and terminate between mobile consumers where 
>>>>>>>> their carriers are able to usefully authenticate their device 
>>>>>>>> and have a high degree of confidence of the authenticity of the calling number.
>>>>>>>> 
>>>>>>>> the calling party has to sign a call with a per-TN cert 
>>>>>>>> provided by the called party.  No called party cert to include?  
>>>>>>>> Then the calling party does not have a trusted relationship 
>>>>>>>> with the called party, and the call can be authorized/treated accordingly.
>>>>>>>> Well, the mechanisms are designed so that they could be 
>>>>>>>> deployed on devices and PBXs.  Whether they will be is a policy issue.
>>>>>>>> 
>>>>>>>> The notion of credentials that are traceable to a delegation of 
>>>>>>>> a TN is a mechanism that is part of the design of stir, and the 
>>>>>>>> credential.  For the use case we've discussed, a mobile phone 
>>>>>>>> may also have a credential for, say, a TN that is delegated to 
>>>>>>>> a landline, to cover the example case of a doctor placing a 
>>>>>>>> call on his mobile, but getting his office number to show up as the calling party.  Use of such mechanisms is policy.
>>>>>>>> 
>>>>>>>> Brian
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Of course I want PBXs to sign calls.  As well as smart phones 
>>>>>>>> and any other devices that can be programmed to do so.
>>>>>>>> they are authorized to sign for.  They can try to sign any 
>>>>>>>> call, but the validity of the credential would make such a 
>>>>>>>> signature fail the checking.
>>>>>>>> 
>>>>>>>> reasonable way to deploy quickly, but I expect many SPs will 
>>>>>>>> want to get out of the liability of signing on behalf of their 
>>>>>>>> appropriate credential when they assign TNs, then I would 
>>>>>>>> expect them to want to do so.  That means the devices have to 
>>>>>>>> be able to sign, but I understand many of the PBX vendors think 
>>>>>>>> that's something they could provide in a future release.
>>>>>>>> 
>>>>>>>> Brian
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> --
>>>>>>>> -------
>>>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 5 Aug 2016 12:57:39 -0400

If PAI is present and signed, and From is also signed, I would expect it 
to be up to the UA to decide what to display, not the carrier.

Of course this will work differently if there is a different signaling 
regime between the carrier and the user device (e.g. black phone).

	Thanks,
	Paul

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 5 Aug 2016 17:04:10 +0000

Which header the carrier chooses to display is moot if the header is stripped between carriers as per at least one standard.  I think Paul Rosbotham's observation we're likely to encounter "some interesting interworking challenges" was perhaps the understatement of the year.

Pierce

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: August 05, 2016 11:58 AM
To: Gorman, Pierce A [CTO] <[email-masked]>; Richard Shockey <[email-masked]>; Rosbotham, Paul, Vodafone UK <[email-masked]>; Brian Rosen <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] STIR 4474bis-10 comments

If PAI is present and signed, and From is also signed, I would expect it to be up to the UA to decide what to display, not the carrier.

Of course this will work differently if there is a different signaling regime between the carrier and the user device (e.g. black phone).

	Thanks,
	Paul

On 8/5/16 11:26 AM, Gorman, Pierce A [CTO] wrote:
> To: Rosbotham, Paul, Vodafone UK <[email-masked]>; Paul 
> Kyzivat <[email-masked]>; Brian Rosen <[email-masked]>
> Cc: [email-masked]
> to sign the CLIs they send me so that at the terminating end it can be 
> checked (or indeed somewhere en-route if that's the business model).  
> I can and would sign for customers on my mobile business since I'm 
> driving what number is presented, but that's by-the-by because they 
> aren't the ones who generate millions of nuisance calls.  If the 
> signing only occurs at the originating carrier level for 
> position to do that for these type of customers...and the whole system 
> becomes a waste of time. I'd also highlight there are many more of my 
> large customers that I'd trust more than a far end originating carrier 
> that could be anywhere in the world (though we have no shortage of 
> small carriers that I wouldn't know from Adam more locally in the 
> UK....)
>
>     Regards
>
>     Paul
>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 5 Aug 2016 17:54:34 +0000

PAI is not stripped at the network boundary between trusted networks
3GPP TS 29.195
Atis specs
GSMA
Atis sip forum task force 
ITU
And the list goes on

Martin C Dolly

> On Aug 5, 2016, at 1:04 PM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
>

---

From: Richard Shockey <[email-masked]>
Date: Fri, 05 Aug 2016 13:56:45 -0400

Don’t be so sure. If it’s a mobile device or perhaps cable you can bet the carrier will have some say in what is displayed on the UA. 

On 8/5/16, 12:57 PM, "stir on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

    
    	Thanks,
    	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 5 Aug 2016 15:32:58 -0400

> Don’t be so sure. If it’s a mobile device or perhaps cable you can bet the carrier will have some say in what is displayed on the UA.

I said that is what I would *expect*. I also said "if the PAI is 
present". Of course the carrier can strip the PAI. (And *should* if the 
caller requested anonymity.)

If the information is passed to the device, then AFAIK the user could 
install software that would be free to decide what to display. If the 
carrier is the supplier of the OS on the phone then it can try to "lock 
down" this aspect. But IIUC that is inconsistent with current practice. 
And it wouldn't apply to devices they don't manage, like Nexus phones.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 5 Aug 2016 15:35:43 -0400

> Atis sip forum task force

Is there any reason to strip it at an *untrusted* boundary?

(Yes, there *is* a reason to do so if the caller requested anonymity. 
But other than that.)

Leaving it in provides the recipient with useful information.

	Thanks,
	Paul

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 5 Aug 2016 19:51:17 +0000

A serious challenge to usability is simplicity.  A complicating factor is variability in the trustworthiness of several different use cases of authenticated calling numbers signed using STIR/PASSporT mechanisms.

It would be "nice" if there was a simple set of authentication rules and display that are consistent across carriers, and platform OS.  At least for anything carriers are required to do by mandate, regulation, and standard.  This benefits consumers in that if done properly, at a minimum the authentication at/on Carrier A should mean the same thing as authentication at/on Carrier B.

Premium, enhanced products using authorization, analytics, accept/deny lists, et cetera, should of course be unrestricted, and the marketplace can drive the best solution.  Coexistence seems possible and desirable.

Pierce

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: August 05, 2016 2:33 PM
To: [email-masked]
Subject: Re: [stir] STIR 4474bis-10 comments

> Don’t be so sure. If it’s a mobile device or perhaps cable you can bet the carrier will have some say in what is displayed on the UA.

I said that is what I would *expect*. I also said "if the PAI is present". Of course the carrier can strip the PAI. (And *should* if the caller requested anonymity.)

If the information is passed to the device, then AFAIK the user could install software that would be free to decide what to display. If the carrier is the supplier of the OS on the phone then it can try to "lock down" this aspect. But IIUC that is inconsistent with current practice. 
And it wouldn't apply to devices they don't manage, like Nexus phones.

	Thanks,
	Paul

---

From: "Rosbotham, Paul, Vodafone UK" <[email-masked]>
Date: Fri, 5 Aug 2016 20:16:45 +0000

This all depends on context.

In the UK the Network Number (what we have in PAI) is network internal, not passed to end users. On originating connections from large enterprise SIP networks in particular, as the NN represents where the call hits the public network it'd be highly misleading/irrelevant as far a the terminating customer's concerned.

Rgds

Paul

-------- Original Message --------

From: Paul Kyzivat <[email-masked]>

Date: 5 Aug 2016 17:57

To: "Gorman, Pierce A [CTO]" <[email-masked]>,Richard Shockey <[email-masked]>,"Rosbotham, Paul, Vodafone UK" <[email-masked]>,Brian Rosen <[email-masked]>

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 5 Aug 2016 18:50:38 -0400

On 8/5/16 4:16 PM, Rosbotham, Paul, Vodafone UK wrote:
> In the UK the Network Number (what we have in PAI) is network internal,
> not passed to end users. On originating connections from large
> enterprise SIP networks in particular, as the NN represents where the
> call hits the public network it'd be highly misleading/irrelevant as far
> a the terminating customer's concerned.

OK, fine. If it isn't a number that means anything to the end user then 
I agree there is no point in disclosing it.

	Thanks,
	Paul

> To: "Gorman, Pierce A [CTO]" <[email-masked]>,Richard Shockey
> <[email-masked]>,"Rosbotham, Paul, Vodafone UK"
> <[email-masked]>,Brian Rosen <[email-masked]>
>
>> P-Asserted-Identity is supposed to operate "among trusted SIP entities" and therefore some specifications (e.g., 3GPP TS 24.607) assume P-Asserted-Identity is stripped by border controller functions and is not to be used in inter-carrier inter-connection (although it commonly shows up anyway).  My opinion is the "From"
> header is likely used more often for presentation.
>>
>> Pierce
>>
>>
>>     But - subject to regulatory restrictions which are well documented - the number sent for display purposes belongs to the customer.  For blue-chip customers, I can allow them to send their Presentation Numbers into the network, and can't readily check at a network level that they're theirs (I do have contractual
> safeguards).  The number may have been allocated by me, or could be
> allocated by a third party provider.  If it's a call-centre they'll be
> making outbound calls for lots of different customers which will change
> on day-by-day basis.  This is business as usual.  I don't like the term
> "authorised spoofing" because it implies that the CLI is in some way
> being rigged: it's not, it's the corporate customer or their
> subcontractor using the number that's been assigned (so in internet
> terms delegated) to them via a chain of trust from the regulator.
>>
>>     What I want is the ability for customers to use their credentials to sign the CLIs they send me so that at the terminating end it can be checked (or indeed somewhere en-route if that's the business model).  I can and would sign for customers on my mobile business since I'm driving what number is presented, but that's
> by-the-by because they aren't the ones who generate millions of nuisance
> calls.  If the signing only occurs at the originating carrier level for
> that could be anywhere in the world (though we have no shortage of small
> carriers that I wouldn't know from Adam more locally in the UK....)
>>
>>     Regards
>>
>>     Paul
>>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 8 Aug 2016 13:52:29 +0000

Martin,

You referenced TS 29.195.  I'm not familiar with that spec.  Has it been deprecated?  It's not showing up on the 3GPP site.

I referenced 3GPP TS 24.607.  In Section 4.3.2 "Requirements on the originating side" Note 4 it states, " It is assumed that the IBCF is responsible for stripping the P-Asserted-Identity from the SIP header when
interworking with untrusted networks."

Your remark is consistent with Note 4, but only if we agree that, for instance, the AT&T network and the Sprint network are "trusted networks".  In reality, this is not the case or there would be no firewalls or Session Border Controllers used for interworking and security.  My opinion is the only carrier networks that are trusted are the SS7 network, and the Internet backbone.

What it really comes down to is that PAI is left in signaling either through formal specification as a part of an inter-carrier inter-connection agreement, or by custom (or even by accident).  I think this illustrates Paul Rosbotham's observation is true. 

Pierce

-----Original Message-----
From: DOLLY, MARTIN C [mailto:[email-masked]] 
Sent: August 05, 2016 12:55 PM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]; Paul Kyzivat <[email-masked]>; Richard Shockey <[email-masked]>
Subject: Re: [stir] STIR 4474bis-10 comments

PAI is not stripped at the network boundary between trusted networks 3GPP TS 29.195 Atis specs GSMA Atis sip forum task force ITU And the list goes on

Martin C Dolly

> To: Gorman, Pierce A [CTO] <[email-masked]>; Richard Shockey 
> <[email-masked]>; Rosbotham, Paul, Vodafone UK 
> <[email-masked]>; Brian Rosen <[email-masked]>
> Cc: [email-masked]
>> be checked (or indeed somewhere en-route if that's the business model).
>>>>>>>> be able to  sign, but I understand many of the PBX vendors 
>>>>>>>> think that's  something they could provide in a future release.
>>>>>>>> 
>>>>>>>>  Brian
>>>>>>>> 
>>>>>>>>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 8 Aug 2016 11:46:58 -0400

Pierce,

My assumption is that Martin morphed 2 specs, 3GPP TS 29.165 and GSMA IR.95.  The latter references and profiles the former.  Section 4.4.1 of IR.95 recommends that MNO-to-MNO or MNO-to-IPX interconnects be considered trusted, and table 3 in that section recommends that P-Asserted-Identity (PAI) be exchanged at a trusted interconnect.  It also states that PAI is mandatory at a roaming NNI.

Tim

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [CTO]
Sent: Monday, August 08, 2016 8:52 AM
To: DOLLY, MARTIN C
Cc: Rosbotham, Paul, Vodafone UK; Richard Shockey; Paul Kyzivat; [email-masked]; Brian Rosen
Subject: [E] Re: [stir] STIR 4474bis-10 comments

Martin,

I referenced 3GPP TS 24.607.  In Section 4.3.2 "Requirements on the originating side" Note 4 it states, " It is assumed that the IBCF is responsible for stripping the P-Asserted-Identity from the SIP header when interworking with untrusted networks."

Pierce

-----Original Message-----
From: DOLLY, MARTIN C [mailto:[email-masked]]
Sent: August 05, 2016 12:55 PM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]; Paul Kyzivat <[email-masked]>; Richard Shockey <[email-masked]>
Subject: Re: [stir] STIR 4474bis-10 comments

Martin C Dolly

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 8 Aug 2016 16:11:29 +0000

Thanks for the added comments Tim.

I agree that passing P-Asserted-Identity between trusted networks is appropriate (and the converse is true as well).  Part of my issue is I have been conditioned from the very earliest implementation of Sprint's VoIP network that other carriers' IP networks are inherently untrusted.  I've been browsing TS 29.165 and even there I find language that implies trust is established by agreement, not by standard.  (Even roaming implies agreement.)

Regardless, this discussion has been helpful and educational (to me at least).  And, I confirmed with my operations counterpart we generally send PAI today.  I've also made note that where standards and ICA require it, we will include PAI.   Thanks again.

Best regards,

Pierce 

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: August 08, 2016 10:47 AM
To: Gorman, Pierce A [CTO] <[email-masked]>; DOLLY, MARTIN C <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Richard Shockey <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]; Brian Rosen <[email-masked]>
Subject: RE: [stir] STIR 4474bis-10 comments

Pierce,

Tim

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [CTO]
Sent: Monday, August 08, 2016 8:52 AM
To: DOLLY, MARTIN C
Cc: Rosbotham, Paul, Vodafone UK; Richard Shockey; Paul Kyzivat; [email-masked]; Brian Rosen
Subject: [E] Re: [stir] STIR 4474bis-10 comments

Martin,

Pierce

-----Original Message-----
From: DOLLY, MARTIN C [mailto:[email-masked]]
Sent: August 05, 2016 12:55 PM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]; Paul Kyzivat <[email-masked]>; Richard Shockey <[email-masked]>
Subject: Re: [stir] STIR 4474bis-10 comments

Martin C Dolly

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Aug 2016 13:03:06 -0400

> I agree that passing P-Asserted-Identity between trusted networks is appropriate (and the converse is true as well).  Part of my issue is I have been conditioned from the very earliest implementati…

I understand why *some* stuff needs to be removed when forwarding to an 
untrusted party. For instance, if the call has requested privacy, then 
P-A-ID needs to be removed.

But when privacy is not a concern, trust is really more of a concern on 
the ingress side, not egress. If I don't trust you then I won't trust a 
P-A-ID you sent to me, and so *I* will remove it. But if I trust you, 
but you don't trust me, then what is the downside for passing along the 
P-A-ID?

	Thanks,
	Paul

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 8 Aug 2016 18:38:37 +0000

Paul,

As you know, SIP inter-working is often challenging because of variability in implementation including proprietary headers (without an X-) and support or lack thereof for non-mandatory (per RFC 3261) headers such as P-Asserted-Identity, (and things like B2BUA stacks stripping things like display name in From but that's another story).  I could argue that from a cleanliness of protocol implementation, (and if I wanted to be pedantic), I would strip PAI outbound unless required otherwise.  But the point is moot.  As I mentioned in the earlier e-mail, that is not our practice and I'm not requesting it to be so.

Pierce

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: August 08, 2016 12:03 PM
To: Gorman, Pierce A [CTO] <[email-masked]>; Dwight, Timothy M (Tim) <[email-masked]>; DOLLY, MARTIN C <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Richard Shockey <[email-masked]>; [email-masked]; Brian Rosen <[email-masked]>
Subject: Re: [stir] STIR 4474bis-10 comments

On 8/8/16 12:11 PM, Gorman, Pierce A [CTO] wrote:
> I agree that passing P-Asserted-Identity between trusted networks is 
> appropriate (and the converse is true as well).  Part of my issue is I 
> have been conditioned from the very earliest implementation of 
> Sprint's VoIP network that other carriers' IP networks are inherently 
> untrusted.  I've been browsing TS 29.165 and even there I find 
> language that implies trust is established by agreement, not by 
> standard.  (Even roaming implies agreement.)

I understand why *some* stuff needs to be removed when forwarding to an untrusted party. For instance, if the call has requested privacy, then P-A-ID needs to be removed.

But when privacy is not a concern, trust is really more of a concern on the ingress side, not egress. If I don't trust you then I won't trust a P-A-ID you sent to me, and so *I* will remove it. But if I trust you, but you don't trust me, then what is the downside for passing along the P-A-ID?

	Thanks,
	Paul

> Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; 
> Richard Shockey <[email-masked]>; Paul Kyzivat 
> <[email-masked]>; [email-masked]; Brian Rosen 
> <[email-masked]>
> Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Brian 
> Rosen <[email-masked]>; [email-masked]; Paul Kyzivat 
> <[email-masked]>; Richard Shockey <[email-masked]>
> 3GPP TS 29.195 Atis specs GSMA Atis sip forum task force ITU And the 
> list goes on
>
> Martin C Dolly
>> To: Gorman, Pierce A [CTO] <[email-masked]>; Richard 
>> Shockey <[email-masked]>; Rosbotham, Paul, Vodafone UK 
>>>>>> to send calls from his office number.  He is spoofing (because 
>>>>>> the call is coming from his mobile's TN but claims to be from his 
>>>>>>>> long as the delegator is willing to take the heat for 
>>>>>>>> delegating to someone who sends a lot of bad calls.  They can 
>>>>>>>> pass the buck ("I delegated the TN to him, and now I'm not 
>>>>>>>> responsible"), but only if the SP knows who they delegated to, 
>>>>>>>> so authorities can follow the delegation path.  There are 
>>>>>>>> plenty of certificated carriers who are willing to not care who they delegate to.  The fact that there are some who do doesn't change much.
>>>>>>>> That should be straightforward, but we know it's not always, 
>>>>>>>> and that represents the hard part of deployment in my opinion.  
>>>>>>>> But once they delegate, they can hand responsibility to sign to 
>>>>>>>> the delegatee.  But, that only works if they know who they are delegating to.
>>>>>>>>
>>>>>>>> informal delegation path for telephone numbers in every 
>>>>>>>> country, and we can build a chain of trust from that delegation 
>>>>>>>> path.  If you propose to alter that model, then we get into 
>>>>>>>> (policy) issues of which carriers/entities we trust and which we don't.
>>>>>>>>> reason for suggesting a way to qualify the signature to 
>>>>>>>>> reflect that variability.
>>>>>>>>>
>>>>>>>>> relationship with typical consumers adds to the 
>>>>>>>>> trustworthiness assessment and partially because carriers are 
>>>>>>>>> a regulated point of forensic inquiry for CALEA and fraud.  
>>>>>>>>> Additionally, most calls originate and terminate between 
>>>>>>>>> authenticate their device and have a high degree of confidence of the authenticity of the calling number.
>>>>>>>>>
>>>>>>>>> Conversely, I think billions of per-TN certs will work well, 
>>>>>>>>> if the calling party has to sign a call with a per-TN cert 
>>>>>>>>> The notion of credentials that are traceable to a delegation 
>>>>>>>>> of a TN is a mechanism that is part of the design of stir, and 
>>>>>>>>> the design allows delegation of one TN (to one device, 
>>>>>>>>> although a device like a PBX would have more than one TN per 
>>>>>>>>> "device", and something like a dual NAM phone could have more 
>>>>>>>>> than one credential.  For the use case we've discussed, a 
>>>>>>>>> mobile phone may also have a credential for, say, a TN that is 
>>>>>>>>> delegated to a landline, to cover the example case of a doctor 
>>>>>>>>> placing a call on his mobile, but getting his office number to show up as the calling party.  Use of such mechanisms is policy.
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> would like to continue the discussion, but I'm pretty sure 
>>>>>>>>> this isn't the right forum.
>>>>>>>>>
>>>>>>>>>  Pierce
>>>>>>>>>
>>>>>>>>>  They will be given credentials that only are valid for the 
>>>>>>>>> TNs they are authorized to sign for.  They can try to sign any 
>>>>>>>>> want  to get out of the liability of signing on behalf of 
>>>>>>>>> their customers.  If they can push of that responsibility to 
>>>>>>>>> their customer, only being responsible for getting the 
>>>>>>>>> customer an appropriate credential when they assign TNs, then 
>>>>>>>>> I would expect  them to want to do so.  That means the devices 
>>>>>>>>> have to be able to  sign, but I understand many of the PBX 
>>>>>>>>> vendors think that's  something they could provide in a future release.
>>>>>>>>>
>>>>>>>>>  Brian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>              <[email-masked] <mailto:[email-masked]> 
>>>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>>>
>>>>>>>>>                 "authentication service" which validates 
>>>>>>>>> caller identity at or near origination.  outgoing
>>>>>>>>>              requests.  An
>>>>>>>>>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 8 Aug 2016 15:31:37 +0000

29.165

-----Original Message-----
From: Gorman, Pierce A [CTO] [mailto:[email-masked]] 
Sent: Monday, August 08, 2016 9:52 AM
To: DOLLY, MARTIN C <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]; Paul Kyzivat <[email-masked]>; Richard Shockey <[email-masked]>
Subject: RE: [stir] STIR 4474bis-10 comments

Martin,

Pierce

-----Original Message-----
From: DOLLY, MARTIN C [mailto:[email-masked]]
Sent: August 05, 2016 12:55 PM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]; Paul Kyzivat <[email-masked]>; Richard Shockey <[email-masked]>
Subject: Re: [stir] STIR 4474bis-10 comments

Martin C Dolly

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 8 Aug 2016 19:46:12 +0000

Just so I'm clear, I'm not hearing an ask here in terms of changing the
text of rfc4474bis-10, which does allow signing PAI instead of From for
precisely the reasons outlined in this lengthy thread. To Alex's original
point about providing authorization without authentication, rfc4474bis has
a lot of text about signing non-TN identifiers, including for preserving
anonymity; see the end of section 6.1, and then the Privacy Considerations
in section 11 for more. Those should suffice to provide this property: it
will identify the service provider who signed without attesting an
specific user identity.

I also wanted to make sure we didn't drop the other ball that Alex
mentioned at the start of this thread, which is the issue of proximate
replay within the 60 second Date window. This is addressed in Section 12.1
of rfc4474bis-10, which reads: "Note that per baseline [RFC3261] behavior,
servers keep state of recently received requests, and thus if an Identity
header is replayed by an attacker within the Date interval, verifiers can
detect that it is spoofed because a message with an identical Date from
the same source had recently been received." This refers to the text of
RFC3261 section 23.4.2, though more properly the Date-related behavior is
better detailed in RFC3893 Section 10, which introduced the first version
of the partial signature mechanism that ultimately inspired RFC4474. I'll
update the text here so it is clearer about exactly how to detect
proximate replay.

Jon Peterson
Neustar, Inc.

On 8/8/16, 11:38 AM, "stir on behalf of Gorman, Pierce A [CTO]"
<[email-masked] on behalf of [email-masked]> wrote:

>Paul,
>
>As you know, SIP inter-working is often challenging because of
>variability in implementation including proprietary headers (without an
>X-) and support or lack thereof for non-mandatory (per RFC 3261) headers
>such as P-Asserted-Identity, (and things like B2BUA stacks stripping
>things like display name in From but that's another story).  I could
>argue that from a cleanliness of protocol implementation, (and if I
>wanted to be pedantic), I would strip PAI outbound unless required
>otherwise.  But the point is moot.  As I mentioned in the earlier e-mail,
>that is not our practice and I'm not requesting it to be so.
>
>Pierce
>
>
>To: Gorman, Pierce A [CTO] <[email-masked]>; Dwight, Timothy M
>(Tim) <[email-masked]>; DOLLY, MARTIN C <[email-masked]>
>Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Richard
>Shockey <[email-masked]>; [email-masked]; Brian Rosen
><[email-masked]>
>P-A-ID you sent to me, and so *I* will remove it. But if I trust you, but
>you don't trust me, then what is the downside for passing along the
>P-A-ID?
>
>	Thanks,
>	Paul
>
>> Regardless, this discussion has been helpful and educational (to me at
>>least).  And, I confirmed with my operations counterpart we generally
>>send PAI today.  I've also made note that where standards and ICA
>>require it, we will include PAI.   Thanks again.
>>
>> Best regards,
>>
>> Pierce
>>
>> My assumption is that Martin morphed 2 specs, 3GPP TS 29.165 and GSMA
>>IR.95.  The latter references and profiles the former.  Section 4.4.1 of
>>IR.95 recommends that MNO-to-MNO or MNO-to-IPX interconnects be
>>considered trusted, and table 3 in that section recommends that
>>P-Asserted-Identity (PAI) be exchanged at a trusted interconnect.  It
>>also states that PAI is mandatory at a roaming NNI.
>>
>> Tim
>>
>>
>> You referenced TS 29.195.  I'm not familiar with that spec.  Has it
>>been deprecated?  It's not showing up on the 3GPP site.
>>
>> I referenced 3GPP TS 24.607.  In Section 4.3.2 "Requirements on the
>>originating side" Note 4 it states, " It is assumed that the IBCF is
>>responsible for stripping the P-Asserted-Identity from the SIP header
>>when interworking with untrusted networks."
>>
>> Your remark is consistent with Note 4, but only if we agree that, for
>>instance, the AT&T network and the Sprint network are "trusted
>>networks".  In reality, this is not the case or there would be no
>>firewalls or Session Border Controllers used for interworking and
>>security.  My opinion is the only carrier networks that are trusted are
>>the SS7 network, and the Internet backbone.
>>
>> What it really comes down to is that PAI is left in signaling either
>>through formal specification as a part of an inter-carrier
>>inter-connection agreement, or by custom (or even by accident).  I think
>>this illustrates Paul Rosbotham's observation is true.
>>
>> Pierce
>>
>>> Which header the carrier chooses to display is moot if the header is
>>>stripped between carriers as per at least one standard.  I think Paul
>>>Rosbotham's observation we're likely to encounter "some interesting
>>>interworking challenges" was perhaps the understatement of the year.
>>>
>>> Pierce
>>>
>>> If PAI is present and signed, and From is also signed, I would expect
>>>it to be up to the UA to decide what to display, not the carrier.
>>>
>>>> P-Asserted-Identity is supposed to operate "among trusted SIP
>>>>entities" and therefore some specifications (e.g., 3GPP TS 24.607)
>>>>assume P-Asserted-Identity is stripped by border controller functions
>>>>and is not to be used in inter-carrier inter-connection (although it
>>>>commonly shows up anyway).  My opinion is the "From" header is likely
>>>>used more often for presentation.
>>>>
>>>> Pierce
>>>>
>>>>
>>>> Humm this is getting interesting.  Its my understanding that the
>>>>display number aka "presentation number" in the US context is the one
>>>>carried in the PAI.  Martin, Pierce?
>>>>
>>>>
>>>>
>>>>
>>>> On 8/5/16, 3:46 AM, "stir on behalf of Rosbotham, Paul, Vodafone UK"
>>>><[email-masked] on behalf of [email-masked]> wrote:
>>>>
>>>>    Here in the UK, we've got 2 numbers carried as calling line
>>>>IDs....one (we term the Network Number, carried in PAID) uniquely
>>>>identifies the line, the other (we term Presentation Number, carried
>>>>in From) is used for display purposes.
>>>>
>>>>    But - subject to regulatory restrictions which are well documented
>>>>- the number sent for display purposes belongs to the customer.  For
>>>>blue-chip customers, I can allow them to send their Presentation
>>>>Numbers into the network, and can't readily check at a network level
>>>>that they're theirs (I do have contractual safeguards).  The number
>>>>may have been allocated by me, or could be allocated by a third party
>>>>provider.  If it's a call-centre they'll be making outbound calls for
>>>>lots of different customers which will change on day-by-day basis.
>>>>This is business as usual.  I don't like the term "authorised
>>>>spoofing" because it implies that the CLI is in some way being rigged:
>>>>it's not, it's the corporate customer or their subcontractor using the
>>>>number that's been assigned (so in internet terms delegated) to them
>>>>via a chain of trust from the regulator.
>>>>
>>>>model).
>>>>> I think it's not a delegation.  The mobile phone is not being
>>>>>delegated the TN, it's being authorized to place calls that are not
>>>>>from that TN, but appear to be.
>>>>>
>>>>> The mechanism to handle the credential is exactly the same as a
>>>>>delegation, so if you want to call it delegation, go ahead, but I
>>>>>prefer to call it authorized spoofing.
>>>>
>>>>    IIUC the delegation is to a responsible entity (something that can
>>>>be held legally accountable - e.g. a person), not to a device. The
>>>>entity can then "use" the credential via any device(s) it chooses. In
>>>>the case of the mobile, the device then becomes a two-line phone.
>>>>
>>>>    Thanks,
>>>>    Paul
>>>>
>>>>> Brian
>>>>>
>>>>>>landline number, he should be able to install that in whatever
>>>>>>devices he wants - his landline UA, his mobile phone, etc. It is
>>>>>>still delegated from his landline carrier, even when used with calls
>>>>>>via his mobile carrier.
>>>>>>
>>>>>> Thanks,
>>>>>> Paul
>>>>>>
>>>>>>>>> plenty of certificated carriers who are willing to not care who
>>>>>>>>>they delegate to.  The fact that there are some who do doesn't
>>>>>>>>>change much.
>>>>>>>>>> authenticate their device and have a high degree of confidence
>>>>>>>>>>of the authenticity of the calling number.
>>>>>>>>>>
>>>>>>>>>> placing a call on his mobile, but getting his office number to
>>>>>>>>>>          Use case example(s): E911 on visited network w/o
>>>>>>>>>>roaming
>>>>>>>>>>          agreement, manual roaming.
>>>>>>>>>>          Trust Estimate:  Carrier_orig trustworthy, CgPN
>>>>>>>>>>entirely
>>>>>>>>>>          untrustworthy
>>>>>>>>>>
>>>>>>>>>>          Use case example(s): Number block delegated from OCN,
>>>>>>>>>>but
>>>>>>>>>>          no per-TN screen (SIP trunks).
>>>>>>>>>><file:///C:/Users/ab3778/Documents/IETF/draft-ietf-stir-rfc4474bi
>>>>>>>>>>s-10%20-%20Authenticated%20Identity%20Management%20in%20the%20Ses
>>>>>>>>>>sion%20Initiation%20Protocol%20%28SIP%29.htm#section-3>.
>>>>>>>>>>                  Background
>>>>>>>>>>
>>>>>>>>>>              [...]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                 Per [RFC7340
>>>> This e-mail may contain Sprint proprietary information intended for 
>>>>the sole use of the recipient(s). Any use by others is prohibited. If 
>>>>you are not the intended recipient, please contact the sender and 
>>>>delete all copies of the message.
>>>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 8 Aug 2016 20:01:03 +0000

Agree.

Pierce
-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: August 08, 2016 2:46 PM
To: Gorman, Pierce A [CTO] <[email-masked]>; Paul Kyzivat <[email-masked]>; Dwight, Timothy M (Tim) <[email-masked]>; DOLLY, MARTIN C <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]; Richard Shockey <[email-masked]>
Subject: Re: [stir] STIR 4474bis-10 comments

Just so I'm clear, I'm not hearing an ask here in terms of changing the text of rfc4474bis-10, which does allow signing PAI instead of From for precisely the reasons outlined in this lengthy thread. To Alex's original point about providing authorization without authentication, rfc4474bis has a lot of text about signing non-TN identifiers, including for preserving anonymity; see the end of section 6.1, and then the Privacy Considerations in section 11 for more. Those should suffice to provide this property: it will identify the service provider who signed without attesting an specific user identity.

I also wanted to make sure we didn't drop the other ball that Alex mentioned at the start of this thread, which is the issue of proximate replay within the 60 second Date window. This is addressed in Section 12.1 of rfc4474bis-10, which reads: "Note that per baseline [RFC3261] behavior, servers keep state of recently received requests, and thus if an Identity header is replayed by an attacker within the Date interval, verifiers can detect that it is spoofed because a message with an identical Date from the same source had recently been received." This refers to the text of
RFC3261 section 23.4.2, though more properly the Date-related behavior is better detailed in RFC3893 Section 10, which introduced the first version of the partial signature mechanism that ultimately inspired RFC4474. I'll update the text here so it is clearer about exactly how to detect proximate replay.

Jon Peterson
Neustar, Inc.

On 8/8/16, 11:38 AM, "stir on behalf of Gorman, Pierce A [CTO]"
<[email-masked] on behalf of [email-masked]> wrote:

>X-) and support or lack thereof for non-mandatory (per RFC 3261)
>headers such as P-Asserted-Identity, (and things like B2BUA stacks
>stripping things like display name in From but that's another story).
>I could argue that from a cleanliness of protocol implementation, (and
>if I wanted to be pedantic), I would strip PAI outbound unless required
>otherwise.  But the point is moot.  As I mentioned in the earlier
>e-mail, that is not our practice and I'm not requesting it to be so.
>
>Pierce
>
>
>> appropriate (and the converse is true as well).  Part of my issue is
>> I have been conditioned from the very earliest implementation of
>> Regardless, this discussion has been helpful and educational (to me
>>at least).  And, I confirmed with my operations counterpart we
>>generally send PAI today.  I've also made note that where standards and ICA
>>security.  My opinion is the only carrier networks that are trusted
>>are the SS7 network, and the Internet backbone.
>>
>>inter-connection agreement, or by custom (or even by accident).  I
>>think this illustrates Paul Rosbotham's observation is true.
>>
>> Pierce
>>
>>> If PAI is present and signed, and From is also signed, I would
>>>expect it to be up to the UA to decide what to display, not the carrier.
>>>
>>> Of course this will work differently if there is a different
>>>signaling regime between the carrier and the user device (e.g. black phone).
>>>
>>>    Thanks,
>>>    Paul
>>>
>>>>assume P-Asserted-Identity is stripped by border controller
>>>>functions and is not to be used in inter-carrier inter-connection
>>>>(although it commonly shows up anyway).  My opinion is the "From"
>>>> To: Rosbotham, Paul, Vodafone UK <[email-masked]>;
>>>> Paul Kyzivat <[email-masked]>; Brian Rosen
>>>> <[email-masked]>
>>>> Cc: [email-masked]
>>>>display number aka "presentation number" in the US context is the
>>>>one carried in the PAI.  Martin, Pierce?
>>>>
>>>>
>>>>
>>>>
>>>>may have been allocated by me, or could be allocated by a third
>>>>party provider.  If it's a call-centre they'll be making outbound
>>>>calls for lots of different customers which will change on day-by-day basis.
>>>>it's not, it's the corporate customer or their subcontractor using
>>>>the number that's been assigned (so in internet terms delegated) to
>>>>them via a chain of trust from the regulator.
>>>>
>>>>    What I want is the ability for customers to use their
>>>>credentials  to sign the CLIs they send me so that at the
>>>>terminating end it can  be checked (or indeed somewhere en-route if
>>>>that's the business model).
>>>>    IIUC the delegation is to a responsible entity (something that
>>>>can be held legally accountable - e.g. a person), not to a device.
>>>>The entity can then "use" the credential via any device(s) it
>>>>chooses. In the case of the mobile, the device then becomes a two-line phone.
>>>>
>>>>    Thanks,
>>>>    Paul
>>>>
>>>>> Brian
>>>>>
>>>>>>> In my jargon an "authorized spoofer" is the doctor who is
>>>>>>>calling  from his mobile, but sending the TN of his office phone
>>>>>>>as calling party.
>>>>>> When his landline carrier gave him a delegated certificate for
>>>>>>his landline number, he should be able to install that in whatever
>>>>>>still delegated from his landline carrier, even when used with
>>>>>>calls via his mobile carrier.
>>>>>>
>>>>>> Thanks,
>>>>>> Paul
>>>>>>
>>>>>>>>> But once they delegate, they can hand responsibility to sign
>>>>>>>>>to  the delegatee.  But, that only works if they know who they
>>>>>>>>>are delegating to.
>>>>>>>>>
>>>>>>>>>> I agree that the STIR/PASSporT mechanisms could be deployed
>>>>>>>>>>on  individual devices as well as multi-device and
>>>>>>>>>>multi-number platforms.
>>>>>>>>>>
>>>>>>>>>>  Of course I want PBXs to sign calls.  As well as smart
>>>>>>>>>> phones and  any other devices that can be programmed to do so.
>>>>>>>>>> TNs they are authorized to sign for.  They can try to sign
>>>>>>>>>> any call,  but the validity of the credential would make such
>>>>>>>>>> a signature  fail the checking.
>>>>>>>>>>
>>>>>>>>>>          Use case example(s): Number block delegated from
>>>>>>>>>>OCN, but
>>>>>>>>>>              spec.  First, one or more proximate (e.g.,
>>>>>>>>>>within
>>>>>>>>>>60
>>>>>>>>>>s-10%20-%20Authenticated%20Identity%20Management%20in%20the%20
>>>>>>>>>>Ses sion%20Initiation%20Protocol%20%28SIP%29.htm#section-3>.
>>>>>>>>>>                  Background
>>>>>>>>>>
>>>>>>>>>>              [...]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                 Per [RFC7340
>>>>>>>>>>                 of authenticity of and/or authorization to
>>>>>>>>>> use end-user SIP identity in an interdomain or intradomain context.
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> -
>>>>>>>>>> --
>>>>>>>>>> -------
>>>>>>>>>>
>>>>the sole use of the recipient(s). Any use by others is prohibited.
>>>>If you are not the intended recipient, please contact the sender and

---

From: Alex Bobotek <[email-masked]>
Date: Tue, 9 Aug 2016 02:03:53 -0700

Jon,

Thanks much for your thoughtful response to the original points.  Yes, things got somewhat sidetracked.

On the first point (signing without authentication), I do not read 6.1 as permitting "I'm signing to assert that I've authorized use of this phone number without authenticating the caller and/or completing a number delegation authority check", a use case that reflects the currently-widespread practice of authorization without authentication.  My read of section 6.1 is that it allows anonymity rather than signer-attribution with unauthenticated (non-anonymous) caller identity.  Knowing the triple of purported calling phone number that flashes on a recipient's phone, the terminating phone number and a timestamp is important in reporting/tracing/mitigating abusive calls.  [On a side note, I reread Section 11, but had trouble with the definition of "private URI" (note:  "private URI" and "private SIP URI" each occur exactly once each in the doc and could benefit from a definition or two).]   Additionally, Brian Rosen's comment on 8/4 seems to corroborate my reading of a ban on authorization without authentication in the non-anonymous case (i.e., that using someone else's phone number requires that "the entity that is assigned the TN explicitly authorizes calls placed using it's TN").

In summary, there is a high value in allowing signing/authorization in the categories and use cases Pierce outlined.  In my operational experience, it really helps to know which company to contact to get the callers kicked off a network.  And signer attribution even without caller authentication is a huge win for the public.

On the second point, thanks for pointing out that 12.1 requires servers to keep the state of recently received requests.  This is a point that I missed in my reading of the draft, and this feature as you have described it defeats most conceivable replay attacks.  My bad for missing this, but as you suggest, there may be some potential for emphasizing this point.  But there's another part of the issue -- cross method replay.  For example, it may be difficult to expect a messaging node (which handles SIP MESSAGE) and a voice-capable IMS node (handling SIP INVITE) to coordinate their anti-replay caches, allowing an attacker that observes a SIP invite for a voice call to piggyback a spam text message.  As it's common to use the same "To" address for multiple services that may be served by very different infrastructure components, it would be beneficial to allow signatures to cover more than "To", "From/PAI" and "Timestamp".   I do not see this issue as meriting significant delay of a STIR RFC if there's no quick fix.

Regards,

Alex

> From: stir [mailto:[email-masked]] On Behalf Of Peterson, Jon
> Sent: Monday, August 8, 2016 12:46 PM
> To: Gorman, Pierce A [CTO] <[email-masked]>; Paul Kyzivat
> <[email-masked]>; Dwight, Timothy M (Tim)
> <[email-masked]>; DOLLY, MARTIN C <[email-masked]>
> Richard Shockey <[email-masked]>; [email-masked]; Brian Rosen
> <[email-masked]>
> Just so I'm clear, I'm not hearing an ask here in terms of changing the text of
> rfc4474bis-10, which does allow signing PAI instead of From for precisely the
> reasons outlined in this lengthy thread. To Alex's original point about
> providing authorization without authentication, rfc4474bis has a lot of text
> about signing non-TN identifiers, including for preserving anonymity; see the
> end of section 6.1, and then the Privacy Considerations in section 11 for
> more. Those should suffice to provide this property: it will identify the
> service provider who signed without attesting an specific user identity.
>
> I also wanted to make sure we didn't drop the other ball that Alex mentioned
> at the start of this thread, which is the issue of proximate replay within the 60
> second Date window. This is addressed in Section 12.1 of rfc4474bis-10, which
> reads: "Note that per baseline [RFC3261] behavior, servers keep state of
> recently received requests, and thus if an Identity header is replayed by an
> attacker within the Date interval, verifiers can detect that it is spoofed
> because a message with an identical Date from the same source had recently
> been received." This refers to the text of
> better detailed in RFC3893 Section 10, which introduced the first version of
> the partial signature mechanism that ultimately inspired RFC4474. I'll update
> the text here so it is clearer about exactly how to detect proximate replay.
>
> Jon Peterson
> Neustar, Inc.
>
> >To: Gorman, Pierce A [CTO] <[email-masked]>; Dwight,
> Timothy
> >M
> Richard
> >> To: Gorman, Pierce A [CTO] <[email-masked]>; DOLLY,
> MARTIN
> >> C <[email-masked]>
> >>>>>>>>>>s-10%20-
> %20Authenticated%20Identity%20Management%20in%20the%20

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Aug 2016 11:44:25 -0400

On 8/9/16 5:03 AM, Alex Bobotek wrote:
> On the first point (signing without authentication), I do not read 6.1 as permitting "I'm signing to assert that I've authorized use of this phone number without authenticating the caller and/or completing a number delegation authority check",

I'm not sure I understand. Is this the assertion you are asking for?

"I (Acme Corp), having administrative authority over number NNN, certify 
that this message is "from" NNN, though I have no idea who actually 
originated this message."

This is a good thing???

If you sign the message you are taking responsibility for the assertion 
that it is from NNN. If you choose to do so without knowing who it is 
from then that is your problem. You should be legally liable. At the 
very least your reputation as a signer should be diminished as 
fraudulent calls you have signed are detected. Eventually you will be 
put on blacklists as an untrustworthy signer.

I guess we could speed the blacklisting by allowing signers to 
pre-declare that they are untrustworthy. (That seems to be what you are 
asking for.)

> a use case that reflects the currently-widespread practice of authorization without authentication.

No wonder we have a problem with spoofed calls.

	Thanks,
	Paul

> My read of section 6.1 is that it allows anonymity rather than signer-attribution with unauthenticated (non-anonymous) caller identity.  Knowing the triple of purported calling phone number that flashes on a recipient's phone, the terminating phone number and a timestamp is important in reporting/tracing/mitigating abusive calls.  [On a side note, I reread Section 11, but had trouble with the definition of "private URI" (note:  "private URI" and "private SIP URI" each occur exactly once each in the doc and could benefit from a definition or two).]   Additionally, Brian Rosen's comment on 8/4 seems to corroborate my reading of a ban on authorization without authentication in the non-anonymous case (i.e., that using someone else's phone number requires that "the entity that is assigned the TN explicitly authorizes calls placed using it's TN").
>

---

From: Alex Bobotek <[email-masked]>
Date: Tue, 9 Aug 2016 09:40:52 -0700

Paul,

The assertion I'm referring to is a bit different.  It's:

"I (Acme Corp), certify that this message originated and or gatewayed to SIP on my network, (and btw, I probably know which account/user actually originated this message and take responsibility for its origination or gatewaying)"

Is this a good thing?  Yes and no.  From a security perspective I believe we all agree that it's best to have the (possibly delegated) authority of the rightful owner of the originating phone number as well as the identity of the responsible originating service provider (typically the signer).  But this goal will be elusive; there are cases where even a well-meaning a service provider may not be able to enforce or determine whether the owner of an originating number has authorized its use.   In these cases, there is high value in knowing the identity of a signer claiming some responsibility for the call's origination.  The carriers' abuse desks and systems then know who to contact for abuse mitigation.

The con to this is that some signers may be lazy, and elect to sign while omitting or not enforcing number authority policies in cases where they could.

So IMO the right question to ask is whether the pros outweigh the cons.  IHMO, the answer is an emphatic yes.

Regards,

Alex

> Sent: Tuesday, August 9, 2016 8:44 AM
> To: Alex Bobotek <[email-masked]>; Peterson, Jon
> <[email-masked]>; Gorman, Pierce A [CTO]
> <[email-masked]>; Dwight, Timothy M (Tim)
> > On the first point (signing without authentication), I do not read 6.1
> > as permitting "I'm signing to assert that I've authorized use of this
> > phone number without authenticating the caller and/or completing a
> > number delegation authority check",
>
> If you sign the message you are taking responsibility for the assertion that it
> is from NNN. If you choose to do so without knowing who it is from then that
> is your problem. You should be legally liable. At the very least your reputation
> as a signer should be diminished as fraudulent calls you have signed are
> detected. Eventually you will be put on blacklists as an untrustworthy signer.
>
> I guess we could speed the blacklisting by allowing signers to pre-declare that
> they are untrustworthy. (That seems to be what you are asking for.)
>
> > My read of section 6.1 is that it allows anonymity rather than signer-
> attribution with unauthenticated (non-anonymous) caller identity.  Knowing
> the triple of purported calling phone number that flashes on a recipient's
> phone, the terminating phone number and a timestamp is important in
> reporting/tracing/mitigating abusive calls.  [On a side note, I reread Section
> 11, but had trouble with the definition of "private URI" (note:  "private URI"
> and "private SIP URI" each occur exactly once each in the doc and could
> benefit from a definition or two).]   Additionally, Brian Rosen's comment on
> 8/4 seems to corroborate my reading of a ban on authorization without
> authentication in the non-anonymous case (i.e., that using someone else's
> phone number requires that "the entity that is assigned the TN explicitly
> authorizes calls placed using it's TN").
> >
> > In summary, there is a high value in allowing signing/authorization in the
> categories and use cases Pierce outlined.  In my operational experience, it
> really helps to know which company to contact to get the callers kicked off a
> network.  And signer attribution even without caller authentication is a huge
> win for the public.
> >
> >
> >
> > On the second point, thanks for pointing out that 12.1 requires servers to
> keep the state of recently received requests.  This is a point that I missed in
> my reading of the draft, and this feature as you have described it defeats
> most conceivable replay attacks.  My bad for missing this, but as you suggest,
> there may be some potential for emphasizing this point.  But there's another
> part of the issue -- cross method replay.  For example, it may be difficult to
> expect a messaging node (which handles SIP MESSAGE) and a voice-capable
> IMS node (handling SIP INVITE) to coordinate their anti-replay caches,
> allowing an attacker that observes a SIP invite for a voice call to piggyback a
> spam text message.  As it's common to use the same "To" address for
> multiple services that may be served by very different infrastructure
> components, it would be beneficial to allow signatures to cover more than
> "To", "From/PAI" and "Timestamp".   I do not see this issue as meriting
> significant delay of a STIR RFC if there's no quick fix.
> >
> > Regards,
> >
> > Alex
> >
> >> Just so I'm clear, I'm not hearing an ask here in terms of changing
> >> the text of rfc4474bis-10, which does allow signing PAI instead of
> >> From for precisely the reasons outlined in this lengthy thread. To
> >> Alex's original point about providing authorization without
> >> authentication, rfc4474bis has a lot of text about signing non-TN
> >> identifiers, including for preserving anonymity; see the end of
> >> section 6.1, and then the Privacy Considerations in section 11 for
> >> mentioned at the start of this thread, which is the issue of
> >> proximate replay within the 60 second Date window. This is addressed
> >> in Section 12.1 of rfc4474bis-10, which
> >> reads: "Note that per baseline [RFC3261] behavior, servers keep state
> >> of recently received requests, and thus if an Identity header is
> >> replayed by an attacker within the Date interval, verifiers can
> >> detect that it is spoofed because a message with an identical Date
> >> from the same source had recently been received." This refers to the
> >> text of
> >> RFC3261 section 23.4.2, though more properly the Date-related
> >> behavior is better detailed in RFC3893 Section 10, which introduced
> >> the first version of the partial signature mechanism that ultimately
> >> inspired RFC4474. I'll update the text here so it is clearer about exactly
> how to detect proximate replay.
> >>
> >> Jon Peterson
> >> Neustar, Inc.
> >>
> >>> I could argue that from a cleanliness of protocol implementation,
> >>> (and if I wanted to be pedantic), I would strip PAI outbound unless
> >>> required otherwise.  But the point is moot.  As I mentioned in the
> >>> earlier e-mail, that is not our practice and I'm not requesting it to be so.
> >>>
> >>> Pierce
> >>>
> >>>
> >>>> I agree that passing P-Asserted-Identity between trusted networks
> >>>> is appropriate (and the converse is true as well).  Part of my
> >>>> issue is I have been conditioned from the very earliest
> >>>> implementation of Sprint's VoIP network that other carriers' IP
> >>>> networks are inherently untrusted.  I've been browsing TS 29.165
> >>>> and even there I find language that implies trust is established by
> >>>> agreement, not by standard.  (Even roaming implies agreement.)
> >>>
> >>> I understand why *some* stuff needs to be removed when forwarding
> to
> >> an
> >>> untrusted party. For instance, if the call has requested privacy,
> >>> then P-A-ID needs to be removed.
> >>>
> >>> But when privacy is not a concern, trust is really more of a concern
> >>> on the ingress side, not egress. If I don't trust you then I won't
> >>> trust a P-A-ID you sent to me, and so *I* will remove it. But if I
> >>> trust you, but you don't trust me, then what is the downside for
> >>> passing along the P-A-ID?
> >>>
> >>>     Thanks,
> >>>     Paul
> >>>
> >>>> generally send PAI today.  I've also made note that where standards
> >>>> and
> >> ICA
> >>>> P-Asserted-Identity (PAI) be exchanged at a trusted interconnect.
> >>>> It also states that PAI is mandatory at a roaming NNI.
> >>>>
> >>>> Tim
> >>>>
> >>>>
> >>>> originating side" Note 4 it states, " It is assumed that the IBCF
> >>>> is responsible for stripping the P-Asserted-Identity from the SIP
> >>>> header when interworking with untrusted networks."
> >>>>
> >>>> Your remark is consistent with Note 4, but only if we agree that,
> >>>> for instance, the AT&T network and the Sprint network are "trusted
> >>>> What it really comes down to is that PAI is left in signaling
> >>>> either through formal specification as a part of an inter-carrier
> >>>> PAI is not stripped at the network boundary between trusted
> >>>> networks 3GPP TS 29.195 Atis specs GSMA Atis sip forum task force
> >>>> ITU And the list goes on
> >>>>
> >>>> Martin C Dolly
> >>>>> Which header the carrier chooses to display is moot if the header
> >>>>> is stripped between carriers as per at least one standard.  I
> >>>>> think Paul Rosbotham's observation we're likely to encounter "some
> >>>>> interesting interworking challenges" was perhaps the
> understatement of the year.
> >>>>>
> >>>>> Pierce
> >>>>>
> >>>>> signaling regime between the carrier and the user device (e.g.
> >>>>> black
> >> phone).
> >>>>>
> >>>>>    Thanks,
> >>>>>    Paul
> >>>>>
> >>>>>> entities" and therefore some specifications (e.g., 3GPP TS
> >>>>>> 24.607) assume P-Asserted-Identity is stripped by border
> >>>>>> controller functions and is not to be used in inter-carrier
> >>>>>> inter-connection (although it commonly shows up anyway).  My
> opinion is the "From"
> >>>>>> <[email-masked] on behalf of
> [email-masked]>
> >> wrote:
> >>>>>>
> >>>>>> identifies the line, the other (we term Presentation Number,
> >>>>>> carried in From) is used for display purposes.
> >>>>>>
> >>>>>> - the number sent for display purposes belongs to the customer.
> >>>>>> For blue-chip customers, I can allow them to send their
> >>>>>> Presentation Numbers into the network, and can't readily check at
> >>>>>> a network level that they're theirs (I do have contractual
> >>>>>> safeguards).  The number may have been allocated by me, or could
> >>>>>> be allocated by a third party provider.  If it's a call-centre
> >>>>>> they'll be making outbound calls for lots of different customers
> >>>>>> which will change on day-by-day
> >> basis.
> >>>>>> it's not, it's the corporate customer or their subcontractor
> >>>>>> using the number that's been assigned (so in internet terms
> >>>>>> delegated) to them via a chain of trust from the regulator.
> >>>>>>
> >>>>>> terminating end it can  be checked (or indeed somewhere en-route
> >>>>>> if that's the business model).
> >>>>>> I can and would sign for customers on my mobile business since
> >>>>>> I'm driving what number is presented, but that's by-the-by
> >>>>>> because they aren't the ones who generate millions of nuisance
> >>>>>> calls.  If the signing only occurs at the originating carrier
> >>>>>> level for corporate/call-centre customers that's no use because
> >>>>>> I'm not in a position to do that for these type of
> >>>>>> customers...and the whole system becomes a waste of time. I'd
> >>>>>> also highlight there are many more of my large customers that I'd
> >>>>>> trust more than a far end originating carrier that could be
> >>>>>> anywhere in the world (though we have no shortage of small
> >>>>>>> delegation, so if you want to call it delegation, go ahead, but
> >>>>>>> I prefer to call it authorized spoofing.
> >>>>>>
> >>>>>> chooses. In the case of the mobile, the device then becomes a
> >>>>>> two-line
> >> phone.
> >>>>>>
> >>>>>>    Thanks,
> >>>>>>    Paul
> >>>>>>
> >>>>>>> Brian
> >>>>>>>
> >>>>>>>> On Aug 4, 2016, at 5:51 PM, Paul Kyzivat
> >>>>>>>> <[email-masked]>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> calling  from his mobile, but sending the TN of his office
> >>>>>>>>> phone as calling party.
> >>>>>>>>> signs with his office phone credential that authorizes his
> >>>>>>>>> mobile to send calls from his office number.  He is spoofing
> >>>>>>>>> (because the call is coming from his mobile's TN but claims to
> >>>>>>>>> be from his office), but it's authorized spoofing.  The doc
> >>>>>>>>> could give the credential to his mobile SP if they sign on his
> behalf.
> >>>>>>>>
> >>>>>>>> his landline number, he should be able to install that in
> >>>>>>>> whatever devices he wants - his landline UA, his mobile phone,
> >>>>>>>> etc. It is still delegated from his landline carrier, even when
> >>>>>>>> used with calls via his mobile carrier.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Paul
> >>>>>>>>
> >>>>>>>>>> On Aug 4, 2016, at 5:37 PM, Paul Kyzivat
> >>>>>>>>>> <[email-masked] <mailto:[email-masked]>>
> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I don't think it matters who the delegator or delegatee are
> >>>>>>>>>>> as long as the delegator is willing to take the heat for
> >>>>>>>>>>> delegating to someone who sends a lot of bad calls.  They
> >>>>>>>>>>> can pass the buck ("I delegated the TN to him, and now I'm
> >>>>>>>>>>> not responsible"), but only if the SP knows who they
> >>>>>>>>>>> delegated to, so authorities can follow the delegation path.
> >>>>>>>>>>> There are plenty of certificated carriers who are willing to
> >>>>>>>>>>> not care who they delegate to.  The fact that there are some
> >>>>>>>>>>> who do doesn't change much.
> >>>>>>>>>>> It's perfectly reasonable for a carrier to be able to sign
> >>>>>>>>>>> for any calls placed on its network on any number it has
> >>>>>>>>>>> been delegated.
> >>>>>>>>>>> to  the delegatee.  But, that only works if they know who
> >>>>>>>>>>> they are delegating to.
> >>>>>>>>>>>
> >>>>>>>>>>> country, and we can build a chain of trust from that
> >>>>>>>>>>> delegation path.  If you propose to alter that model, then
> >>>>>>>>>>> we get into
> >>>>>>>>>>> Our model is that you know who you delegate to, and once
> you
> >>>>>>>>>>> do that delegation, it's their problem.
> >>>>>>>>>>> That's pretty appealing I think, even if it's a change in
> >>>>>>>>>>> some business practices.
> >>>>>>>>>>>
> >>>>>>>>>>>> Inherent variable trustworthiness of a calling number was
> >>>>>>>>>>>> my reason for suggesting a way to qualify the signature to
> >>>>>>>>>>>> coming from a device assigned a single number, or from
> >>>>>>>>>>>> "trunk group" which could originate calls using multiple
> >>>>>>>>>>>> numbers, and can qualify to some degree the
> trustworthiness
> >>>>>>>>>>>> of number authenticity accordingly.
> >>>>>>>>>>>>
> >>>>>>>>>>>> My suggestion was qualifying calling number authenticity
> >>>>>>>>>>>> into categories of carrier-signed (or not), and
> >>>>>>>>>>>> unauthenticated, semi-authenticated, and
> >>>>>>>>>>>> most-authenticated.  There can be
> >> more
> >>>>>>>>>>>> granularity, but it implies additional operational
> >>>>>>>>>>>> complexity (both for the carriers and the consumers) and I
> >>>>>>>>>>>> assume diminishes value.
> >>>>>>>>>>>>
> >>>>>>>>>>>> trustworthiness assessment and partially because carriers
> >>>>>>>>>>>> are a regulated point of forensic inquiry for CALEA and fraud.
> >>>>>>>>>>>> authenticate their device and have a high degree of
> >>>>>>>>>>>> confidence of the authenticity of the calling number.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Conversely, I think billions of per-TN certs will work
> >>>>>>>>>>>> well, if the calling party has to sign a call with a per-TN
> >>>>>>>>>>>> cert provided by the called party.  No called party cert to
> include?
> >>>>>>>>>>>> The notion of credentials that are traceable to a
> >>>>>>>>>>>> delegation of a TN is a mechanism that is part of the
> >>>>>>>>>>>> design of stir, and the design allows delegation of one TN
> >>>>>>>>>>>> (to one device, although a device like a PBX would have
> >>>>>>>>>>>> more than one TN per "device", and something like a dual
> >>>>>>>>>>>> NAM phone could have
> >> more
> >>>>>>>>>>>> mobile phone may also have a credential for, say, a TN that
> >>>>>>>>>>>> is delegated to a landline, to cover the example case of a
> >>>>>>>>>>>> doctor placing a call on his mobile, but getting his office
> >>>>>>>>>>>> number to show up as the calling party.  Use of such
> mechanisms is policy.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Brian
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> discussion.  Regardless, I do appreciate your explanation.
> >>>>>>>>>>>> I would like to continue the discussion, but I'm pretty
> >>>>>>>>>>>> sure this isn't the right forum.
> >>>>>>>>>>>>
> >>>>>>>>>>>>  Pierce
> >>>>>>>>>>>>
> >>>>>>>>>>>> phones and  any other devices that can be programmed to
> do
> >> so.
> >>>>>>>>>>>> any call,  but the validity of the credential would make
> >>>>>>>>>>>> such a signature  fail the checking.
> >>>>>>>>>>>>
> >>>>>>>>>>>>  Getting service providers to sign on behalf of devices is
> >>>>>>>>>>>> a reasonable way to deploy quickly, but I expect many SPs
> >>>>>>>>>>>> will want  to get out of the liability of signing on behalf
> >>>>>>>>>>>> of their customers.  If they can push of that
> >>>>>>>>>>>> responsibility to their customer, only being responsible
> >>>>>>>>>>>> for getting the customer an appropriate credential when
> >>>>>>>>>>>> they assign TNs, then I would expect  them to want to do
> >>>>>>>>>>>> so.  That means the devices have to be able to  sign, but I
> >>>>>>>>>>>> understand many of the PBX vendors think that's  something
> >>>>>>>>>>>> they could provide in a future release.
> >>>>>>>>>>>>
> >>>>>>>>>>>>  Brian
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> less than
> >>>>>>>>>>>> <file:///C:/Users/ab3778/Documents/IETF/draft-ietf-stir-rfc
> >>>>>>>>>>>> 447
> >>>>>>>>>>>> 4bi
> >>>>>>>>>>>> s-10%20-
> >>>>>>>>>>>> Ses
> >>>>>>>>>>>>                 depends on authenticating and/or
> >>>>>>>>>>>> authorizing the source of communications as it is
> >>>>>>>>>>>>
> >>>>>> This e-mail may contain Sprint proprietary information intended
> >>>>>> for the sole use of the recipient(s). Any use by others is prohibited.
> >>>>>> If you are not the intended recipient, please contact the sender
> >>>>>> and delete all copies of the message.
> >>>>>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 9 Aug 2016 17:04:36 +0000

" If you sign the message you are taking responsibility for the assertion that it is from NNN. If you choose to do so without knowing who it is from then that is your problem."

Paul,

Following this standard of liability, every ISP should be forced to sign IP packets and be liable for hacking attempts which originate on their IP networks.

Just as reverse unicast path forwarding is not often (ever?) used in the Internet backbone or ISP networks to ensure IP packets don't come from networks they can't have originated from, neither do all telephone networks "check" each originating telephone number to determine whether they should have been able to originate from a particular carrier or enterprise and for the same reasons - it is difficult, imperfect, and expensive.  Just as it is with the Internet backbone, it's actually reasonably challenging just delivering the calls (or IP packets) to the number that it is addressed to, without also having to also worry about where it supposedly came from.

I'm telling you we can differentiate the trustworthy-ness (like Stephen Colbert's "truth-iness") of calls.  We can tell if a call originated from a subscriber using a device which has to authenticate to the network before it's permitted to place calls (except manual roaming and some E911 calls).  And we can tell if a call originated (or was subjected to mid-call 3rd party call control from an enterprise or mobile virtual network operator partner for example) and is therefore not as trustworthy as the directly-connected and authenticated mobile subscriber (for example).  We can pass that relative trustworthiness information along in signaling and it can be used to usefully differentiate treatment, ultimately, by the consumer.

What you want is that the calling number is always, universally, only ever trustworthy.  My opinion is that is unrealistic and unreasonable.

Pierce

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: August 09, 2016 10:44 AM
To: Alex Bobotek <[email-masked]>; Peterson, Jon <[email-masked]>; Gorman, Pierce A [CTO] <[email-masked]>; Dwight, Timothy M (Tim) <[email-masked]>; DOLLY, MARTIN C <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Richard Shockey <[email-masked]>; [email-masked]; Brian Rosen <[email-masked]>
Subject: Re: [stir] STIR 4474bis-10 comments

"I (Acme Corp), having administrative authority over number NNN, certify that this message is "from" NNN, though I have no idea who actually originated this message."

This is a good thing???

If you sign the message you are taking responsibility for the assertion that it is from NNN. If you choose to do so without knowing who it is from then that is your problem. You should be legally liable. At the very least your reputation as a signer should be diminished as fraudulent calls you have signed are detected. Eventually you will be put on blacklists as an untrustworthy signer.

I guess we could speed the blacklisting by allowing signers to pre-declare that they are untrustworthy. (That seems to be what you are asking for.)

Thanks,
Paul

>> more. Those should suffice to provide this property: it will identify the service provider who signed without attesting an specific user identity.
>>
>> inspired RFC4474. I'll update the text here so it is clearer about exactly how to detect proximate replay.
>>
>> Jon Peterson
>> Neustar, Inc.
>>
>>>>> interesting interworking challenges" was perhaps the understatement of the year.
>>>>>
>>>>> Pierce
>>>>>
>>>>>> inter-connection (although it commonly shows up anyway).  My opinion is the "From"
>>>>>>>>> could give the credential to his mobile SP if they sign on his behalf.
>>>>>>>>
>>>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>>
>>>>>>>>>>>> numbers, and can qualify to some degree the trustworthiness
>>>>>>>>>>>> cert provided by the called party.  No called party cert to include?
>>>>>>>>>>>> number to show up as the calling party.  Use of such mechanisms is policy.
>>>>>>>>>>>>
>>>>>>>>>>>> Brian
>>>>>>>>>>>>
>>>>>>>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Aug 2016 13:08:42 -0400

> "I (Acme Corp), certify that this message originated and or gatewayed to SIP on my network, (and btw, I probably know which account/user actually originated this message and take responsibility for…

The weasel word here is "probably". That needs considerably more definition.

Is it your intent that there be multiple "levels" of confidence, with 
the signer choosing which one it is willing to use?

If so, then careful consideration is required about how useful that is 
to the recipient. Is there sufficient definition about the differences 
so that the recipient can make a meaningful distinction about how to 
handle the call?

IMO it would be better to simply sign or not, with the signer taking 
responsibility. If they are too lax about verification then they will be 
responsible for more penalties when bad things happen.

This is similar to the issue of liability for fraudulent credit card 
charges. Retailers sometimes accept a card without a signature, because 
it makes customers happy and speeds transactions. But in doing so they 
accept the responsibility for the charge if the transaction turns out to 
be fraudulent.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Aug 2016 13:10:30 -0400

See the reply I just sent to Alex.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 9 Aug 2016 17:36:45 +0000

I did.  Similar is a weasel word too isn't it?

" This is similar to the issue of liability for fraudulent credit card 
charges. Retailers sometimes accept a card without a signature, because 
it makes customers happy and speeds transactions. But in doing so they 
accept the responsibility for the charge if the transaction turns out to 
be fraudulent."

It's not at all the same.  The retailer is liable for eating the cost of that which they thought they sold.  Instead, applying the logic of making the operator liable for calling number verification is the same as asking the retailer to be liable for the fraud committed by the criminal.

Let's not forget that a criminal can get a phone that is authenticated to the network and whose calling numbers is signed, either by the operator, or by the SIP stack on the phone, and still commit crime.

If you want the operators to eat the cost of transporting and processing the phone call where the originating number was fraudulently provided, I'm pretty sure it will fail in court, but it probably wouldn't be very offensive to operators.

What I think you're asking for is operators to be police, both detectives and traffic cops, and to be liable (sounds eerily like other current events). 

Pierce

---

From: Brian Rosen <[email-masked]>
Date: Tue, 9 Aug 2016 13:44:03 -0400

To get rid of the scourge of robocalling, service providers will have to check to make sure the calling party number is delegated to the subscriber, or delegate them credentials so they can sign.
That is not current practice, but current practice will need to change.

Where you aren’t doing it because, well, just because, you will need to.  That’s the actual change,  Signing is the mechanics, but the change is checking. 
Where you are already just asserting PAI, without regard to what is in From, you are good.  It’s when you blindly accept From  and copy to PAI that you have a problem,  If you are accepting PAI, then whomever is asserting it needs to sign.

Where there is a reason, like the call center, an extra delegation will be required, and probably you will be looking to the call center to sign calls that are coming over your network, but are being placed by the call center on behalf of someone not on your network.

Where you are a transit network, you will need to push signing responsibility to your transit customer.

It would be good to be able to push the problem to your subscriber/customer, but that won’t work for a while unless they are a service provider (where you need to make them responsible for signing, because you don’t know their customers).  The bigger, and more complex the subscriber’s connection to your network, the more you are incentivised to push the problem down.  Things that just work now (like a multi-location enterprise least cost routing outbound calls through several networks) may no longer work unless they do the signing.  Most of the larger PBX vendors know about stir and are planning to support it.  “When" is always the issue, and the more we make the consequences of stir deployment known to service providers, enterprises and regulators, the quicker we’ll get the vendors to respond.

Brian

> On Aug 9, 2016, at 1:04 PM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 9 Aug 2016 17:56:55 +0000

I actually don't think STIR is going to "get rid of the scourge of robocalling".  And to be more specific, we mean robocalling for nefarious purposes (if you can accept robocall for political purposes as non-nefarious).

I assume that cloud-based on-line communications services will make it trivial to get and commit robo-calling for nefarious purposes with authenticated numbers, and that it will be difficult to impossible to track down the perpetrators.  We're playing wack-a-mole here.

Regardless, I also agree with most of what you said.

All Paul and I have been debating is whether or not all signed numbers can have equivalent trustworthiness (and they can't) and whether the network operator should be liable for a customer's crimes (and they shouldn't).

Pierce

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: August 09, 2016 12:44 PM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; Alex Bobotek <[email-masked]>; Peterson, Jon <[email-masked]>; Dwight, Timothy M (Tim) <[email-masked]>; DOLLY, MARTIN C <[email-masked]>; Rosbotham, Paul, Vodafone UK <[email-masked]>; Richard Shockey <[email-masked]>; [email-masked]
Subject: Re: [stir] STIR 4474bis-10 comments

Brian

---

From: Brian Rosen <[email-masked]>
Date: Tue, 9 Aug 2016 14:05:28 -0400

I do think we will need to extend stir to cover WebRTC and that solution will “work” for other cloud based calling services using telephone numbers as identifiers.  stir as we are defining it will work for any origination mechanism that terminates on a telephony device (PSTN/mobile/VoIP) using a telephone number as the address.  Wherever the gateway to the telephone network exists, it will have to sign, or the carrier serving it will have to sign, and thus check the TN.

To get more complex, and cover the case of an SS7 link in the path will need some more work (out of band), that can’t start until we finish our base effort.

Brian

> On Aug 9, 2016, at 1:56 PM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 9 Aug 2016 18:50:44 +0000

If you sign, the call traces back to you and thereby you can be punished by the FTC/FCC

-----Original Message-----
From: Alex Bobotek [mailto:[email-masked]] 
Sent: Tuesday, August 09, 2016 12:41 PM
To: Paul Kyzivat <[email-masked]>; Peterson, Jon <[email-masked]>; Gorman, Pierce A [CTO] <[email-masked]>; Dwight, Timothy M (Tim) <[email-masked]>; DOLLY, MARTIN C <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Richard Shockey <[email-masked]>; [email-masked]; Brian Rosen <[email-masked]>
Subject: RE: [stir] STIR 4474bis-10 comments

Paul,

Regards,

Alex

---

From: Brian Rosen <[email-masked]>
Date: Tue, 9 Aug 2016 14:56:14 -0400

Yup, the ultimate motivator to push the problem upstream to your customer.

But, you have to KNOW your customer.  If the FTC/FCC or equivalent in other jurisdictions can’t follow the cert trail back, then you are left holding the bag.

So it probably won’t work to push off signing authority to a subscriber you only know by an email address and a pre-paid debit card.

Remember that anonymity is allowed, but it has to be labeled as anonymous.  You can’t spoof and claim it’s because you want to remain anonymous. 

Brian

> On Aug 9, 2016, at 2:50 PM, DOLLY, MARTIN C <[email-masked]> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Aug 2016 15:29:04 -0400

> I did.  Similar is a weasel word too isn't it?

Yes :-)

> What I think you're asking for is operators to be police, both detectives and traffic cops, and to be liable (sounds eerily like other current events).

I agree it isn't comparable, and that it is unreasonable for the 
operators to be liable for the bad deeds of their customers.

But there needs to be *some* negative consequence for failing to perform 
due diligence when signing. Exactly what that consequence is is out of 
our hands, but I hope we can count on there being one.

Getting blacklisted as an untrusted signer is one possibility.

	Thanks,
	Paul

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 10 Aug 2016 15:10:50 +0000

Be careful.

I think you will find it is mandatory to be supported, not mandatory to be carried.

It is perfectly applicable to reach the edge of the trust domain and not provide it between two networks.

At least from the 3GPP specifications, the trust domain for PAI, comes back down to RFC 3325, so in that respect there is no such thing as implicit trust. While there might be emphasis on supporting trust between network operators, if you cannot trust the sender to provide your own quality of checks, and you cannot trust the receiver to apply your own quality of privacy, then it should be ignored on receipt, and not be sent.

Keith

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Dwight, Timothy M (Tim)
Sent: 08 August 2016 16:47
To: Gorman, Pierce A [CTO]; DOLLY, MARTIN C
Cc: Rosbotham, Paul, Vodafone UK; Brian Rosen; [email-masked]; Paul Kyzivat; Richard Shockey
Subject: Re: [stir] STIR 4474bis-10 comments

Pierce,

Tim

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [CTO]
Sent: Monday, August 08, 2016 8:52 AM
To: DOLLY, MARTIN C
Cc: Rosbotham, Paul, Vodafone UK; Richard Shockey; Paul Kyzivat; [email-masked]; Brian Rosen
Subject: [E] Re: [stir] STIR 4474bis-10 comments

Martin,

Pierce

-----Original Message-----
From: DOLLY, MARTIN C [mailto:[email-masked]]
Sent: August 05, 2016 12:55 PM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]; Paul Kyzivat <[email-masked]>; Richard Shockey <[email-masked]>
Subject: Re: [stir] STIR 4474bis-10 comments

Martin C Dolly

---

From: Brian Rosen <[email-masked]>
Date: Wed, 10 Aug 2016 11:24:19 -0400

Remember that although we are discussing signature based on PAI in this part of this thread, the From really should have the same TN.

If PAI is stripped, but Identity is not, the end device could use the information in From to validate.  If the numbers were the same, the check would work, because the canonicalization of the TN is the same.

Where the From and PAI differ, this won’t work of course.

Brian

> On Aug 10, 2016, at 11:10 AM, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
> 
> Be careful.
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 10 Aug 2016 17:11:17 +0000

"...there needs to be *some* negative consequence for failing to perform due diligence when signing. Exactly what that consequence is is out of  our hands, but I hope we can count on there being one."

The definition of "due diligence" is the key point.  For better or worse, most calls do not, and some calls cannot have their calling numbers verified.  One (albeit minor) example is manual roaming.

We're talking here about a fundamental change in logic (and to some degree capacity/peformance) in most carrier switches and SIP application servers, and it's not simple and straight-forward, and it's a large-scale issue because were talking about many thousands of calls per second during the busy hours.  "A good plan today is better than a perfect plan tomorrow."  - G.S. Patton

Placing bad actors on a deny list (and/or other palliative actions) is more possible if/when we get to some critical mass of signing, even with some quantity of lower quality number vetting.  I believe it is possible to get useful and therefore valuable authenticity information without having to have overly rigorous or burdensome "due diligence".  You're sending me a call you signed and you didn't provide thorough vetting?  OK, just let me know that you did that and I can take actions accordingly.  Perhaps I'll record the fact and keep score of the consequences.

Given all-VoIP networks signaling with SIP, and the great majority of calls (which are benign) are signed with high-quality authenticity (which will be the case), then the remainder of calls and their sources will be easier to monitor/manage even though they could have lower quality authenticity.  And, having the originating carrier sign the call provides a mechanism for forensic investigation and enforcement (against perpetrators and their associates).  

Pierce

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: August 09, 2016 2:29 PM
To: Gorman, Pierce A [CTO] <[email-masked]>; Alex Bobotek <[email-masked]>; Peterson, Jon <[email-masked]>; Dwight, Timothy M (Tim) <[email-masked]>; DOLLY, MARTIN C <[email-masked]>
Cc: Rosbotham, Paul, Vodafone UK <[email-masked]>; Richard Shockey <[email-masked]>; [email-masked]; Brian Rosen <[email-masked]>
Subject: Re: [stir] STIR 4474bis-10 comments

Yes :-)

	Thanks,
	Paul