Subject: Re: [Sip] Securing Other URI (Tel URI) scheme

From: Scott Lawrence <[email-masked]>
Date: Mon, 02 Apr 2007 12:15:12 -0400

On Tue, 2007-03-27 at 14:38 -0500, Samir Srivastava wrote:
> Changed the subject.
> 
> But the UAC wanted its Tel Uri Request to traverse securely on the
> intermediate hops. How it can enforce that?    

The only real utility of the tel uri is for addressing something through
the PSTN.  Once you've crossed that boundary, the security is
meaningless anyway, so there is little point it protecting it in the sip
in the first place.

Using a tel uri for end-to-end sip has no advantage over a sip uri, so
if you're going to do that anyway, you have sips available to protect
it.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

_______________________________________________
Sip mailing list  https://www1.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: [email-masked] (Juha Heinanen)
Date: Mon, 2 Apr 2007 19:19:57 +0300

> meaningless anyway, so there is little point it protecting it in the sip

security is meaningless unless it is end-to-end.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Apr 2007 13:10:30 -0400

> if you're going to do that anyway, you have sips available to protect

If I give you a TEL URI, it presumably means that I am *reachable* at 
that number via the PSTN. I may also be reachable directly via SIP, 
using ENUM for the mapping. Giving you the TEL maximizes the options you 
have to reach me.

Now you may want to reach me via SIP, and to do so securely. If you do 
the ENUM lookup yourself then you can discover if there is a SIPS 
mapping and use it. That doesn't require TELS.

Alternatively, you may want to delegate the ENUM processing to your SP. 
Then the question is whether you can then also say that you want a 
secure call. One possible way is for you to convert the TEL uri to a 
SIPS URI with user=phone and with the domain of your own SP. This will 
only work if the SP agrees to provide this feature. In that case, it 
would first check to see if this is an address it hosts. If so it would 
map it appropriately. If not, it may choose to do you the benefit of 
doing an ENUM lookup for you. If that succeeds, because the incoming 
request was SIPS it should only choose a translation that is also SIPS, 
and then route the call to that.

If there is no ENUM translation for the number, it *could* decide to 
route the call to the PSTN. Then you will get whatever security the PSTN 
provides.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 2 Apr 2007 12:34:40 -0500

Exactly. 

> -----Original Message-----
> From: Scott Lawrence [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 09:15
> To: Srivastava, Samir (SC100:8826)
> Cc: Audet, Francois (SC100:3055); IETF SIP List; Dean Willis
> Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
> 
> The only real utility of the tel uri is for addressing 
> something through the PSTN.  Once you've crossed that 
> boundary, the security is meaningless anyway, so there is 
> little point it protecting it in the sip in the first place.
> 
> Using a tel uri for end-to-end sip has no advantage over a 
> sip uri, so if you're going to do that anyway, you have sips 
> available to protect it.
> 
> --

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 2 Apr 2007 13:21:17 -0500

With what level of security using 40 bit ciphers, who is stopping them
not to use that ?

Tel is just one example what about im:, pres: etc... 

Thx
Samir

>
>Using a tel uri for end-to-end sip has no advantage over a sip 
>uri, so if you're going to do that anyway, you have sips 
>available to protect it.
>
>--

---

From: Dean Willis <[email-masked]>
Date: Mon, 2 Apr 2007 13:35:05 -0500

> security is meaningless unless it is end-to-end.

I keep my money in a secure bank, but occasionally I take some of it  
out as cash, put it in my wallet, and walk to the store with it. The  
security provided by the bank ends when I withdraw the cash.

Was that security meaningless?

Similarly, with sips.

I might be working from a hotel owned by my competitor in a country  
owned by my competitor (I think big -- judge a man not by his  
friends, but by his competitors). From here, I would like to call  
into a conference bridge back at my office. Some of the other users  
calling into the conference bridge will be calling over the PSTN in a  
country not owned by me competitor.

So I might use a VPN client back to my office, and place the call  
over that into the conference bridge.

Does the fact that other people are calling into the bridge using  
unsecured PSTN lines render the security provided by the VPN  
meaningless?

Security always has to be evaluated with respect to a threat. No  
single security mechanism can address all threats. Using the wrong  
mechanism for a specific threat can be worse than useless.

There do appear to be a subset of problems for which sips:, as  
documented by Francois Audet, seems to be useful. I accept that we  
have not clearly explained that subset, and that a larger subset  
exists for for which sips: is arguably not useful. However, there do  
appear to be people using sips: somewhat appropriately, and I think  
we owe them a clarification of that specification so that they can  
have a greater chance of using it successfully.

I also think we need to develop other mechanisms for other subsets of  
the problem space, and that we need to be far more clear about the  
usage of each mechanism and the appropriateness of those mechanisms  
for different sorts of threats.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 2 Apr 2007 13:56:17 -0500

On Apr 2, 2007, at 1:35 PM, Dean Willis wrote:

>
> There do appear to be a subset of problems for which sips:,

Eek! Call the grammar police.

"There does appear. . ."

My bad.

--
dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Apr 2007 15:25:45 -0400

Amen!

	Paul

Dean Willis wrote:
> I keep my money in a secure bank, but occasionally I take some of it out 
> as cash, put it in my wallet, and walk to the store with it. The 
> owned by my competitor (I think big -- judge a man not by his friends, 
> but by his competitors). From here, I would like to call into a 
> conference bridge back at my office. Some of the other users calling 
> into the conference bridge will be calling over the PSTN in a country 
> not owned by me competitor.
> 
> So I might use a VPN client back to my office, and place the call over 
> that into the conference bridge.
> 
> unsecured PSTN lines render the security provided by the VPN meaningless?
> 
> Security always has to be evaluated with respect to a threat. No single 
> security mechanism can address all threats. Using the wrong mechanism 
> for a specific threat can be worse than useless.
> 
> documented by Francois Audet, seems to be useful. I accept that we have 
> not clearly explained that subset, and that a larger subset exists for 
> for which sips: is arguably not useful. However, there do appear to be 
> people using sips: somewhat appropriately, and I think we owe them a 
> clarification of that specification so that they can have a greater 
> chance of using it successfully.
> 
> the problem space, and that we need to be far more clear about the usage 
> of each mechanism and the appropriateness of those mechanisms for 
> different sorts of threats.
> 
> -- 
> Dean
>  
>

---

From: Michael Thomas <[email-masked]>
Date: Mon, 02 Apr 2007 12:33:15 -0700

I'm sorry, but this is dangerous. If I am using an open access point 
with no WEP
using SIP and no TLS back to a PSTN gateway to call somebody, that the 
adding
TLS provides no utility? This is just plain wrong.

This attitude about the PSTN being "insecure" misses a vital point: 
insecure
compared to _what_? IMO, IP should be viewed as less secure than the PSTN
until proven otherwise. There are far more threats and far fewer 
barriers to
exploit them.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Mon, 2 Apr 2007 14:46:36 -0500

On Apr 2, 2007, at 2:33 PM, Michael Thomas wrote:

> I'm sorry, but this is dangerous. If I am using an open access  
> point with no WEP
> using SIP and no TLS back to a PSTN gateway to call somebody, that  
> the adding

The counter argument is that, by the conventions established in  
Francois' draft, is that IF your SIP ua and proxy chain can do TLS,  
it WILL do TLS whether you use "sips/tels" or not. You don't have to  
ask for it. Or, from another perspective, any time you send a request  
you are asking for that request to be sent via TLS to the extent  
possible.

> until proven otherwise. There are far more threats and far fewer  

By the current accord, the only reason to use sips: is to say "If you  
can NOT do this using TLS end to end, then please reject this request."

If you are referring a tel: URL, you are asking somebody to make a  
phone call to a destination specified using PSTN numbering.  
Presumably, this is because you don't know enough about their  
topology to know whether they can make that call using TLS or not.  
They might even make it by sending DTMF over a TDM link -- you have  
no way of knowing.

So, one might argue, it doesn't make a lot of sense to tell them they  
have to make the call using TLS end-to-end.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Mon, 02 Apr 2007 13:27:27 -0700

Dean Willis wrote:
> Francois' draft, is that IF your SIP ua and proxy chain can do TLS, it 
> WILL do TLS whether you use "sips/tels" or not. You don't have to ask 
> for it. Or, from another perspective, any time you send a request you 
> are asking for that request to be sent via TLS to the extent possible.

This isn't counter, it's subverted by the original assertion:

 > The only real utility of the tel uri is for addressing something 
through the PSTN.  Once you've > crossed that boundary, the security is 
meaningless anyway, so there is little point it protecting it
                                                                                                  
^^^^^^^^^^^^^^^^^^^^^^^^^^^
 > in the sip in the first place.
   ^^^^^^^^^^^^^^^^^^^^^

It pains me greatly to stick up for the security of the PSTN, but using 
"secure" in
an absolute sense as is being done here is harmful. The attitude we 
should have is
that we want to affect what we can affect and leave the comparisons of 
risk to
somebody who can actually make them. Which is why I think making any 
distinction
at all as to what is on the other side of a SIPS gateway is wrong too, 
and I think is
at the root of this kind of misconception.

       Mike

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 02 Apr 2007 20:25:06 +0000

> By the current accord, the only reason to use sips: is to say 
> "If you can NOT do this using TLS end to end, then please 
> reject this request."

So any call originating sips: that terminates to the PSTN, must be
rejected?  Even if it can be secured from originating UA to the PSTN
gateway via TLS?  That seems like a good way to depracate sips: since
nobody will want to use it.

Suppose a network is capable of TLS but doesn't use it unless asked.
Maybe this is an enhanced service they charge for, or maybe they're just
conserving resources.  Anyway suppose you are (like most people, this
list excluded) reasonably comfortable with PSTN security but nervous
about Internet security.  You might like a secured session across the
VoIP portion of your calls to your friends whose access is via the PSTN.
How do you get it?  You start by specifying a sips: URI.  Per my
understanding of this "accord" the network rejects the session request
because it terminated at a PSTN gateway.  Your UA retries without sips:
but due to network policy you don't get TLS (because you didn't ask for
it).

Seems broke to me.

tim

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 2 Apr 2007 16:37:13 -0500

> So any call originating sips: that terminates to the PSTN, 
> must be rejected?  Even if it can be secured from originating 
> UA to the PSTN gateway via TLS?  That seems like a good way 
> to depracate sips: since nobody will want to use it.

No, we did not agree to do this. 

When you are outside the SIP network, it's out of scope  of SIPS. You
can
do whatever you want.

> Maybe this is an enhanced service they charge for, or maybe 
> they're just conserving resources.  Anyway suppose you are 
> (like most people, this list excluded) reasonably comfortable 
> with PSTN security but nervous about Internet security.  You 
> might like a secured session across the VoIP portion of your 
> calls to your friends whose access is via the PSTN.
> How do you get it?  You start by specifying a sips: URI.  Per 
> my understanding of this "accord" the network rejects the 
> session request because it terminated at a PSTN gateway.  
> Your UA retries without sips:
> but due to network policy you don't get TLS (because you 
> didn't ask for it).

As the operator of the PSTN gateway, you can decide to use 
SIPS all the way to the PSTN gateways if that satisfies your
security needs.

SIPS just means that IN THE SIP DOMAIN, you forward everything
on TLS (hop-by-hop).

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 02 Apr 2007 22:05:57 +0000

> No, we did not agree to do this. 

But that's what Dean said.

> When you are outside the SIP network, it's out of scope  of 
> SIPS. You can do whatever you want.
> 
> > Maybe this is an enhanced service they charge for, or maybe they're 
> > just conserving resources.  Anyway suppose you are (like most
people, 
> > this list excluded) reasonably comfortable with PSTN security but 
> > nervous about Internet security.  You might like a secured session 
> > across the VoIP portion of your calls to your friends whose access
is 
> > via the PSTN.
> > but due to network policy you don't get TLS (because you didn't ask 
> > for it).
> 
> SIPS just means that IN THE SIP DOMAIN, you forward 
> everything on TLS (hop-by-hop).

Of course.  In my example I am provider of both "the SIP domain" and the
PSTN gateways.  I am surprised to hear that I must reject sips: calls
that terminate on my PSTN gateway, because of some "accord" that I am
told exists.

Tim

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 2 Apr 2007 17:25:09 -0500

In-line.

Thx
Samir

>From: Dean Willis [mailto:[email-masked]] 
>Sent: Monday, April 02, 2007 11:35 AM
>To: Juha Heinanen
>Cc: IETF SIP List; Audet, Francois (SC100:3055)
>documented by Francois Audet, seems to be useful. I accept 
>that we have not clearly explained that subset, and that a 
>larger subset exists for for which sips: is arguably not 
>useful. However, there do appear to be people using sips: 
>somewhat appropriately, and I think we owe them a 
>clarification of that specification so that they can have a 
>greater chance of using it successfully.

With all respect I have to state that "I don't think there is even a
chance of using it successfully without users being informed of what
level of security is provided. Feature sets are broken too, even if I
accept that proxies are trusted to use the correct set of ciphers (AES
128) in this case. The more we try to patch it, the more problems we are
inviting. 

You seem to be agreeing that SIPS is largely not useful. Can you
quantify this, which can lead us to DEPRECATE SIPS. 

I want to avoid the islands of current SIPS as defined currently in the
coming future, as we will be having a large battle then to fix when
request goes through currently defined SIPS islands (Similar to PSTN
clouds) Where we don't know what is happening ? We will have another
beast to interoperate. 

>
>I also think we need to develop other mechanisms for other 
>subsets of the problem space, and that we need to be far more 
>clear about the usage of each mechanism and the 
>appropriateness of those mechanisms for different sorts of threats.

Thx for agreeing on this.

>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 3 Apr 2007 07:45:23 +0300

> topology to know whether they can make that call using TLS or not.

the reason is that i don't know their pstn gateway provider.  if they
can use tls or not i don't know either, but the same holds true even if
i would refer them to a sips uri.

 > have to make the call using TLS end-to-end.

that is referer's judgement.  if referer does not want that the call is
made using tls or not made at all, then referer needs to use sips or tels and
we need to support both of them or neither.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Tue, 03 Apr 2007 00:01:17 -0500

> at the root of this kind of misconception.

You're probably right there.

But does this mean that we need a tels: URI scheme, or are you just 
saying my argument smells funny?

--
dean