Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 9 Sep 2016 17:10:45 +0000

The only normative RECOMMEND in Section 8 is for cases "where local policy canonicalizes the identity into a form different form how it appears in the From header field." That doesn't have anything to do with multiple identities. The text in the previous sentence notes that it is talking about a case where "the canonical identity derives from the P-Asserted-Identity field rather than the From header field," not a case where identities based on both appear in different Identity headers.

If P-Asserted-Identity is present, surely that's where you should be looking for identity information. As I've argued several times in the past, this is no more or less ambiguous than the practical use of P-Asserted-Identity in the field today: nothing about the request tells you "use PAI instead of From" other than the presence of PAI. Because of all the RFC3324 trust domain stuff that Mark Watson talked us into back in the day, it's hard to say anything more than that it's a matter of local policy, as nothing about the protocol tells you whether or not you are in an RFC3324 trust domain. Thus far, I gather this hasn't impeded the adoption of PAI. I did ask the WG in Berlin if we should include some more explicit indicator that would tell you that an Identity header came from PAI rather than From, and the consensus was not to.

We are largely punting on why you might have multiple Identity headers present in the same request: this is included for forward compatibility. The most likely use cases are ones where extensions will differentiate the Identity headers. The recommendation to include "canon" here just enables some potential implementation optimizations (e.g. Verifier canonicalizes the identity in PAI, then compares to value in "canon" to save cycles before computing the identity string and checking for breakage).

Jon Peterson
Neustar, Inc.

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 9, 2016 at 4:32 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Hi,

Section 8 of draft-4474bis says (or, that’s at least my reading) that, if the SIP request contains multiple identities (e.g. if the request in addition to the From header field contains one or more P-Asserted-Identity header fields), it is RECOMMENDED to include “canon”, so that the verifier knows which identity to verify.

Why is this only RECOMMENDED? If there are more than one identity, shouldn’t it be a MUST? I don’t think we want the verifier to try all identities, and see which one (if any) works, do we?

Now, the text DOES talk about “local policy” when it comes to choosing between From and PAI for deriving the identity, so perhaps we could say “MUST, unless local policy defines from where the identity is retrieved”, or something like that…

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Sep 2016 17:31:16 +0000

Hi,

Ok, maybe "multiple identities" was the wrong wording.

My point was that, even if you know you should derive the identity from PAI instead of From, you can have two P-Asserted-Identity header fields, and as far as I understand there is no guarantee that the canonicalized form of those match.

Regards,

Christer

From: Peterson, Jon [mailto:[email-masked]]
Sent: 09 September 2016 20:11
To: Christer Holmberg <[email-masked]>; [email-masked]
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Jon Peterson
Neustar, Inc.

Hi,

Section 8 of draft-4474bis says (or, that's at least my reading) that, if the SIP request contains multiple identities (e.g. if the request in addition to the From header field contains one or more P-Asserted-Identity header fields), it is RECOMMENDED to include "canon", so that the verifier knows which identity to verify.

Why is this only RECOMMENDED? If there are more than one identity, shouldn't it be a MUST? I don't think we want the verifier to try all identities, and see which one (if any) works, do we?

Now, the text DOES talk about "local policy" when it comes to choosing between From and PAI for deriving the identity, so perhaps we could say "MUST, unless local policy defines from where the identity is retrieved", or something like that...

Regards,

Christer

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 13 Sep 2016 22:30:34 +0000

The more values there are in a SIP request that are candidates for the identity of the caller, the more likely we are going to entertain corner cases like this. There is no guarantee that the canonicalized identity in the From header field will be identical to one in PAI - why carry PAI if it would be? - and similarly if there are multiple PAIs there's no guarantee that they will all canonicalize to the same form. Somehow, though, in those RFC3324 trust environments, you are supposed to be able to know which PAI contains the identity that you care about for this purpose, the identity of the originator of the call. STIR can't tell you how to find that, only local trust domain policy can. I don't think the burden is on STIR to make this unambiguous when apparently the trust domains already can and do.

But, of course, when carrying the "canon" parameter, it will have one value for the originating telephone number, say, and that will match the canonicalized form of one of those identities and not the others. If your trust domain introduces this ambiguity into every call, then your trust domain should probably set a local policy of sending "canon" with every call. I'm not sure there's much more to say about it than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 12, 2016 at 10:31 AM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Hi,

Ok, maybe “multiple identities” was the wrong wording.

Regards,

Christer

From: Peterson, Jon [mailto:[email-masked]]
Sent: 09 September 2016 20:11
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Jon Peterson
Neustar, Inc.

Hi,

Regards,

Christer

---

From: Alan Ford <[email-masked]>
Date: Thu, 15 Sep 2016 19:40:09 +0100

Hi all,

I’m involved in the interop testing of early STIR implementations at Sipit, and we have quickly run into issues around understanding how the sender has encoded the source/destination. One person’s tn: is another person’s sip: URI; the rules from the draft simply assume that any purely-numeric user part is a telephone number, which is not always the case in the real world. Without any context, when you call a numeric alias in another domain, you have no idea whether this maps to a telephone number or a SIP URI. If the receiver thinks it’s a tn:, but the sender thinks it’s a SIP URI, then the Identity will not validate.

In short, I agree with Christer that the canon is far more important than the draft suggests, and is needed whenever there could be any ambiguity about how a sender has encoded (or a receiver would encode) some of the data (which, frankly, is most B2B scenarios).

Indeed, I would go probably further and suggest the canon SHOULD always be included, - i.e. MUST, unless it is known to be operating within a controlled environment where all entities that may be validating the Identity header have a common understanding on its construction.

The second reason I think that future implementers would thank you for guidance like this is to enable extensibility. Say we wanted to add protection of Display Name - and in the SIP world this is very important since endpoints will typically display only display name if it is present, so provides a trivial way of bypassing human visual validation. Today, that would be achieved by defining a new ppt that added this field. Which is all well and good, but both the sender and the receiver would need to support this new ppt, and this is by no means guaranteed. So for maximum compatibility what would a sender do? Should a sender include multiple Identity headers of multiple ppts, hoping one is supported by the far end? The overhead there would be huge. If canon was always included, then (and I’m not saying this should necessarily be baseline spec, since it’s too big a change at this stage) a receiver could validate the signature of the canon, rather than reconstructing it, and then validate field-by-field for the fields it cares/knows about.

Regards,
Alan

> On 13 Sep 2016, at 23:30, Peterson, Jon <[email-masked]> wrote:
> 
> 
> From: Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> To: Jon Peterson <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>>   <>
>> From: Peterson, Jon [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Christer Holmberg <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked] <mailto:[email-masked]>>
>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Brian Rosen <[email-masked]>
Date: Thu, 15 Sep 2016 14:51:40 -0400

Can you cite an example?  I’m having trouble guessing where you have a >6 digit number string on the user side which is not a telephone number.  

If there is an implementation that is assigning sip:[email-masked] to a user that doesn’t have the telephone number +12025551212, then I don’t think I care much that identify fails.

Brian
 
> On Sep 15, 2016, at 2:40 PM, Alan Ford <[email-masked]> wrote:
> 
> Hi all,
> 
>> On 13 Sep 2016, at 23:30, Peterson, Jon <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Alan Ford <[email-masked]>
Date: Thu, 15 Sep 2016 19:56:03 +0100

Hi Brian,

I can think of many enterprises that have long numeric aliases (at least 6 digits) for internal dialling, but are mapped to external PSTN differently.

So everyone gets an extension, e.g. 44121234, but this is mapped to +44 1999 881234 for external dialling.

Regards,
Alan

> On 15 Sep 2016, at 19:51, Brian Rosen <[email-masked]> wrote:
> 
> If there is an implementation that is assigning sip:[email-masked] <sip:[email-masked]> to a user that doesn’t have the telephone number +12025551212, then I don’t think I care much that identify fails.
> 
> Brian
>  
>> On Sep 15, 2016, at 2:40 PM, Alan Ford <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi all,
>>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 15 Sep 2016 15:01:18 -0400

Okay, got it.  Pity the poor blokes who have to DTMF these extensions, but I get it.

So, what really is correct behavior here?  The call is sent with an internal extension as a SIP URI, the mechanism tries to set an Identity header, and what?

If it does not have a credential for that TN, it shouldn’t be trying to sign using a TN credential.

If it has a credential for the SIP ID, then the scope of that credential wouldn’t be a telephone number, it would be a domain, and the recipient should be able to figure out what is happening.

Where is the problem?

Brian

---

From: Alan Ford <[email-masked]>
Date: Thu, 15 Sep 2016 20:06:28 +0100

Hi Brian,

The problem is on the receiving end. I see a number as the source or destination, and decide it’s a tn: so try to construct a passport object with a tn: and validate it as such, but this fails. This is because the sender sent it as a sip: URI instead. But because there’s no canon, I don’t know how to reconstruct the passport so can’t validate.

Regards,
Alan

> On 15 Sep 2016, at 20:01, Brian Rosen <[email-masked]> wrote:
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 15 Sep 2016 20:51:42 +0000

I don't think I agree with either the framing of the problem or the proposed solution here (for the first problem in Alan's mail); but to dig in to this, we need to go back to the first principles of canonicalizing phone numbers.

A From identity (or a PAI identity) is expected to contain an address-of-record of the originator of the request. If some really unhelpful URI that is only resolvable locally is used as the From, then we should expect there to be problems in ordinary SIP operations if the request escapes that local environment. The whole point of including an AoR as your public identity is that someone who sees it can dereference it, and through standard routing procedures (in baseline SIP we mean RFC3263) you'll end up reaching the right user agents(). If you aren't operating within those constraints, I don't think that's really something that RFC4474bis can fix.

A To identity expresses the AoR you are trying to reach. We already have a split in baseline SIP between the To and the Request-URI, because SIP recognizes that the target of a request is likely to be dynamic: in baseline SIP, the To is supposed to be immutable, and the Request-URI is supposed to support hard changes.

When it comes to rfc4474bis, the idea of having both sides run their own independent canonicalization of the telephone number arose because deployment experience suggests that intermediaries in fact modify telephone numbers in transit in various ways, be they found in the To and From header field values or wherever else. This meddling includes thing like removing visual separators, but also includes adding and subtracting suffixes and prefixes as necessary to render the telephone number or URI there globally reachable and meaningful. Or in some cases, it includes nulling them out entirely because some other header (like PAI) is doing their job in a way that the intermediary likes better. Nothing that we do on the originating side will prevent intermediaries that want to alter these numbers form doing so -- including sticking them in a PASSporT object we tunnel in the SIP request. All that would do is encourage those intermediaries to change the numbers in the PASSporT object too. Like, years ago, we entertained just having a new SIP header field that would contain the canonical number as the authentication service saw it - but merely adding another field cannot get around the intermediaries: they will know it's there and they will do what they want to it. "canon" has no magic powers that would save it from the same fate.

At the end of the day, if you are on the receiving side, you are left to inspect whatever is left after intermediaries get through with the message. This remains one of the most important reasons that "canon" (which now means carrying the header and payload PASSporT objects) is optional: the philosophy behind canonicalization is that what matters isn't some value that the authentication service mandates, but instead how the two sides understand the numbers as they receive them. The originating side may initially direct the request to some local seven digital telephone number: but by the time that gets to the terminating side, a country code and area code might be added to it. They both "mean" the same number, and the authentication service that signs the request exercises the canonicalization process in order to capture what it thinks the originator "meant" for the global environment.

Moreover, to your specific argument, here's the rub: because this is a security function, carrying the canonical value in "canon" cannot really help unless the verification service already knows how to turn the value already in the From (or PAI or whatever) into the canonical value anyway. Why not? Because if I get a From with "sip:[email-masked]" and the PASSporT object in canon says the orig is a tn value "12012142102", how is the verification service supposed to know whether or not this is a cut-and-paste attack? If the verification service just blindly trusted that the contents of the PASSporT object's orig were equivalent to the URI in the From, it would never be able to tell whether or not the PASSporT object actually belonged with this call. The value of "canon" is only there for debugging and optimization purposes, we say this many times in the spec. It is NOT there to tunnel some "secret" value for the telephone number between the authentication service and verification service, as that would be a huge security hole. And it wouldn't work anyway because as I said above intermediaries could just change it. The neat thing about not including "canon" is that intermediaries can't change something that isn't in the message. This was effectively the argument Hadriel and others made back in the day.

You can argue that the verification service will sometimes not have sufficient information to arrive at the same canonicalization as the authentication service, and I agree. In some cases it won't: like when calls escape from really opaque private branches, or in if one end is in some weird variable-length dialing plan, or if a nationally-specific service number is used, or whatever. I just think that in order for those calls to realistically get routed and expect identity to work, they need to express identifiers in a way that is actually useful to the rest of the world. We formerly had some text in rfc4474bis that recommended (against the normative guidance of RFC3261, incidentally) that authentication services alter the To and From header fields to conform with the canonicalizations that they performed if those changes warranted notice. Ultimately, though, I took that out because the potential intermediary interference after the fact makes it moot. The question is not whether the verification service trusts the bits the authentication service claims it saw, the question is whether or not the verification service can derive an identity equal to that from the values it sees in the SIP request.

Ultimately, implementations need to use numbers in a sane way in order to have any expectation that SIP will work. In those cases where the use of numbers is sane enough that SIP will work, then I think Identity will probably work too.

Jon Peterson
Neustar, Inc.

From: Alan Ford <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 15, 2016 at 12:06 PM
To: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Cc: Jon Peterson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Hi Brian,

Regards,
Alan

On 15 Sep 2016, at 20:01, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:

Where is the problem?

Brian

On Sep 15, 2016, at 2:40 PM, Alan Ford <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Regards,
Alan

On 13 Sep 2016, at 23:30, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

Jon Peterson
Neustar, Inc.

Hi,

Regards,

Christer

Jon Peterson
Neustar, Inc.

Hi,

Regards,

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

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

---

From: Brian Rosen <[email-masked]>
Date: Thu, 15 Sep 2016 17:28:50 -0400

I understood the problem to be:
sip:[email-masked] is a perfectly valid SIP URI, which, if called would get to the right person.  414428123 however, is not a telephone number, it’s a userId, and a valid userId within the example.com domain.  If the receiving end tries to canonicalize that digit string, and use that as the identity, it will fail. It has to use the entire SIP URI as the identity.

And I think the solution is the domain of the credential.

Brian

> On Sep 15, 2016, at 4:51 PM, Peterson, Jon <[email-masked]> wrote:
> 
> 
> From: Alan Ford <[email-masked] <mailto:[email-masked]>>
> To: Brian Rosen <[email-masked] <mailto:[email-masked]>>
> Cc: Jon Peterson <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Christer Holmberg <[email-masked] <mailto:[email-masked]>>
>>> On 15 Sep 2016, at 20:01, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 15 Sep 2016 21:52:14 +0000

I took Alan's mail to be speaking to the much more general problem of why we perform two independent canonicalization passes at all, if in some cases it is impossible for the terminating side to know what the originating side meant.

I don't disagree that the signing credential, and its scope of authority, can give you an indication of which kind of identity the originating side thinks its signing for. I'm not sure even that will ever be entirely free of potential ambiguity; I could construct some corner cases where a certificate has both a subjectAltName and a TNAuthorizationList, say. But if you're saying it's worth mentioning that the signing credential can provide a hint, we could put in some text to that effect.

Jon Peterson
Neustar, Inc.

From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 15, 2016 at 2:28 PM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>
Cc: Alan Ford <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

I understood the problem to be:
sip:[email-masked] is a perfectly valid SIP URI, which, if called would get to the right person.  414428123 however, is not a telephone number, it’s a userId, and a valid userId within the example.com<http://example.com> domain.  If the receiving end tries to canonicalize that digit string, and use that as the identity, it will fail. It has to use the entire SIP URI as the identity.

Brian

On Sep 15, 2016, at 4:51 PM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

Jon Peterson
Neustar, Inc.

Hi Brian,

Regards,
Alan

Where is the problem?

Brian

Hi all,

Regards,
Alan

Jon Peterson
Neustar, Inc.

Hi,

Regards,

Christer

Jon Peterson
Neustar, Inc.

Hi,

Regards,

Christer

---

From: Alan Ford <[email-masked]>
Date: Fri, 16 Sep 2016 03:18:13 +0100

Thanks for the detailed clarifications, Jon. My issue is indeed with the idea that two independent canonicalisation procedures may come up with different answers, thus negating any benefit from this scheme. I had not considered the idea of looking at the the signing CA and determining behaviour based on this - if it looks like a cert that would authorise a tn: then canonicalise as a tn:, else canonicalise as a sip: URI. I think this would probably resolve most issues around my primary concern here, although it’s not particularly efficient, but if this was the case then this is something that needs to be spelled out more clearly (including the logic around determining whether a CA Is appropriate for tn: canonicalisation).

However, I still share Christer’s original concerns about selection of URIs for multiple identities. My view after our interop testing and investigating real-world deployment is that mandating the use of canon in these situations would significantly help validation.

> A From identity (or a PAI identity) is expected to contain an address-of-record of the originator of the request. If some really unhelpful URI that is only resolvable locally is used as the From, t…

This is a concern right here, however. Do you use From or PAI? Which PAI if there’s more than one? Or do you include all of them? If so, in what order? What about Remote-Party-ID? Without including a canon this is very difficult to validate.

[...]

> At the end of the day, if you are on the receiving side, you are left to inspect whatever is left after intermediaries get through with the message. This remains one of the most important reasons t…

I don’t follow why this is an argument against carrying the canon. Or are you saying that the receiver has its own canonicalisation process it should be able to determine from the headers the source or destination that the originator originally intended? If so, that’s assuming a lot of shared knowledge after headers have been mangled! But if the canon was included, then this could provide hints in such a situation and the receiver could know whether the field values it sees matches the intended value as shown in the canon, rather than guessing!

> Moreover, to your specific argument, here's the rub: because this is a security function, carrying the canonical value in "canon" cannot really help unless the verification service already knows how to turn the value already in the From (or PAI or whatever) into the canonical value anyway. Why not? Because if I get a From with "sip:[email-masked] <sip:[email-masked]>" and the PASSporT object in canon says the orig is a tn value "12012142102", how is the verification service supposed to know whether or not this is a cut-and-paste attack? If the verification service just blindly trusted that the contents of the PASSporT object's orig were equivalent to the URI in the From, it would never be able to tell whether or not the PASSporT object actually belonged with this call.

I completely agree. I see the canon as a way of telling the receiver “this is what I encoded”. This allows the receiver to easily verify whether a) the values now present in the headers can be mapped to the values in the PASSporT object (as shared by the canon) by local logic of the verification service; and b) if there is the potential for confusion (multiple source/dest options, or multiple encodings for source/dest), this clarifies which one was chosen.

> The value of "canon" is only there for debugging and optimization purposes, we say this many times in the spec. It is NOT there to tunnel some "secret" value for the telephone number between the authentication service and verification service, as that would be a huge security hole. And it wouldn't work anyway because as I said above intermediaries could just change it. The neat thing about not including "canon" is that intermediaries can't change something that isn't in the message. This was effectively the argument Hadriel and others made back in the day.

Sorry, I don’t follow any of the above. Including canon does not add any security hole, it does not allow intermediaries to change anything, since it is protected by the signature. A receiver can receive the canon, validate the signature against the canon, and then validate the fields. This makes much more sense from an implementation point of view than trying to guess the construction of the PASSporT object from the fields in the SIP message, and then seeing if this validates.

> You can argue that the verification service will sometimes not have sufficient information to arrive at the same canonicalization as the authentication service, and I agree. In some cases it won't: like when calls escape from really opaque private branches, or in if one end is in some weird variable-length dialing plan, or if a nationally-specific service number is used, or whatever. I just think that in order for those calls to realistically get routed and expect identity to work, they need to express identifiers in a way that is actually useful to the rest of the world.

Absolutely agreed, and therefore in all these circumstances SIP URIs would be used for the encoding. The problem I raised is more with receivers. How do receivers know how the sender encoded it?

Regards,
Alan

> On 15 Sep 2016, at 22:52, Peterson, Jon <[email-masked]> wrote:
> 
> 
> From: Brian Rosen <[email-masked] <mailto:[email-masked]>>
> To: Jon Peterson <[email-masked] <mailto:[email-masked]>>
> Cc: Alan Ford <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Christer Holmberg <[email-masked] <mailto:[email-masked]>>
>> sip:[email-masked] <sip:[email-masked]> is a perfectly valid SIP URI, which, if called would get to the right person.  414428123 however, is not a telephone number, it’s a userId, and a valid userId within the example.com <http://example.com/> domain.  If the receiving end tries to canonicalize that digit string, and use that as the identity, it will fail. It has to use the entire SIP URI as the identity.
>> 
>>> On Sep 15, 2016, at 4:51 PM, Peterson, Jon <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> Moreover, to your specific argument, here's the rub: because this is a security function, carrying the canonical value in "canon" cannot really help unless the verification service already knows how to turn the value already in the From (or PAI or whatever) into the canonical value anyway. Why not? Because if I get a From with "sip:[email-masked] <sip:[email-masked]>" and the PASSporT object in canon says the orig is a tn value "12012142102", how is the verification service supposed to know whether or not this is a cut-and-paste attack? If the verification service just blindly trusted that the contents of the PASSporT object's orig were equivalent to the URI in the From, it would never be able to tell whether or not the PASSporT object actually belonged with this call. The value of "canon" is only there for debugging and optimization purposes, we say this many times in the spec. It is NOT there to tunnel some "secret" value for the telephone number between the authentication service and verification service, as that would be a huge security hole. And it wouldn't work anyway because as I said above intermediaries could just change it. The neat thing about not including "canon" is that intermediaries can't change something that isn't in the message. This was effectively the argument Hadriel and others made back in the day.
>>>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 16 Sep 2016 05:19:08 +0000

We're still not quite on the same page I fear.

Well like I said, if it helps, I don't see any reason not to mention it in the spec. But...

... I guess you are saying it does't help enough?

There may be good reasons to include the entire PASSporT object in every SIP request, but I still don't think the issues you enumerate here are it.

I've previously noted that practical deployments require the sane use of identities. "Which PAI if there's more than one?" or worse, what if you have RPID too? Well, which identifier does your deployment treat as the identity of the user today? If you can't answer that question, you shouldn't be laying this problem at the feet of rfc4474bis. SIP was not designed to let you put fifteen originating identities into a request, and in terms of figuring out an identity for the purposes of defeating the attacks in our threat model (robocalling etc) speculating about this proliferation of identities is counterproductive.

"Difficult to validate" here presumably means that you have to know which identity was used by the authentication service, which one it thought was the "real" identity. Well, today, in a pre-rfc44744bis world, SIP requests appear with both From and PAI. How do you know which one contains the "real" identity of the user? The short answer is that local policy tells you. Is this a practical problem? Given the prevalence of PAI in the field, I'd say it isn't. And if there are multiple PAIs in the same request, how do you know? The same way. Again, casting this as a problem that rfc4474bis has to fix discounts the fact that this is literally the deployment reality today and there isn't a problem. Nothing about adding rfc4474bis to the mix creates a new problem that we need to address that I can see.

Finally, I will reiterate for like the nth time on this list that in order to close this issue, we presented this as a slide at the last IETF, and we discussed it, and we took a consensus call, and the result was that the group thought there was no problem. At that meeting, we even discussed as a strawman proposal that the PASSporT object would carry some explicit indicator saying which header in the SIP request an identity came form. No new information is being added to the discussion by these threads other than vague "isn't there a problem?" sorts of questions. If there is new information here, if there is a problem with existing deployments today that cannot disambiguate multiple uses of PAI, then we probably need to fix it in PAI rather than in rfc4474bis. But no one has however offered any evidence that there's actually any ambiguity when using multiple PAIs in the absence of Identity.

[...]

I don’t follow why this is an argument against carrying the canon. Or are you saying that the receiver has its own canonicalisation process it should be able to determine from the headers the source or destination that the originator originally intended?

I am saying that, yes. It won't always work, but it'll work in the cases where SIP (and identity) has any hope of working anyway.

If so, that’s assuming a lot of shared knowledge after headers have been mangled!

I am making the stronger claim that if the receiver can't do that, the Identity mechanism offers little security.

But if the canon was included, then this could provide hints in such a situation and the receiver could know whether the field values it sees matches the intended value as shown in the canon, rather than guessing!

The problem here is hiding behind "the field value it sees matches the intended value." If "the intended value" was generated (or more likely cut-and-pasted) by an attacker, then the verification service needs to be able to detect that this value does not conform with the values in the SIP request. There is no guesswork required: the verifier performs a canonicalization procedure on the SIP request to determine that. The results of that procedure either equal the value that the authentication service used when it signed or they don't. Thus it doesn't matter whether "canon" provides the full PASSporT object or not: the presence of "canon" will never remove the obligation of the verification service to actually look at the SIP message and canonicalize the identity of the originator.

Moreover, to your specific argument, here's the rub: because this is a security function, carrying the canonical value in "canon" cannot really help unless the verification service already knows how to turn the value already in the From (or PAI or whatever) into the canonical value anyway. Why not? Because if I get a From with "sip:[email-masked]" and the PASSporT object in canon says the orig is a tn value "12012142102", how is the verification service supposed to know whether or not this is a cut-and-paste attack? If the verification service just blindly trusted that the contents of the PASSporT object's orig were equivalent to the URI in the From, it would never be able to tell whether or not the PASSporT object actually belonged with this call.

I understand that your primary impetus in discussing this is (b), that you want to disambiguate a number of different headers that are potential carriers of identity. I at least get what you want from that. But (a) is a more complicated matter, as I describe above. Again, a lot is hiding behind "can be mapped" in the description of (a). The value used by the authentication service either maps according to the canonicalization procedure performed by the verifier or it doesn't. The presence of canon cannot influence the verification service decision: we want security to fail (which, I feel obliged to say, doesn't necessarily mean rejecting the request) if the verification service canonicalization does not resolve to the same value that the auth service used. That is what this mechanism is designed to do.

Sorry, I don’t follow any of the above. Including canon does not add any security hole, it does not allow intermediaries to change anything, since it is protected by the signature.

... the PASSport object is not a security hole in the sense that it lacks integrity protection. The security hole appears only if we stipulate that the verification service trusts that the orig tn value in the PASSporT object is a canonicalization of whatever identity the SIP request carries. If the authentication service is an attacker, it can set the orig tn in the PASSporT object to any value of its choosing. Ascertaining the relationship of that value to the value of the TN in the From (or PAI) is a crucial security function that the verification service performs.

(Well, and as rfc4474bis noted, passing around the whole object can also introduce some privacy concerns when requests exit the boundaries of RFC3324 trusted networks, but that's not the matter at hand here. A different security hole that is another reason why including the full PASSporT object is not a MUST.)

A receiver can receive the canon, validate the signature against the canon, and then validate the fields. This makes much more sense from an implementation point of view than trying to guess the construction of the PASSporT object from the fields in the SIP message, and then seeing if this validates.

The problem here is hiding behind what you mean by "validate the fields". The comparison operation that the verification service performs to do that validation requires it to perform the entire canonicalization process itself. rfc4474bis says that the verification service, *before* it bothers to validate the signature, optionally can perform this function, and compare the value it gets as a result against the orig tn in PASSporT (when present), solely as an optimization - so if there's no match is won't need to do the crypto. So it's not that I disagree that there's an optimization pass we can make, if "canon" is present. I just get very nervous when I hear this framed the other way, as more than an optimization, but instead as a substitute for having to "guess the construction of the PASSporT object from the fields of the SIP message," which is indeed an apt description of the procedures that rfc4474bis requires.

By finding out for themselves by performing the canonicalization. If they trust the sender to tell them how it was encoded, then the PASSporT object has no practical reference integrity with the SIP request.

Jon Peterson
Neustar, Inc.

---

From: Alan Ford <[email-masked]>
Date: Fri, 16 Sep 2016 16:21:56 +0100

Hi Jon, all,

> On 16 Sep 2016, at 06:19, Peterson, Jon <[email-masked]> wrote:
> 

No, it doesn’t. I was a bit too optimistic when I wrote that, the real problem is on the receiving side: How does the receiver know how the sender has canonicalised the destination?

That’s the number #1 problem I think. You could use the cert to infer how the sender may have canonicalised the source, but the destination there is no clue. Unless you make an assumption that tn:s call tn:s with a tn cert, otherwise it’s a SIP URI. That I could live with but seems unnecessarily limiting.

> "Difficult to validate" here presumably means that you have to know which identity was used by the authentication service, which one it thought was the "real" identity. Well, today, in a pre-rfc447…

This comes back to the same problem, fundamentally. “Local policy tells you” - that’s great, but when applied to STIR this requires both the sender and the receiver to have the same local policy.

> Finally, I will reiterate for like the nth time on this list that in order to close this issue, we presented this as a slide at the last IETF, and we discussed it, and we took a consensus call, and…

Indeed. I didn’t speak up in Berlin on this, and neither did I pick up on this when reviewing an earlier version of the draft, since it all made sense in my head - “implementations would understand how to do this based on the environments in which they were operating” was my thought. However, having actually sat down with a colleague and started to create running code, the real-world problems quickly become apparent.

Our current real-world problem is the SIP/TN decision process at the receiver, particularly for destination address(es), but it’s also becoming apparent that for compatibility the other issues raised here, such as selection of PAI vs From, are likely to cause problems.

> The problem here is hiding behind "the field value it sees matches the intended value." If "the intended value" was generated (or more likely cut-and-pasted) by an attacker, then the verification s…

Indeed not. But, it tells the receiver which fields to look in, and what form of canonicalisation to undertake. This is A Good Thing from an implementation and interoperability point of view.

> I understand that your primary impetus in discussing this is (b), that you want to disambiguate a number of different headers that are potential carriers of identity. I at least get what you want from that. But (a) is a more complicated matter, as I describe above. Again, a lot is hiding behind "can be mapped" in the description of (a). The value used by the authentication service either maps according to the canonicalization procedure performed by the verifier or it doesn’t.

And that is the crux of the matter.

> The presence of canon cannot influence the verification service decision: we want security to fail (which, I feel obliged to say, doesn't necessarily mean rejecting the request) if the verification service canonicalization does not resolve to the same value that the auth service used. That is what this mechanism is designed to do.

But this is the problem! When a sender does not know its target would canonicalise the destination address as a TN, and thus encodes it as a SIP URI in the PASSporT object, verification would fail. But with canon, the verification service could be more intelligent, as it may be able to pass all other verification logic if it knew how the field had been canonicalised.

Verification failing in this circumstance is surely bad?

> ... the PASSport object is not a security hole in the sense that it lacks integrity protection. The security hole appears only if we stipulate that the verification service trusts that the orig tn value in the PASSporT object is a canonicalization of whatever identity the SIP request carries.

I don’t think anyone is suggesting that should be the logic. I certainly am not.

> If the authentication service is an attacker, it can set the orig tn in the PASSporT object to any value of its choosing. Ascertaining the relationship of that value to the value of the TN in the From (or PAI) is a crucial security function that the verification service performs.

And passing the canon does not prevent the verification service from providing this function.

> The problem here is hiding behind what you mean by "validate the fields". The comparison operation that the verification service performs to do that validation requires it to perform the entire can…

I may be being slow here, and apologies if so, but I still don’t understand what benefit is brought by not sharing the construction.

> By finding out for themselves by performing the canonicalization. If they trust the sender to tell them how it was encoded, then the PASSporT object has no practical reference integrity with the SI…

It sounds like you are arguing there are two binary options here: no shared canon, so both parties trust the other to perform the same process; or share a canon, and it sounds as if you believe that would mean “well the canon is signed so this is obviously a valid canonicalisation of what’s in the header”. Which is obviously completely insecure.

I’m saying there’s a middle ground here. When there are multiple possibilities for canonicalisation, providing the canon helps the verification service decide which one to use. The security remains the same, as long as the canonicalisation process being followed is one that is trusted by the verification service anyway.

My proposal, just to reiterate, is to mandate the presence of canon unless STIR is being used between environments where both parties are known to have a common canonicalisation scheme.

Regards,
Alan

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Sep 2016 11:42:58 -0400

On 9/16/16 11:21 AM, Alan Ford wrote:

>> Finally, I will reiterate for like the nth time on this list that in
>> order to close this issue, we presented this as a slide at the last
>> IETF, and we discussed it, and we took a consensus call, and the
>> result was that the group thought there was no problem. At that
>> meeting, we even discussed as a strawman proposal that the PASSporT
>> object would carry some explicit indicator saying which header in the
>> SIP request an identity came form. No new information is being added
>> to the discussion by these threads other than vague "isn't there a
>> problem?" sorts of questions. If there is new information here, if
>> there is a problem with existing deployments today that cannot
>> disambiguate multiple uses of PAI, then we probably need to fix it in
>> PAI rather than in rfc4474bis. But no one has however offered any
>> evidence that there's actually any ambiguity when using multiple PAIs
>> in the absence of Identity.
>
> Indeed. I didn’t speak up in Berlin on this, and neither did I pick up
> on this when reviewing an earlier version of the draft, since it all
> made sense in my head - “implementations would understand how to do this
> based on the environments in which they were operating” was my thought.
> However, having actually sat down with a colleague and started to create
> running code, the real-world problems quickly become apparent.
>
> Our current real-world problem is the SIP/TN decision process at the
> receiver, particularly for destination address(es), but it’s also
> becoming apparent that for compatibility the other issues raised here,
> such as selection of PAI vs From, are likely to cause problems.

Surely the caller and signer bear some responsibility here. If they 
create a situation where there is ambiguity about which address is being 
signed then either they should do something to resolve it (e.g., in 
include canon) or else be prepared for the consequences if the callee 
can't validate. It is in the caller's interest that the call be 
validated, so they should be expected to make that feasible. This 
ultimately comes down to quality of implementation.

But there is also a brute force solution available to the validator: try 
validation using each of the supplied identities in turn until one 
validates or none do. While that might cost a bit of extra computation, 
the cost of that might be less than the cost of carrying the canon 
parameter from end to end.

	Thanks,
	Paul

---

From: Alan Ford <[email-masked]>
Date: Fri, 16 Sep 2016 17:57:39 +0100

Hi Paul,

> Surely the caller and signer bear some responsibility here. If they create a situation where there is ambiguity about which address is being signed then either they should do something to resolve it (e.g., in include canon) or else be prepared for the consequences if the callee can't validate. It is in the caller's interest that the call be validated, so they should be expected to make that feasible. This ultimately comes down to quality of implementation.

The sender may or may not know that there would be ambiguity at the receiving side. For example, the sender may only deal in SIP URIs and not know the receiver is also a PSTN gateway.

But in general, I agree, but feel this should be codified. This is why my proposed resolution here would be to mandate canon unless the sender knows for certain the receiving environment will follow the same canonicalisation scheme - or words to that effect.

> But there is also a brute force solution available to the validator: try validation using each of the supplied identities in turn until one validates or none do. While that might cost a bit of extra computation, the cost of that might be less than the cost of carrying the canon parameter from end to end.

That’s certainly true, but in my opinion the cost of bits is much cheaper than the cost of computation. What’s more, a brute-force receiver could generate a modest denial-of-service attack vector - send a signature for something completely different, and let the verification service munch through cycles trying various combinations to see if any validate (they won’t, of course). Minimum would be four combinations tried for just one src and one dest (trying tn: vs sip: combinations) - and this could be many more if you start to include other identifiers such as PAI or RPID. Whereas, if the canon was included, there would be one single crypto operation to verify the signature against known data.

Regards,
Alan

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Sep 2016 17:27:26 +0000

Without taking a position on whether to canon-ize or not (that's a papal thing and I'm not catholic), I wonder if ATIS/SIPForum NNI best practices will largely moot this issue, i.e., within a particular context the use of PAI vs. From and the encoding will be constant and ruled by best practices, so that real devices will just have a configuration setting that says "Look at PAI; only if absent, look at From". Clearly, for calls within a carrier network, this is not likely to be an issue.

Not ideal, but the good guys will have an incentive to adhere to common practice, as they want validation to work.

I haven't looked at the details of the SIP NNI spec to see if that spec is sufficiently precise or whether, say, the SHAKEN ATIS document could provide that level of specificity.

Unless a parameter can short-circuit the exploration completely ("only look at X"), I'm not sure 'canon' helps with the resource exhaustion issue.

Henning

________________________________
From: stir <[email-masked]> on behalf of Alan Ford <[email-masked]>
Sent: Friday, September 16, 2016 12:57:39 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Hi Paul,

Regards,
Alan

---

From: Brian Rosen <[email-masked]>
Date: Fri, 16 Sep 2016 13:35:35 -0400

I think it probably would within the ATIS kind of environment, but Alan is talking about things that are beyond that: his example is a SIP URI from an enterprise PBX that doesn’t have a phone number in the identity.

I personally think we need to get the PBX vendors on board as fast as we can in order to be able to support “authorized spoofing”, like call centers calling on behalf of other enterprises.  I think getting the service providers to sign in those cases will be complicated, and if they can push the problem off to the call center, it will work out better.  So, I think its worth solving all/most of the problems the PBX folks think they have.

Having said that, the only circumstance I can think of where there is an identity like he is describing is an intra-enterprise call (possibly between sites, but within the same enterprise).  In those environments, identity spoofing is much harder to mount because the intra-enterprise traffic tends to be entirely within the corporate network, and they don’t allow calls from sources they don’t know.  Doesn’t mean stir should not work, but it’s pretty far down in my list of things to worry about.

Brian

> On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne <[email-masked]> wrote:
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Sep 2016 17:45:38 +0000

Wouldn't this seem like something that SIPConnect 2.0 should address?

My general impression is that there are a small number of ways to do things well, and a near-infinite number of ways to make life difficult for everybody else. Trying to accommodate and detect the latter seems like a fool's errand, given that we want validation to work as close to 100% as possible. This discussion seems to have yielded a number of reasonable guidelines, along the lines of:

* consistently use PAI or From (i.e., be clear what should be used within a particular operating context, such as SIPConnect or SIP NNI)

* only convey return-callable global (E.164) numbers outside your own closed network

* separators in tel URIs should be expected

* short codes, N11 and similar numbers will likely only work within a national context

Thus, "be predictable, boring and conservative in what you send, and don't expect the receiver to be liberal".

Here, we have a penalty function: Being "creative" will likely get your call flagged as unvalidated.

Henning

________________________________
From: Brian Rosen <[email-masked]>
Sent: Friday, September 16, 2016 1:35:35 PM
To: Henning Schulzrinne
Cc: Alan Ford; Paul Kyzivat; [email-masked]
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Brian

On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

Henning
________________________________
From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Alan Ford <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 16, 2016 12:57:39 PM
To: Paul Kyzivat
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Hi Paul,

Regards,
Alan

---

From: Brian Rosen <[email-masked]>
Date: Fri, 16 Sep 2016 13:53:40 -0400

My understanding of SIPconnect 2.0 is that it’s still an enterprise to service provider handoff interface, and thus would assume real telephone numbers in the identity, but I’m not directly involved.

But I’m in agreement with your points.

Brian

> On Sep 16, 2016, at 1:45 PM, Henning Schulzrinne <[email-masked]> wrote:
> 
>> On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of Alan Ford <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 16 Sep 2016 18:00:33 +0000

It is a fundamental requirement of using PAI that it be true that the sender and receiver have the same local policy for this. That I what RFC3324 exists to say. If we take that away, none of the mechanism around PAI really works. This is why I've been saying if something is broken here, it's broken in PAI.

If Brian's cert hint fixes the first problem, I am pretty comfortable saying that I'm not worried about the second problem (at least for the purposes of rfc4474bis). As Henning recently suggested, in the trusted networks where PAI is used, there are probably going to be profiles that govern the local policy that will at least make it clear to the participants in the trust network. All we need to do is what rfc3325 tells us - to rely on those networks to do their job.

Only if you think that the way that the state in which the authentication service saw these fields should determine for the verifier what the "real" identity of the originator is. That is not an assumption we make, or should make.

Since we're still talking about this, maybe we should also bring this back to the gatewaying and mixed-SIP cases that informed this decision. I hesitate to move indications into PASSporT that say things like "I got this identity from a PAI" because PASSporT shouldn't have those sorts of dependencies on a using protocol. I similarly can imagine a case where a VoIP call starts in, say, Jingle, and lands eventually on a SIP endpoint, with some gateway in the middle. The original Jingle authentication service didn't derive its TN from any SIP header at all. Cases like that should be in our scope of consideration here.

I would ultimately prefer not to festoon PASSporT with SIP-specific indicators.

I am indeed saying that is a security bug, not a feature. Though surely an attacker would like to make the verification service "more intelligent" by telling it "try to see things my way."

We both agree that "canon" should at least be allowed, and when it is present, I think it is meaningful for the verification service to compare the canonicalized value(s) it found in the message with the orig value of the PASSporT object as a step in the verification process. That doesn't raise any alarm bells for me. As soon as this becomes instead about how the verification service should decide based on the information in "canon" how its canonicalization process should work., that trips the alarm loud and clear.

I cannot distinguish what you are recommending from this.

Well, let me put it this way. When you have fourteen identities in a message, there is a natural temptation to say that what we need is a new field that will let recipients know what the "real" identity is to remove ambiguity. The result of that is inevitably that we now have fifteen identities in a message. Make no mistake: the orig value in canon is just a fifteenth identity. The kinds of intermediaries that change identities will not see the one in canon any differently.

Hadriel argued (and as the foremost SBC vendor at the time, I'd say persuasively) that including the value only makes it a target for intermediaries to modify, and consequently to break the signature in the PASSporT object - or indeed to just remove the Identity header and PASSporT object altogether. The policies that make intermediaries modify the identity in the From header will not spare the contents of canon. This is how we came to the idea of allowing intermediaries to change the bits a little as they went by, under the assumption that the two ends would be able to figure out what number was meant. We studied this a bit at the time and came to the conclusion that it would work in the cases where SIP is likely to work anyway.

I think what I've argued is that canon should be optional because its big and and it probably doesn't help as much as one might think. And that it might even hurt in some cases (like the ones Hadriel spoke to). But that for debugging or optimizations, it might still be useful in some transactions.

I’m saying there’s a middle ground here. When there are multiple possibilities for canonicalisation, providing the canon helps the verification service decide which one to use.

This is exactly not what canon is for, and if it were, it would be a problem.

The security remains the same, as long as the canonicalisation process being followed is one that is trusted by the verification service anyway.

If the canonicalization process the verifier was going to follow would have worked anyway, there's no need for the influence you're suggesting.

My proposal, just to reiterate, is to mandate the presence of canon unless STIR is being used between environments where both parties are known to have a common canonicalisation scheme

PAI has all sorts of funky assumptions about being in a trusted network and knowing what the policies will be at the place you land. rfc4474bis does not, and should not. The only reason we're even in this discussion is because we allowed Identity to sign PAI rather than From, and thus PAI's murkiness is creeping into the edges of the rfc4474bis process. It should stay at the edges. If there are ambiguities this introduces, they should be fixed at the PAI level (which probably means in profile documents for the trust networks that use PAI).

Jon Peterson
Neustar, Inc.

Regards,
Alan

---

From: Richard Shockey <[email-masked]>
Date: Fri, 16 Sep 2016 14:06:42 -0400

Probably more like SIP Connect 3.0.   2.0 is in ballot as we speak but both points are well taken.  

These are exactly the kind of issues that can be dealt with in implementation profiles or BCP’s as the case may be.  

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

From: stir <[email-masked]> on behalf of Henning Schulzrinne <[email-masked]>
Date: Friday, September 16, 2016 at 1:45 PM
To: Brian Rosen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Kyzivat <[email-masked]>, Alan Ford <[email-masked]>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Henning

Brian

Henning

Hi Paul,

Regards,
Alan

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

---

From: Alan Ford <[email-masked]>
Date: Sat, 17 Sep 2016 02:19:59 +0100

Hi Jon,

I feel we’re getting distracted by the PAI discussion here, and this was not the initial driver behind my comments. I felt it was an additional valid issue, stemming from the same problems of lack of clear canonicalisation, and so latched on to the ongoing discussions here, but let’s leave this out for the moment.

My primary concern was the SIP/TN distinction. Here is an example, real-world which we ran into in SIPit:

- Sender’s PASSporT:

{ “orig” : { “uri” : “sip:[email-masked]” }, “dest” : { “uri” : [ “sip:[email-masked]” ] } }

The sender sends like this since it is in a SIP environment, e.g. a large enterprise, with no distinction of internal and external calling.

- Receiver’s PASSporT:

{ “orig” : { “uri” : “sip:[email-masked]” }, “dest” : { “tn” : “87654321" } }

These are two different PASSporTs, which will not validate, because both ends canonicalised a call in a different way. The receiver considers the number a TN, but the sender did not.

This is why I am proposing mandating canon in any circumstances where you cannot guarantee the behaviour of the receiver.

A few more replies inline; avoiding anything PAI-related...

> On 16 Sep 2016, at 19:00, Peterson, Jon <[email-masked]> wrote:
> 

That’s perfectly understandable, and a new PASSporT could be defined to provide this function if desired.

However, to achieve deployability with STIR as defined today requires people to canonicalise in the same way. To make this happen, we need to share information.

> I am indeed saying that is a security bug, not a feature. Though surely an attacker would like to make the verification service "more intelligent" by telling it "try to see things my way.” 

Then I fear there is misunderstanding here. A verification service has a set of possible canonicalisations (e.g. to TN or not to TN). It could, as Paul said in another mail, try all combinations, but that would be computationally expensive. By providing the canon we are providing information as to which of these possible canonicalisations to choose. This is not adding any additional security risk - all canonicalisations are those which the verification service would support anyway.

> We both agree that "canon" should at least be allowed, and when it is present, I think it is meaningful for the verification service to compare the canonicalized value(s) it found in the message wi…

Again, this is not saying “what is in the canon is truth”, it is saying “this is what I encoded, if you think this canonicalisation is accurate then let’s validate”.

> I cannot distinguish what you are recommending from this.

I hope my example at the start of this mail clarifies this.

Regards,
Alan

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 19 Sep 2016 20:26:15 +0000

Can you explain then how Brian's hint doesn't resolve this?

- Sender’s PASSporT:

Even without Brian's hint, cases like this don't actually keep me up at night. And not just because, well, "destination.net" probably isn't CompuServ and thus there's little chance it issues entirely-numeric usernames. It doesn't especially concern me because in order for a SIP request to actually be routed, you need to know whether it's just a telephone number, in which case you might drop it to any old gateway to the PSTN with equal effect, or if in fact you're expected to perform RFC3263 routing on the domain name part. Somehow, this works today without us adding any indicator to SIP to resolve any confusions.

SIP routing has some core ambiguities around using telephone numbers that it isn't the Identity header's job to rectify. But the important question is whether or not, in our threat model, we think that this particular ambiguity will arise enough that it justifies always including "canon." We opened up the STIR working group to address problems with telephone numbers as identifiers in SIP; along the way, we decided that it was worth allowing that the same mechanism would work for greenfield SIP URIs as well. I think the common case for STIR will be to use telephone numbers for both orig and dest, just as it is in SIP deployment today.

I would, perhaps, grudgingly, be willing to entertain normative guidance that states that if either orig or dest does not contain a "tn" identity then you MUST use "canon." That would avoid the rather weasel-y RFC3324ish proposed language about only sending "canon" when you psychically know the terminating side shares your canonicalization scheme. Even in my proposed form, I think it's overkill. But just hypothetically, would that resolve your concern? Or anyone else's?

Jon Peterson
Neustar, Inc.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 19 Sep 2016 19:05:06 -0400

Not to mention that you are supposed to use user=phone when the user part
is a phone number and a context when it's not a globally routable number.
It's pretty tough to design sensible extensions to a protocol when
implementations don't follow the original mechanisms and then demand to be
treated as if what they implemented was correct.

Brian

On Monday, September 19, 2016, Peterson, Jon <[email-masked]
<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

> The sender sends like this since it is in a SIP environment, e.g. a large
> enterprise, with no distinction of internal and external calling.
>
>
> Even without Brian's hint, cases like this don't actually keep me up at
> night. And not just because, well, "destination.net" probably isn't
> CompuServ and thus there's little chance it issues entirely-numeric
> usernames. It doesn't especially concern me because in order for a SIP
> request to actually be routed, you need to know whether it's just a
> telephone number, in which case you might drop it to any old gateway to the
> PSTN with equal effect, or if in fact you're expected to perform RFC3263
> routing on the domain name part. Somehow, this works today without us
> adding any indicator to SIP to resolve any confusions.
>
> SIP routing has some core ambiguities around using telephone numbers that
> it isn't the Identity header's job to rectify. But the important question
> is whether or not, in our threat model, we think that this particular
> ambiguity will arise enough that it justifies always including "canon." We
> opened up the STIR working group to address problems with telephone numbers
> as identifiers in SIP; along the way, we decided that it was worth allowing
> that the same mechanism would work for greenfield SIP URIs as well. I think
> the common case for STIR will be to use telephone numbers for both orig and
> dest, just as it is in SIP deployment today.
>
> I would, perhaps, grudgingly, be willing to entertain normative guidance
> that states that if either orig or dest does not contain a "tn" identity
> then you MUST use "canon." That would avoid the rather weasel-y RFC3324ish
> proposed language about only sending "canon" when you psychically know the
> terminating side shares your canonicalization scheme. Even in my proposed
> form, I think it's overkill. But just hypothetically, would that resolve
> your concern? Or anyone else's?
>
> Jon Peterson
> Neustar, Inc.
>

---

From: Chris Wendt <[email-masked]>
Date: Mon, 19 Sep 2016 19:42:04 -0400

Have to agree here, if you put digits in front of a SIP URI without user=phone/context, all bets are off for any chance of deterministic behavior for “telephone numbers” for anything beyond a private network.  For both STIR and non-STIR.

Just like you have some “special arrangement” with all of the clients in your network to interpret sip:[email-masked] <sip:[email-masked]> as a “telephone number”, you could also have the same arrangement to mandate canon.

> On Sep 19, 2016, at 7:05 PM, Brian Rosen <[email-masked]> wrote:
> 
> Not to mention that you are supposed to use user=phone when the user part is a phone number and a context when it's not a globally routable number.   It's pretty tough to design sensible extensions to a protocol when implementations don't follow the original mechanisms and then demand to be treated as if what they implemented was correct. 
> 
> Brian
> 
> On Monday, September 19, 2016, Peterson, Jon <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
> 
> { “orig” : { “uri” : “sip:[email-masked] <>” }, “dest” : { “uri” : [ “sip:[email-masked] <>” ] } }
> 
> Even without Brian's hint, cases like this don't actually keep me up at night. And not just because, well, "destination.net <http://destination.net/>" probably isn't CompuServ and thus there's little chance it issues entirely-numeric usernames. It doesn't especially concern me because in order for a SIP request to actually be routed, you need to know whether it's just a telephone number, in which case you might drop it to any old gateway to the PSTN with equal effect, or if in fact you're expected to perform RFC3263 routing on the domain name part. Somehow, this works today without us adding any indicator to SIP to resolve any confusions. 
>

---

From: Alan Ford <[email-masked]>
Date: Tue, 20 Sep 2016 13:38:36 +0100

Hi Jon,

> On 19 Sep 2016, at 21:26, Peterson, Jon <[email-masked]> wrote:
> 
> 

I’m not sure which hint you are referring to here, if it’s the suggestion that the type of certificate should provide a clue, then that could only reliably be used when considering the source URI and does not guarantee how the destination URI would be canonicalised.

If you’re talking about user=phone, I may be misreading what Brian wrote, or misreading RFC3261/4967, but my understanding was that user=phone is to indicate a number really is a phone number? Sadly there are many devices out there which slap user=phone on every vaguely telephonic URI, irrespective of global routability. It’s certainly not reliable today. Furthermore, the sender may still have no idea whether the destination is a TN, so wouldn’t know whether to put user=phone on it.

Of course given we’re defining something new here, there is the (potential) opportunity to correct implementation and say user=phone MUST be present for it to be canonicalised as a TN, although sticking parameters on a To: address would be uncharted territory AFAIK.

>> - Sender’s PASSporT:
>> 
>> { “orig” : { “uri” : “sip:[email-masked] <sip:[email-masked]>” }, “dest” : { “uri” : [ “sip:[email-masked] <sip:[email-masked]>” ] } }
>> 
> Even without Brian's hint, cases like this don't actually keep me up at night. And not just because, well, "destination.net" probably isn't CompuServ and thus there's little chance it issues entirely-numeric usernames.

As I mentioned in an earlier mail, entirely-numeric user parts are actually very common in enterprise SIP deployments.

> It doesn't especially concern me because in order for a SIP request to actually be routed, you need to know whether it's just a telephone number, in which case you might drop it to any old gateway to the PSTN with equal effect, or if in fact you're expected to perform RFC3263 routing on the domain name part. Somehow, this works today without us adding any indicator to SIP to resolve any confusions. 

Indeed it does, given the receiving end only needs to look at the Request-URI to know what to do with it. The sender does not necessarily know what this action will be, however, or indeed what the receiver is. Is it an endpoint? A PBX? A B2BUA? This is the particular scenario above - the sender lives in a SIP-only world (enterprise with numeric aliases on every desk), Identity is attached and call is made. Once it gets to the far end, it’s actually routed to a TN - but the sender didn’t know this.

One specific example where this scenario could occur is in forking - if you use a service which forks a call to multiple destinations, some SIP endpoints, plus a PSTN number, then the verification service at the PSTN gateway may assume a destination is canonicalised as a TN but in fact was canonicalised as a SIP URI.

> SIP routing has some core ambiguities around using telephone numbers that it isn't the Identity header's job to rectify. But the important question is whether or not, in our threat model, we think…

I freely admit we are looking at this from different angles. My perspective is one of SIP ubiquity with external trunks and external PSTN gateways. An improved, deployable SIP Identity header is very appealing, but from a SIP-focused perspective to knowledge of what reliably is or is not a TN simply isn’t there at the sender.

> I would, perhaps, grudgingly, be willing to entertain normative guidance that states that if either orig or dest does not contain a "tn" identity then you MUST use "canon." That would avoid the rather weasel-y RFC3324ish proposed language about only sending "canon" when you psychically know the terminating side shares your canonicalization scheme. Even in my proposed form, I think it's overkill. But just hypothetically, would that resolve your concern? Or anyone else’s?

I was proposing weasel words in the hope it would be acceptable to everyone ;-)  But I'd be certainly happy with the above instead, although that seems a little overkill in comparison, with fewer get-out clauses for environments which would be confident they didn’t need canon!

Regards,
Alan

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 21 Sep 2016 04:27:32 +0000

There are all sorts of reasons why some of these would not work.

There are many reasons why one would use both PAI and From, and use them consistently! But there are also strong reasons why PAI is not present, or that From is obfuscated, on specific calls.

Networks may route calls on the the public network for eventually destination at another point in the same private network.

It is debatable whether short codes are actually telephone numbers, at least within E.164.

Keith

From: stir [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: 16 September 2016 18:46
To: Brian Rosen
Cc: [email-masked]; Paul Kyzivat; Alan Ford
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Henning

Cc: Alan Ford; Paul Kyzivat; [email-masked]<mailto:[email-masked]>

I think it probably would within the ATIS kind of environment, but Alan is talking about things that are beyond that: his example is a SIP URI from an enterprise PBX that doesn't have a phone number in the identity.

I personally think we need to get the PBX vendors on board as fast as we can in order to be able to support "authorized spoofing", like call centers calling on behalf of other enterprises.  I think getting the service providers to sign in those cases will be complicated, and if they can push the problem off to the call center, it will work out better.  So, I think its worth solving all/most of the problems the PBX folks think they have.

Having said that, the only circumstance I can think of where there is an identity like he is describing is an intra-enterprise call (possibly between sites, but within the same enterprise).  In those environments, identity spoofing is much harder to mount because the intra-enterprise traffic tends to be entirely within the corporate network, and they don't allow calls from sources they don't know.  Doesn't mean stir should not work, but it's pretty far down in my list of things to worry about.

Brian

Henning

Hi Paul,

> But there is also a brute force solution available to the validator: try validation using each of the supplied identities in turn until one validates or none do. While that might cost a bit of extr…

That's certainly true, but in my opinion the cost of bits is much cheaper than the cost of computation. What's more, a brute-force receiver could generate a modest denial-of-service attack vector - send a signature for something completely different, and let the verification service munch through cycles trying various combinations to see if any validate (they won't, of course). Minimum would be four combinations tried for just one src and one dest (trying tn: vs sip: combinations) - and this could be many more if you start to include other identifiers such as PAI or RPID. Whereas, if the canon was included, there would be one single crypto operation to verify the signature against known data.

Regards,
Alan

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 21 Sep 2016 12:24:33 +0000

Sanity check, Carriers have been normalizing crap numbers from enterprises since the dawn of time (older than me, and that's old)

From: stir [mailto:[email-masked]] On Behalf Of Drage, Keith (Nokia - GB)
Sent: Wednesday, September 21, 2016 12:28 AM
To: Henning Schulzrinne <[email-masked]>; Brian Rosen <[email-masked]>
Cc: [email-masked]; Paul Kyzivat <[email-masked]>; Alan Ford <[email-masked]>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Keith

From: stir [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: 16 September 2016 18:46
To: Brian Rosen
Cc: [email-masked]<mailto:[email-masked]>; Paul Kyzivat; Alan Ford
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Henning

Brian

Henning

Hi Paul,

Regards,
Alan