Subject: [Sip] Thoughts on gateways, user=phone, and the Identity/DTLS-SRTP problem

From: Dean Willis <[email-masked]>
Date: Sat, 12 Apr 2008 04:00:09 -0500

We've realized we have a specification mutual exclusion.

RFC 4474 as written precludes the insertion of an Identity header by  
an authentication service into a SIP message produced by a PSTN  
gateway. However, DTLS-SRTP as written needs such an Identity header  
in order to be able to verify that the media key fingerprint has not  
been altered by a MITM who is also attacking on the media path.

We've heard a bunch of suggestions, and so far I think the best has  
been to adopt a convention (and possibly a new extension) for encoding  
the From: header field in messages coming from gateways, along with a  
convention for interpreting Identity headers on those messages as  
"asserting the identity of the gateway", instead of "asserting the  
telephone number".

Someone suggested the idea of using a "user=phone" parameter as this  
indicator. I initially dismissed the idea. However, after reading  
Paul's recent analysis of what user=phone means (from his view,  
nothing), and in light of my counterexample (that the user=phone  
modifier can influence routing) I've reconsidered my earlier dismissal  
of the idea.

RFC 3261 Section 19.1.1 says:

          The set of valid telephone-subscriber strings is a subset of
          valid user strings.  The user URI parameter exists to
          distinguish telephone numbers from user names that happen to
          look like telephone numbers.  If the user string contains a
          telephone number formatted as a telephone-subscriber, the user
          parameter value "phone" SHOULD be present.  Even without this
          parameter, recipients of SIP and SIPS URIs MAY interpret the
          pre-@ part as a telephone number if local restrictions on the
          name space for user name allow it

If we made it mandatory for a PSTN gateway to assert identities using  
user=phone and documented that Identity headers over an identity with  
a user=phone parameter do not assert the "user part" of that identity,  
then I think we'd have a complete solution.

Corollary , we need to document that a "phone" UAS that is attached to  
the Internet does NOT use "user=phone" even if its user ID is a phone  
number and the ENUM entry for that phone number happens to point at  
this user ID at this UAS (or supporting domain).

In other words, we'd be changing the above text to say that the  
user=phone does NOT distinguish between phone numbers and user names,  
but that it distinguishes between phone numbers on the PSTN and SIP  
phone numbers or user IDs.

Let me restate: user=phone applies only to things that transit a PSTN  
gateway.

So for example if Alice at +12142821376 were to call Bob at  
+19725199190 (and where +19725199190 terminated on a gateway in domain  
example.com), we might see that gateway generate an INVITE like:

INVITE tel:+19725199190 SIP/2.0
From: sip:[email-masked];user=phone
To: tel:+19725199190
...

The authentication service at example.com could then reasonably insert  
an Identity header field. Receivers of this INVITE would know that the  
"user=phone" modifier implies that the Identity header asserts nothing  
whatsoever about the user part (+12142821376) of the request, and that  
the Identity header proves only that the request came from a gateway  
authenticated by example.com.

Alternatively the INVITE and TO might be populate with sip:[email-masked];user=phone 
, but I think it cleaner to document tel:

Also alternatively, the From: might be  sip:[email-masked];user=phone

Note that with this approach "tel:" does not mean "on the PSTN",  
rather it means "in the namespace of E.164", which is an entirely  
different thing. It is perfectly legitimate to use tel: URIs to refer  
to devices that are entirely on the Internet. In fact, this might be  
the model used if one enum device were to call another using an E.164  
number.

--
Dean

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Apr 2008 11:32:12 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
>

It's not just DTLS-SRTP fingerprints, it's non-SDP mime bodies as well.  For example the body of a MESSAGE request.  Middle-boxes have no need to change such bodies in transit, and we shouldn't want them to.  But as it stands right now, some middle-boxes would either break the signature or need to re-sign (if possible), simply because they modify the call-id.  It is debatable if changing the call-id has any real security implications for 4474, or if they're so minor that we're cutting off our nose to spite our face.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Apr 2008 12:40:05 -0400

>           name space for user name allow it

That last sentence is fascinating.  If I read it right, it basically allows me to treat a sip URI for my domain without the user=phone as a global E.164, if I so wish. (which so happens to be fairly common in my world)  Good, I feel better now. ;)

> this user ID at this UAS (or supporting domain).

There's a problem with that.  There are many "phone" UAS's which are ultimately reachable over the PSTN.  In fact, I would bet most of them are.  If the From of a request is used to store in one's address book, for later requests, then per Paul's desired behavior that later request could only be delivered over sip, or it should fail.

One would think if the original request were to be delivered by sip, then a request anytime later the other direction could as well.  But that's not the case.  For one, transit peering arrangements are not symmetrical, and it's totally possible that calls across providers in one direction go sip the whole way, but calls the other direction cross the PSTN or H.323 or whatever.  For another, many enterprises have "PSTN fallback" abilities, so that if their SIP trunks fail for some reason, there is a PRI-type backup.

But this issue is somewhat orthogonal to your proposal.  And it's leading me to think that we cannot reasonably have a "if sip: then only SIP" behavior solely based on scheme, as Paul seems to feel is currently implied (I think).

-hadriel

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sun, 13 Apr 2008 17:35:23 -0500

There is fall back in the circuit switched world, never mind IP over
lays for enterprise. 

> this user ID at this UAS (or supporting domain).

There's a problem with that.  There are many "phone" UAS's which are
ultimately reachable over the PSTN.  In fact, I would bet most of them
are.  If the From of a request is used to store in one's address book,
for later requests, then per Paul's desired behavior that later request
could only be delivered over sip, or it should fail.

One would think if the original request were to be delivered by sip,
then a request anytime later the other direction could as well.  But
that's not the case.  For one, transit peering arrangements are not
symmetrical, and it's totally possible that calls across providers in
one direction go sip the whole way, but calls the other direction cross
the PSTN or H.323 or whatever.  For another, many enterprises have "PSTN
fallback" abilities, so that if their SIP trunks fail for some reason,
there is a PRI-type backup.

But this issue is somewhat orthogonal to your proposal.  And it's
leading me to think that we cannot reasonably have a "if sip: then only
SIP" behavior solely based on scheme, as Paul seems to feel is currently
implied (I think).

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Apr 2008 21:47:12 -0400

> That last sentence is fascinating.  If I read it right, it basically allows me to treat a sip URI for my domain without the user=phone as a global E.164, if I so wish. (which so happens to be fairl…

If this is news to you, then you guys really lucked out. :-)

> There's a problem with that.  There are many "phone" UAS's which are ultimately reachable over the PSTN.  In fact, I would bet most of them are.  If the From of a request is used to store in one's…

I'm not so rigid as to think gailure is the best option.
I can see the conversion from sip to tel as a heuristic to recover from 
failure to reach the destination via the sip URI in normal ways. It 
woujld require some thought to decide which particular errors would make 
sense to retry in this way.

But I do think one ought to attempt to honor the intent of the provider 
of the URI. IMO 3263 is pretty clear about how a sip uri is to be routed.

> One would think if the original request were to be delivered by sip, then a request anytime later the other direction could as well.  But that's not the case.  For one, transit peering arrangements…

I'm not getting your point. Return routing will be based on a different 
URI provided by the other party. All this discussion applies to that as 
well. Whether reverse routing is possible is irrelevant here.

> But this issue is somewhat orthogonal to your proposal.  And it's leading me to think that we cannot reasonably have a "if sip: then only SIP" behavior solely based on scheme, as Paul seems to feel…

Yes, I think that is implied. And subject to some possible fallback 
behavior I think it is a good thing, as long as we have a uri (tel) that 
covers the cases when that isn't the the appropriate.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Apr 2008 23:21:31 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
>

Yes, but I'm not clear which part of 3263 *isn't* being honored.  You set your req-uri to sip:[email-masked], it reaches example.com, example.com says "hmm, not one of my users, I'll consider this a telephone number, and try the SIP-trunk or PSTN or whatever".  It reached the intended sip target domain (example.com).

> [snipped stuff]

Dean had said we would need to get "phones" to NOT use "user=phone", while GW's do - both using a sip: From.  I had thought you were saying a sip scheme demands a SIP path be used.  So my point was that just because I can get a SIP request to sip:[email-masked], with a signed From of sip:[email-masked], and you store that in your address book, does not mean you can then 2 days later get a request to sip:[email-masked] to stay SIP to me.  It does not mean I wanted to only be reachable by SIP, and it does not mean *you* (the human) only want to reach me via SIP when you send it.  That's all - just reiterating the same as before really.  Nothing to see here, move along... :)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Apr 2008 00:28:14 -0400

> Yes, but I'm not clear which part of 3263 *isn't* being honored.  You set your req-uri to sip:[email-masked], it reaches example.com, example.com says "hmm, not one of my users, I'll consider this…

I have absolutely *no* problem with that, *if* it reaches example.com 
before being translated. That is policy business between you and your 
home proxy.

I have a problem when it passes through foo.com which then decides this 
is a phone number and routes it to a GW without it ever going to 
example.com. And I am hearing you (I think) and others saying that is 
common practice and in fact necessary in many cases for calls not to fail.

> Dean had said we would need to get "phones" to NOT use "user=phone",
> while GW's do - both using a sip: From. 

That is a somewhat interesting proposal. But it does change the existing 
semantics of user=phone. So I hope we can keep that as a separate 
discussion.

> I had thought you were saying
> a sip scheme demands a SIP path be used. 

I believe it does, just as much as sips demands that a sips path be 
used, http demands that an http path be used, etc.

If somebody gives you an http URL, do you think it is an intended usage 
for you to transform it into an ftp URL?

It in fact may work to transform the http into an ftp URL. But if so 
that is a special case that can only be known to work based on extra 
context.

In the case of sip, we might say that user=phone is provides that extra 
context. IMO that is still just a heuristic, not a standard behavior. If 
we want it to be a sanctioned standard behavior then we need to write 
some new specs.

> So my point was that just
> because I can get a SIP request to sip:[email-masked], with a signed
> From of sip:[email-masked], and you store that in your address
> book, does not mean you can then 2 days later get a request to
> sip:[email-masked] to stay SIP to me. 

Well, there are no *guarantees*.

But IMO you ought not to be using that as your From address if you 
*expect* callbacks to work and you don't at least *expect* that the 
returns will work via an all-sip path. If you don't think so, then IMO 
you ought to put a TEL URI in the From.

> It does not mean I wanted
> to only be reachable by SIP, and it does not mean *you* (the human) only
> want to reach me via SIP when you send it.  That's all - just reiterating
> the same as before really.  Nothing to see here, move along... :)

I disagree. IMO this is indeed the true distinction between sip and tel.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 14 Apr 2008 01:16:24 -0400

> > Yes, but I'm not clear which part of 3263 *isn't* being honored.  You
> set your req-uri to sip:[email-masked], it reaches example.com,
> example.com says "hmm, not one of my users, I'll consider this a telephone
> number, and try the SIP-trunk or PSTN or whatever".  It reached the
> intended sip target domain (example.com).
>

Ahhh... crap, we were talking past each other.  No, it is not common usage afaik for a sip request to example.com to be shunted to the PSTN by foo.com.

It may well be that's what would happen, but as far as I know it's incredibly rare for foo.com to get a request for example.com to begin with.  Because afaict no one knows what "final" target domain to set for the req-uri, other than their local enterprise's or provider's, who then changes it to their next-hop domain, and so on.  This works, because they're really all "routing" based on phone numbers at the end of the day.  [I am ignoring the visited proxy model, because such roaming is still rare in SIP afaik]

If a request for example.com were to arrive at foo.com, and it accepted it, I still think it could try it to the PSTN if example.com were a customer of foo.com's and the number was one of example.com's. (ie, if foo.com was a provider and had a pstn-fallback service for its enterprise customer example.com)  But that's probably a nit?

> used, http demands that an http path be used, etc.

Interestingly, I had thought we decided sips did not carry that semantic a long time ago - if you set the req-uri to sips:[email-masked], and it reached example.com over TLS, example.com formed the end of that URI domain and could send it into the PSTN or whatever at will.

> that is a special case that can only be known to work based on extra

If someone set an http URL, I would expect it to be HTTP to the target domain of that URL.  But that web server could use FTP behind the scenes to retrieve its data to feed to you over HTTP, or could use TFTP, or NFS, or any protocol of its choosing.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Apr 2008 16:08:48 -0500

On Apr 13, 2008, at 10:21 PM, Hadriel Kaplan wrote:
> Yes, but I'm not clear which part of 3263 *isn't* being honored.   
> You set your req-uri to sip:[email-masked], it reaches  
> example.com, example.com says "hmm, not one of my users, I'll  
> consider this a telephone number, and try the SIP-trunk or PSTN or  
> whatever".  It reached the intended sip target domain (example.com).
>

Which might also have a user "123456789", resulting in the delivery of  
that call to the user, rather than the phone number.

--
Dean

---

From: Ben Campbell <[email-masked]>
Date: Fri, 18 Apr 2008 16:38:52 -0500

On Apr 12, 2008, at 4:00 AM, Dean Willis wrote:

[...]

> then I think we'd have a complete solution.

[...]

I think you would need to extend that to be PSTN gateways that do not  
do some sort of caller authentication. As we discussed separately,  
it's perfectly possible for a PSTN gateway to require a PIN from a  
caller, and therefore be able tp assert a stronger identity than it  
could from caller id. In that scenario, would you expect the  
"user=phone" parameter to apply?

---

From: Dean Willis <[email-masked]>
Date: Fri, 18 Apr 2008 18:30:31 -0500

On Apr 18, 2008, at 4:38 PM, Ben Campbell wrote:

> I think you would need to extend that to be PSTN gateways that do  
> not do some sort of caller authentication. As we discussed  
> separately, it's perfectly possible for a PSTN gateway to require a  
> PIN from a caller, and therefore be able tp assert a stronger  
> identity than it could from caller id. In that scenario, would you  
> expect the "user=phone" parameter to apply?
>

How would you differentiate an an authenticating gateway from a non- 
authenticating gateway downstream?

--
Dean

---

From: Ben Campbell <[email-masked]>
Date: Fri, 18 Apr 2008 18:44:41 -0500

> authenticating gateway downstream?

That's rather the problem.

My point is, although there is a lot of correlation between "phone  
numbers" and "unauthenticated callers", it doesn't always have to be  
that way. We also assume that calls crossing non-PSTN gateways will  
have better authentication properties, but it doesn't have to be that  
way either. Unless we remove all historical meaning from "user=phone",  
then using it would codify assumptions that are not necessarily true.

If we decide that we need a way to signal that an identity assertion  
is weak, then I think we need a way to do it that is orthogonal to  
whether the call originated the PSTN.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip