Subject: [stir] stir-06: canonicalization

From: Eric Burger <[email-masked]>
Date: Thu, 10 Dec 2015 21:15:59 -0500

Section 6.1.1, Canonicalization, states
      First, implementations must assess if the user-portion of the URI
      constitutes a telephone number.  In some environments, numbers
      will be explicitly labeled by the use of TEL URIs or the
      'user=phone' parameter, or implicitly by the presence of the '+'
      indicator at the start of the user-portion.  Absent these
      indications, if there are numbers present in the user-portion,
      implementations may also detect that the user-portion of the URI
      contains a telephone number by determining whether or not those
      numbers would be dialable or routable in the local environment [EB1] --

Unless the user part is marked as a telephone number (;user=tel, tel URI), there is NO way of knowing without out-of-band knowledge the user part is supposed to be a telephone number or not. There is no restriction on SIP user names that they cannot be an arbitrary string of characters that happen to be six to fifteen digits. I would suggest we just say that some proxies 'know' their UAC's present some form of telephone numbers or extensions.

Anyone disagree?

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Dec 2015 11:02:19 -0500

> Unless the user part is marked as a telephone number (;user=tel, tel URI), there is NO way of knowing without out-of-band knowledge the user part is supposed to be a telephone number or not. There…

You can't assume that an arbitrary proxy will know.

The way I think of it is that this has to be a policy linked to the 
domain of the URI. A proxy for that domain might be expected to know the 
policy. Proxies for other domains might happen to know but can't be 
expected to. The key point is that knowing is a prerequisite for doing 
the canonicalization.

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Fri, 11 Dec 2015 18:40:53 -0500

> On Dec 11, 2015, at 11:02 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> The way I think of it is that this has to be a policy linked to the domain of the URI. A proxy for that domain might be expected to know the policy. Proxies for other domains might happen to know but can't be expected to. The key point is that knowing is a prerequisite for doing the canonicalization.
> 
> 	Thanks,

So really, this is a 100% local matter and not subject to specification. Perhaps say so? Like, “If you have local numbers, it is silly to sign authority for the number.”?

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 Dec 2015 00:27:09 -0500

> So really, this is a 100% local matter and not subject to specification. Perhaps say so? Like, “If you have local numbers, it is silly to sign authority for the number.”?

You lost me here. I think you are conflating two different things:

1) non tel-format representation of E.164 numbers,
2) local numbers

I think (1) is the easier problem. You expect that the signing will be 
done by something in the domain of the caller, who knows the policy for 
representing numbers.

In that case the only problem is how the number is canonicalized by the 
callee. Given the stir solution, the canonicalized number will be passed 
along, making that easier. But even without that this problem gets 
solved. If the call passes out of the domain of the caller the To- and 
From- URIs are often rewritten by an SBC into a form that will be 
understood by the domain on the other side of the SBC.

Local numbers are a different problem. And there we have multiple cases:

3) service numbers
4) "real" local numbers that have no E.164 equivalent

Service numbers are the only ones the draft currently discusses. For 
these there is some general agreement of what dial strings are used. But 
AFAIK there is no general agreement on how they should be represented as 
URIs.

- One way is simply a sip dial-string URI. E.g.,
     sip:411;phone-context=[email-masked];user=dialstring
- Another is to use the tel local-number format. E.g.,
     sip:411;phone-context=[email-masked];user=phone
- And I guess sometimes it will just be:
     sip:[email-masked]

The problem is, regardless of which is used, we have no clear definition 
of what the canonicalized format should be for stir.

Also, for those using phone-context there is no standard for what 
context value to use.

And finally, who is allowed to sign a service number?

Regarding the "real" local numbers: they really have well defined 
meaning once they leave their domain. So I see no point in signing the 
as *numbers*. They can still be signed as non-numeric URIs.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 15 Dec 2015 18:23:21 +0000

At a high level, canonicalization needs to work such that both the
authentication service and verification service can perform the
canonicalization algorithm on the value of the From/PAI and arrive at
exactly (like, bit-exactly) the same response. If it doesn't have this
property, then we've failed. So we can't say that this is just a matter of
local policy on the originating side.

So, what if the original form of the number in the PAI or From header
field is so messed up, so unhelpful, that only an entity in the
originating domain could understand how to canonicalize it? Then it
becomes the responsibility of the originating domain to include "canon" so
that there's some hope the verification service can at least understand
what was signed. But this doesn¹t help as much as it might seem. If the
verification service cannot establish the relationship between the number
in the "canon" and that in the PAI/From, it will not be able to
distinguish this signed request from a cut-and-paste attack where someone
has grabbed a random JWT from a different number and attached it to this
call. This is why ultimately, we have to leave the door open to B2BUAs
that change the number in the From/PAI to something more helpful.

But we also need to uplevel and acknowledge that networks that handle
numbers in a very unusual way face a lot of further challenges
interoperating with other networks, when it comes to number routing and
related functions. If the outside world can't tell whether what you're
signing is a telephone number or not, your operational practices may not
be compatible with a public identity system like STIR is envisioning. We
can't design a system that will work for every contingency, but I think
our canonicalization proposal is adequate to handle the use cases that
matter.

Jon Peterson
Neustar, Inc.

On 12/11/15, 9:27 PM, "stir on behalf of Paul Kyzivat"
<[email-masked] on behalf of [email-masked]> wrote:

>>>> Unless the user part is marked as a telephone number (;user=tel, tel
>>>>URI), there is NO way of knowing without out-of-band knowledge the
>>>>user part is supposed to be a telephone number or not. There is no
>>>>restriction on SIP user names that they cannot be an arbitrary string
>>>>of characters that happen to be six to fifteen digits. I would suggest
>>>>we just say that some proxies 'know' their UAC's present some form of
>>>>telephone numbers or extensions.
>>>
>>>domain of the URI. A proxy for that domain might be expected to know
>>>the policy. Proxies for other domains might happen to know but can't be
>> So really, this is a 100% local matter and not subject to
>>specification. Perhaps say so? Like, ³If you have local numbers, it is
>>silly to sign authority for the number.²?
>
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Dec 2015 13:43:31 -0500

> our canonicalization proposal is adequate to handle the use cases that

Well, this bit started in a discussion of * and #. But they have no role 
in E.164 numbers. Is this document intended to work for non-E.164 
numbers? If so, ISTM that it needs to specify some canonical form for 
such numbers so that the two ends can agree. The obvious way would be 
the tel-uri local-number format. But that includes stuff that this draft 
doesn't allow.

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Tue, 15 Dec 2015 20:31:24 -0500

I think Paul says it better than I can. If the thing you are canonicalizing is anything but an E.164 number (or unambiguously translates to an E.164 number), then the thing is out of scope. If anything, rather than talking about how to canonicalize a non-E.164 number (#’s and *’s), we should be talking about how STIR will not work for non-E.164 thingies.

> On Dec 15, 2015, at 1:43 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Well, this bit started in a discussion of * and #. But they have no role in E.164 numbers. Is this document intended to work for non-E.164 numbers? If so, ISTM that it needs to specify some canonical form for such numbers so that the two ends can agree. The obvious way would be the tel-uri local-number format. But that includes stuff that this draft doesn't allow.
> 
> 	Thanks,
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 19 Dec 2015 15:25:48 -0500

> I think Paul says it better than I can. If the thing you are canonicalizing is anything but an E.164 number (or unambiguously translates to an E.164 number), then the thing is out of scope. If anyt…

Thing is, it appears that there are *some* non-E.164 things (e.g. 911) 
for which a signature is important. (At least when the non-E.164 thingie 
is in To.)

Perhaps in such cases the canonicalized form of the To-URI could be the 
whole URI. But that would only work if it isn't rewritten along the call 
path.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Mon, 21 Dec 2015 11:03:04 -0500

I think canonicalization of service numbers is very strait forward.  I think that URNs are trivial.  I think that we should allow other things, but with no canonicalization, i.e. the whole URI, but with the warning that rewrites might screw things up.  Actually, I take that back a bit - we should canonicalize URIs by lowercasing scheme and host.

Brian

> On Dec 19, 2015, at 3:25 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Thing is, it appears that there are *some* non-E.164 things (e.g. 911) for which a signature is important. (At least when the non-E.164 thingie is in To.)
> 
> Perhaps in such cases the canonicalized form of the To-URI could be the whole URI. But that would only work if it isn't rewritten along the call path.
> 
> 	Thanks,
> 	Paul
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>