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

From: Cullen Jennings <[email-masked]>
Date: Sat, 31 Mar 2007 23:55:28 -0700

I will also add that a sips URI can occur place other than the  
request URI - for example, a Refer-To header field value.  In this  
case a proxy require will not capture the required semantics. This  
has all been discussed before.

On a side note, a great way to get sips protection for a tel URL is  
convert it from a tel to sips.

Cullen <with my individual hat on>

On Mar 27, 2007, at 4:31 PM, Francois Audet wrote:

> The answer was, "yes, it has been considered".
>
> But it has been determined that it would cause more harm to change  
> from
> SIPS to another mechanism at
> this point, because of the precedent in RFC 3261.
>
> It's probably somewhere in the archives for and various reports.

_______________________________________________
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: Sun, 1 Apr 2007 10:40:49 +0300

> convert it from a tel to sips.

how can i refer-to or 302 someone securely to pstn without tels?  if i
would use sips, i cannot place my my own domain in the uri.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 1 Apr 2007 18:48:24 -0500

Yes, and unlike Tel, you can also apply RFC 4474 to sip and sips URI. 

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Saturday, March 31, 2007 23:55
> To: Audet, Francois (SC100:3055)
> Cc: Christer Holmberg ((JO/LMF)); IETF SIP List
> Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
> 
> 
> I will also add that a sips URI can occur place other than 
> the request URI - for example, a Refer-To header field value. 
>  In this case a proxy require will not capture the required 
> semantics. This has all been discussed before.
> 
> On a side note, a great way to get sips protection for a tel 
> URL is convert it from a tel to sips.
> 
> > from SIPS to another mechanism at this point, because of 
> the precedent 
> > in RFC 3261.
> >

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 1 Apr 2007 18:49:46 -0500

You would use that of the service provider.

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Sunday, April 01, 2007 00:41
> To: Cullen Jennings
> Cc: Audet, Francois (SC100:3055); IETF SIP List; Christer 
> Holmberg ((JO/LMF))
>  > On a side note, a great way to get sips protection for a 
> tel URL is  > convert it from a tel to sips.
> 
> how can i refer-to or 302 someone securely to pstn without 
> tels?  if i would use sips, i cannot place my my own domain 
> in the uri.
> 
> -- juha
>

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 1 Apr 2007 18:48:24 -0500

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 1 Apr 2007 18:49:46 -0500

---

From: "Samir Srivastava" <[email-masked]>
Date: Sun, 1 Apr 2007 19:29:19 -0500

Hi,

   I may be missing the point here. Proxy-Require tag will make the
individual REFER routing secure, while the additional tag in the Require
header will make sure that UAS generate the further requests as a result
of REFER method securely.

   Pl correct me, if I am missing something.

   What will be done with the REPLACES header? Whether a dialog created
with SIPS can be considered SECURE for the replacement with unsecure
dialog ? We need a REQUIRE tag for all feature control.

Thx
Samir

>Sent: Saturday, March 31, 2007 11:55 PM
>Cc: IETF SIP List; Christer Holmberg ((JO/LMF))
>request URI - for example, a Refer-To header field value.  In 
>this case a proxy require will not capture the required 
>> from SIPS to another mechanism at this point, because of the 
>precedent 
>> in RFC 3261.
>>
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: Dean Willis <[email-masked]>
Date: Sun, 1 Apr 2007 21:56:43 -0500

But I don't know who his service provider is. So how can I know how  
to populate the domain-part of the request?

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 2 Apr 2007 08:52:49 +0300

> You would use that of the service provider.

which service provider?  i don't have any idea how someone who calls me
reaches pstn.  so please tell me how i can refer or 302 someone securely
to my pstn number.  if you don't have a good answer, please include tels
in your i-d.

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 2 Apr 2007 09:12:26 +0200

Hi, 

>URL is convert it from a tel to sips.

Then, why do we need tel in the first place?

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 2 Apr 2007 10:38:07 +0300

> Then, why do we need tel in the first place?

the only reason that i have found is the refer/302 problem to pstn.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Apr 2007 07:58:46 -0400

IMO you may use the domain of any provider that will be willing to route 
the call to the proper destination. E.g. you could use your own provider 
if you have one and it does this. (I realize this is a bit controversial 
- not all agree this is a proper usage.)

However this will not guarantee you will get a secure call to a 
destination on the PSTN. Once the call leaves the sip network all bets 
are off.

IMO a key value of TEL is that it does not dictate the protocol used to 
reach the destination, whereas a sip/sips URI does. In theory a TELS URI 
could specify a requirement to reach a destination securely without 
specifying how. But in practice I don't think we currently know how to 
realize that.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 2 Apr 2007 14:07:56 +0200

>IMO you may use the domain of any provider that will be 
>willing to route the call to the proper destination. E.g. you 
>could use your own provider if you have one and it does this. 
>(I realize this is a bit controversial
>However this will not guarantee you will get a secure call to 
>a destination on the PSTN. Once the call leaves the sip 
>network all bets are off.
> 
>IMO a key value of TEL is that it does not dictate the 
>protocol used to reach the destination, whereas a sip/sips 
>URI does.

I am not sure I understand correctly, but if you use sip/sips and reach
a PSTN gateway you will not have SIP all the way (it is nowhere said
that you can't send sip to a PSTN gateway).

So, from that perspective I don't see a difference between sip and tel.
Both are only schemes, and if they are used with SIP it's quite obvious
that SIP is going to be the protocol. If they reach a gateway something
else will be used - no matter whether the scheme is sip or tel.

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 2 Apr 2007 15:10:11 +0300

> - not all agree this is a proper usage.)

the domain would need to be one with which the caller has made pstn
gateway agreement.  i cannot have any clue who that might be.  if i put
my own domain there, my proxy would reject such a call.

 > destination on the PSTN. Once the call leaves the sip network all bets 

that was not my point.  the point of using sips or tels is that tls is
used for signaling from calling sip ua to called sip ua, in this case
the pstn gw.

 > specifying how. But in practice I don't think we currently know how to 

what i'm trying to say is that IF we have sips, we also have to have
tels.  having one without another makes NO sense.  the solution to this
deprecate sips.

-- juha

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 2 Apr 2007 16:44:52 +0200

>used for signaling from calling sip ua to called sip ua, in this case

Does this also mean that sips only needs to work from UA to the next B2BUA?
 
Richard

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 2 Apr 2007 10:06:36 -0500

Then you can't secure it.

A Tels URI wouldn't fix this problem. Somebody has to be responsible for
it. 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Sunday, April 01, 2007 19:57
> Cc: Juha Heinanen; Cullen Jennings; IETF SIP List; Christer 
> Holmberg ((JO/LMF))
> But I don't know who his service provider is. So how can I 
> know how to populate the domain-part of the request?
> 
> --
> Dean
> 
> tels?  if 
> >> i would use sips, i cannot place my my own domain in the uri.
> >>
> >> -- juha
> >>
> >
> 
>

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 2 Apr 2007 18:14:02 +0300

> Does this also mean that sips only needs to work from UA to the next

sure.  i don't remember that rfc3161 nor any other rfc has standardized
anything about B2BUAs.  as far as ietf sip specs are concerned, a b2bua
is a sip ua like any other sip ua.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 2 Apr 2007 10:14:31 -0500

Than can never be secure. Unless you use sips (and you know the service
provider), and the PSTN
leg will have PSTN level security. 

> Sent: Monday, April 02, 2007 00:38
> To: Christer Holmberg (JO/LMF)
> Cc: Cullen Jennings; Audet, Francois (SC100:3055); IETF SIP List
> Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
>

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 2 Apr 2007 17:17:02 +0200

So sips is useless, at least in IMS
 
Richard

________________________________

Von: Juha Heinanen [mailto:[email-masked]]
Gesendet: Mo 02.04.2007 17:14
An: Stastny Richard
Cc: Paul Kyzivat; IETF SIP List; Francois Audet; Christer Holmberg ((JO/LMF))
Betreff: Re: [Sip] RE: Securing Other URI (Tel URI) scheme

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 2 Apr 2007 10:19:45 -0500

Exactly.

And by definition, tel can not be "secure" because the service provider
is arbitrary. 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 04:59
> To: Juha Heinanen
> Cc: Audet, Francois (SC100:3055); Cullen Jennings; IETF SIP 
> List; Christer Holmberg ((JO/LMF))
> URI does. In theory a TELS URI could specify a requirement to 
> reach a destination securely without specifying how. But in 
> practice I don't think we currently know how to realize that.
> 
> 	Paul
> 
> Juha Heinanen wrote:
> > Francois Audet writes:
> > 
> >  > > how can i refer-to or 302 someone securely to pstn 
> without  > > 
> > tels?  if i would use sips, i cannot place my my own domain  > > in 
> > the uri.
> > 
> > which service provider?  i don't have any idea how someone 
> who calls 
> > me reaches pstn.  so please tell me how i can refer or 302 someone 
> > securely to my pstn number.  if you don't have a good 
> answer, please 
> > include tels in your i-d.
> > 
> > -- juha
> > 
> > [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 18:23:09 +0300

> A Tels URI wouldn't fix this problem. Somebody has to be responsible for

i don't understand what you are trying to say.  of course i cannot
control what other peoples' UAs are doing nor can i control what other
peoples' proxies are doing.  there is no difference if a sip ua gets a
refer or 302 asking it to use tls or if a proxy gets a invite asking it
to use tls.  both can cheat.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 2 Apr 2007 18:25:51 +0300

> So sips is useless, at least in IMS

good, yet another reason to get rid of it.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 2 Apr 2007 18:28:16 +0300

> And by definition, tel can not be "secure" because the service provider

neither can sips be secure because sip service provider of the callee is
arbitrary.  isn't is a high time to stop this bullsh*t and announce sips
dead?

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 2 Apr 2007 17:32:20 +0200

>So sips is useless, at least in IMS

If you base your comment on B2BUAs, I'm pretty sure you'll also find
them elsewhere than in IMS...

Regards,

Christer

>  > Does this also mean that sips only needs to work from UA 
> to the next  > B2BUA?
> 
> sure.  i don't remember that rfc3161 nor any other rfc has 
> standardized anything about B2BUAs.  as far as ietf sip specs 
> are concerned, a b2bua is a sip ua like any other sip ua.
> 
> -- juha
> 
> 
>

---

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

> what i'm trying to say is that IF we have sips, we also have 
> to have tels.  having one without another makes NO sense.  
> the solution to this deprecate sips.

Using rethorical arguments like this is not terribly helpful.

Kind of like saying SIP is complicated and has bugs. Let's just
deprecate SIP.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 2 Apr 2007 10:35:51 -0500

> i don't understand what you are trying to say.  of course i 
> cannot control what other peoples' UAs are doing nor can i 
> control what other peoples' proxies are doing.  there is no 
> difference if a sip ua gets a refer or 302 asking it to use 
> tls or if a proxy gets a invite asking it to use tls.  both can cheat.

I'm saying that the concept of tels doesn't make sense because there
is no authority for that number.

If you map it into SIPS as Cullen was suggesting, then it's the "service
provider"
(i.e., the domain after the @) that is responsible for the address in
the SIP domain.

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 2 Apr 2007 19:01:52 +0300

> Kind of like saying SIP is complicated and has bugs. Let's just

no, lets just get rid of those features no-one knows that they mean or
that have not been implemented.  like should be obvious already, it is
not possible to fix sips so that it would serve any useful purpose.  it
is not your fault.  you just have to face the facts in your i-d.

-- juha

---

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

> the only reason that i have found is the refer/302 problem to pstn.

While I'll agree that we need tel: for just this problem, I don't see  
a driving imperative for tels:

1) We have agreed that SIP nodes will use TLS if possible, so if it  
is possible to route the tel: request over TLS, then we'll get TLS.  
Right? (or is that the bogus assumption I think it is?)

2) Since the tel: request is possibly going to get routed over the  
PSTN, it can already be assumed to be somewhat security compromised.  
That is, it really isn't worthy of a "s" modifier.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 2 Apr 2007 19:05:36 +0300

> (i.e., the domain after the @) that is responsible for the address in

and then what?  what does that 'authority' mean for the outbound proxy
the caller is using?  this thread leads to nowhere.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Mon, 2 Apr 2007 11:06:26 -0500

> Kind of like saying SIP is complicated and has bugs. Let's just

Yesterday, I'd have heartily agreed with this comment.

;-)

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Mon, 02 Apr 2007 09:16:08 -0700

> Kind of like saying SIP is complicated and has bugs. Let's just

If you want to cut down on rhetorical arguments...

There's a difference between bugs of the nature that can be fixed and
bugs of the nature that cannot because of the base design. SIP suffers
mostly from the former, SIPS the latter.

       Mike

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 2 Apr 2007 19:16:31 +0300

> Right? (or is that the bogus assumption I think it is?)

with this logic we would not need sips either.

 > That is, it really isn't worthy of a "s" modifier.

with this logic no request is worthy of a "s", since caller cannot
know that a call to sips:[email-masked] might end up to pstn or to a
B2BUA that converts sips to sip.

also, should forwarding to pstn be denied by a proxy if uri scheme is
sips?

what users are interested in is end-to-end security.  sips cannot
guarantee it and is useless.

-- juha

---

From: Michael Thomas <[email-masked]>
Date: Mon, 02 Apr 2007 09:38:40 -0700

Dean Willis wrote:
> 1) We have agreed that SIP nodes will use TLS if possible, so if it is 
> possible to route the tel: request over TLS, then we'll get TLS. 
Dean, with all due respect, this is nonsense. The Internet and the PSTN 
are different
animals and they need to be each evaluated on their own merits to determine
whether various security measures are needed/necessary. It's perfectly 
possible
to have a situation where the PSTN security is greater than Internet 
security as it
will be deployed and thus _require_ stronger security mechanisms to get 
the needed
overall risk to be acceptable. "Secure" and "Insecure" in the abstract 
are meaningless
assertions.
 
WRT SIPS, TELS just points out how designing a particular mechanism for an
extremely narrow use in highly tailored environments gets us into huge
problems when it's done in the context of internet-wide standards. It 
begs these
kinds of questions, as well as obscuring the basic fact that faithfully 
replicating a
mistake is still a mistake.

       Mike

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 2 Apr 2007 19:28:50 +0200

>While I'll agree that we need tel: for just this problem, I 
>don't see a driving imperative for tels:
> 
>1) We have agreed that SIP nodes will use TLS if possible, so 
>if it is possible to route the tel: request over TLS, then 
>we'll get TLS.  
>2) Since the tel: request is possibly going to get routed 
>over the PSTN, it can already be assumed to be somewhat 
>security compromised.  

How can we assume that a tel has a higher possibility to get routed over
the PSTN than sip???

Regards,

Christer

---

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

I would say rather start working on SIP 3.0 :-) 

Business guys will kill me ....

Thx
Samir

>Sent: Monday, April 02, 2007 9:06 AM
>Cc: Cullen Jennings; IETF SIP List; Juha Heinanen; Paul 
>Kyzivat; Christer Holmberg ((JO/LMF))

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 12 Apr 2007 21:52:13 -0400

> specifying how. But in practice I don't think we currently know how to 

I'd say that last more strongly - "securely without saying how" is at
best meaningless and at worst actively misleading - exactly the sort of
statement the bad guys would all like us to agree on.

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