Re: [stir] STIR 4474bis-10 comments

["Gorman, Pierce A [CTO]" <[e-mail]>]

"...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:[e-mail]] 
Sent: August 09, 2016 2:29 PM
To: Gorman, Pierce A [CTO] <[e-mail]>; Alex Bobotek <[e-mail]>; Peterson, Jon <[e-mail]>; Dwight, Timothy M (Tim) <[e-mail]>; DOLLY, MARTIN C <[e-mail]>
Cc: Rosbotham, Paul, Vodafone UK <[e-mail]>; Richard Shockey <[e-mail]>; [e-mail]; Brian Rosen <[e-mail]>
Subject: Re: [stir] STIR 4474bis-10 comments

On 8/9/16 1:36 PM, Gorman, Pierce A [CTO] wrote:
> I did.  Similar is a weasel word too isn't it?

Yes :-)

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

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

> Pierce
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: August 09, 2016 12:11 PM
> To: Gorman, Pierce A [CTO] <[e-mail]>; Alex Bobotek <[e-mail]>; Peterson, Jon <[e-mail]>; Dwight, Timothy M (Tim) <[e-mail]>; DOLLY, MARTIN C <[e-mail]>
> Cc: Rosbotham, Paul, Vodafone UK <[e-mail]>; Richard Shockey <[e-mail]>; [e-mail]; Brian Rosen <[e-mail]>
> Subject: Re: [stir] STIR 4474bis-10 comments
>
> See the reply I just sent to Alex.
>
> On 8/9/16 1:04 PM, Gorman, Pierce A [CTO] wrote:
>> " 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:[e-mail]]
>> Sent: August 09, 2016 10:44 AM
>> To: Alex Bobotek <[e-mail]>; Peterson, Jon <[e-mail]>; Gorman, Pierce A [CTO] <[e-mail]>; Dwight, Timothy M (Tim) <[e-mail]>; DOLLY, MARTIN C <[e-mail]>
>> Cc: Rosbotham, Paul, Vodafone UK <[e-mail]>; Richard Shockey <[e-mail]>; [e-mail]; Brian Rosen <[e-mail]>
>> Subject: Re: [stir] STIR 4474bis-10 comments
>>
>> On 8/9/16 5:03 AM, Alex Bobotek wrote:
>>> 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",
>>
>> 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").
>>>
>>> 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
>>>
>>>> -----Original Message-----
>>>> From: stir [mailto:[e-mail]] On Behalf Of Peterson, Jon
>>>> Sent: Monday, August 8, 2016 12:46 PM
>>>> To: Gorman, Pierce A [CTO] <[e-mail]>; Paul Kyzivat
>>>> <[e-mail]>; Dwight, Timothy M (Tim)
>>>> <[e-mail]>; DOLLY, MARTIN C <[e-mail]>
>>>> Cc: Rosbotham, Paul, Vodafone UK <[e-mail]>;
>>>> Richard Shockey <[e-mail]>; [e-mail]; Brian Rosen
>>>> <[e-mail]>
>>>> 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]"
>>>> <[e-mail] on behalf of [e-mail]> 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
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Paul Kyzivat [mailto:[e-mail]]
>>>>> Sent: August 08, 2016 12:03 PM
>>>>> To: Gorman, Pierce A [CTO] <[e-mail]>; Dwight,
>>>> Timothy
>>>>> M
>>>>> (Tim) <[e-mail]>; DOLLY, MARTIN C
>>>> <[e-mail]>
>>>>> Cc: Rosbotham, Paul, Vodafone UK <[e-mail]>;
>>>> Richard
>>>>> Shockey <[e-mail]>; [e-mail]; Brian Rosen
>>>>> <[e-mail]>
>>>>> Subject: Re: [stir] STIR 4474bis-10 comments
>>>>>
>>>>> On 8/8/16 12:11 PM, Gorman, Pierce A [CTO] wrote:
>>>>>> 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.)
>>>>>
>>>>> 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
>>>>>
>>>>>> 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:[e-mail]]
>>>>>> Sent: August 08, 2016 10:47 AM
>>>>>> To: Gorman, Pierce A [CTO] <[e-mail]>; DOLLY,
>>>> MARTIN
>>>>>> C <[e-mail]>
>>>>>> Cc: Rosbotham, Paul, Vodafone UK <[e-mail]>;
>>>>>> Richard Shockey <[e-mail]>; Paul Kyzivat
>>>>>> <[e-mail]>; [e-mail]; Brian Rosen
>>>>>> <[e-mail]>
>>>>>> Subject: RE: [stir] STIR 4474bis-10 comments
>>>>>>
>>>>>> 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:[e-mail]] 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;
>>>>>> [e-mail]; Brian Rosen
>>>>>> Subject: [E] Re: [stir] STIR 4474bis-10 comments
>>>>>>
>>>>>> 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:[e-mail]]
>>>>>> Sent: August 05, 2016 12:55 PM
>>>>>> To: Gorman, Pierce A [CTO] <[e-mail]>
>>>>>> Cc: Rosbotham, Paul, Vodafone UK <[e-mail]>;
>>>> Brian
>>>>>> Rosen <[e-mail]>; [e-mail]; Paul Kyzivat
>>>>>> <[e-mail]>; Richard Shockey <[e-mail]>
>>>>>> 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
>>>>>> Lead Member of Technical Staff
>>>>>> Core & Government/Regulatory Standards AT&T
>>>>>> Cell: 609-903-3360
>>>>>> Email: [e-mail]
>>>>>>
>>>>>>> On Aug 5, 2016, at 1:04 PM, Gorman, Pierce A [CTO]
>>>>>>> <[e-mail]> wrote:
>>>>>>>
>>>>>>> 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:[e-mail]]
>>>>>>> Sent: August 05, 2016 11:58 AM
>>>>>>> To: Gorman, Pierce A [CTO] <[e-mail]>; Richard
>>>>>>> Shockey <[e-mail]>; Rosbotham, Paul, Vodafone UK
>>>>>>> <[e-mail]>; Brian Rosen <[e-mail]>
>>>>>>> Cc: [e-mail]
>>>>>>> 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:
>>>>>>>> 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:[e-mail]]
>>>>>>>> Sent: August 05, 2016 9:37 AM
>>>>>>>> To: Rosbotham, Paul, Vodafone UK
>>>> <[e-mail]>;
>>>>>>>> Paul Kyzivat <[e-mail]>; Brian Rosen
>>>>>>>> <[e-mail]>
>>>>>>>> Cc: [e-mail]
>>>>>>>> Subject: Re: [stir] STIR 4474bis-10 comments
>>>>>>>>
>>>>>>>>
>>>>>>>> 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"
>>>>>>>> <[e-mail] on behalf of [e-mail]>
>>>> wrote:
>>>>>>>>
>>>>>>>>    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:[e-mail]] On Behalf Of Paul Kyzivat
>>>>>>>>    Sent: 04 August 2016 23:12
>>>>>>>>    To: Brian Rosen
>>>>>>>>    Cc: [e-mail]
>>>>>>>>    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.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>> On Aug 4, 2016, at 5:51 PM, Paul Kyzivat
>>>>>>>>>> <[e-mail]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> +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]
>>>>>>>>>>>>>> <[e-mail]
>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *From:* Brian Rosen [mailto:[e-mail]]
>>>>>>>>>>>>>> *Sent:* August 04, 2016 2:03 PM
>>>>>>>>>>>>>> *To:* Gorman, Pierce A [CTO] <[e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>> *Cc:* Alex Bobotek <[e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>;
>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>>>>>>>> *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]
>>>>>>>>>>>>>> <[e-mail]
>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>> 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:[e-mail]]
>>>>>>>>>>>>>>  *Sent:* August 04, 2016 1:34 PM
>>>>>>>>>>>>>>  *To:* Gorman, Pierce A [CTO] <[e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>>  *Cc:* Alex Bobotek <[e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>;
>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>>>>>>>>  *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]
>>>>>>>>>>>>>>      <[e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>>      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:[e-mail]]
>>>>>>>>>>>>>>      *Sent:* August 04, 2016 12:24 PM
>>>>>>>>>>>>>>      *To:* Gorman, Pierce A [CTO] <[e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>      <mailto:[e-mail]>>
>>>>>>>>>>>>>>      *Cc:* Alex Bobotek <[e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>      <mailto:[e-mail]>>; [e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>>>>>>>>      *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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      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]
>>>>>>>>>>>>>>          <[e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>          <mailto:[e-mail]>> 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).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          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:[e-mail]]
>>>>>>>>>>>>>>          *Sent:* August 04, 2016 9:02 AM
>>>>>>>>>>>>>>          *To:* Alex Bobotek <[e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>          <mailto:[e-mail]>>
>>>>>>>>>>>>>>          *Cc:* [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>          *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
>>>>>>>>>>>>>>              <[e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>              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-rfc
>>>>>>>>>>>>>> 447
>>>>>>>>>>>>>> 4bi
>>>>>>>>>>>>>> s-10%20-
>>>> %20Authenticated%20Identity%20Management%20in%20the%20
>>>>>>>>>>>>>> Ses sion%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*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>> _______________________________________________
>>>>>>>>>>>>>>              stir mailing list
>>>>>>>>>>>>>>              [e-mail]
>>>>>>>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>>>>>>>>              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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> stir mailing list
>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> stir mailing list
>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> stir mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>>>
>>>>>>>>    _______________________________________________
>>>>>>>>    stir mailing list
>>>>>>>>    [e-mail]
>>>>>>>>    https://www.ietf.org/mailman/listinfo/stir
>>>>>>>>
>>>>>>>>    _______________________________________________
>>>>>>>>    stir mailing list
>>>>>>>>    [e-mail]
>>>>>>>>    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.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> stir mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> stir mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> stir mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>
>>>>
>>>> _______________________________________________
>>>> stir mailing list
>>>> [e-mail]
>>>> 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.
>>
>
>