Subject: RE: [Sip] A sips: trial balloon for you to shoot down

From: "Brian Rosen" <[email-masked]>
Date: Wed, 1 Nov 2006 10:01:29 -0500

> Don't like the PSTN gateway limitation. As was mentioned in an earlier
> email, if signaling reaches PSTN gateway, it has reached UAS.

Let me relate this to another offshoot of this discussion: when do you get
the lock icon?  Ignore, just for now, implication on the media channel.

Is there ANY possibility of getting a lock icon on any system using the
current PSTN or commercial PBX?

I think the only answer possible is "yes, use a STU" (a secure telephone
that can operate over an ISDN connection).  In no other circumstance would
anyone consider PSTN or PBX systems to be secure enough to get a lock icon.

Therefore, I think that if a part of the call traverse a PSTN or PBX leg, it
is not secured signaling, and sips should fail.

Brian

_______________________________________________
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: David Benoit <[email-masked]>
Date: Wed, 1 Nov 2006 11:27:37 -0400

> email, if signaling reaches PSTN gateway, it has reached UAS.

I think you mean UAC.  As far as SIP is concerned, the gateway is the
client.

David
-- 
[email-masked] | phone: 902-832-2649  fax: 902-832-1015
 "Complex problems have simple, neat and wrong solutions" - H. L. Menken

---

From: Michael Thomas <[email-masked]>
Date: Wed, 01 Nov 2006 07:37:58 -0800

>is not secured signaling, and sips should fail.
Wow, that's a pretty slippery slope -- my home phone doesn't encrypt the
ringer bits before it hits my ear... sounds like by this definition, the 
call should
fail there too.

What strikes me about this is that there are different answers to all of 
this
depending on context. Which is why trying to encode all this into one "S"
bit in an URI scheme is hopeless. Bits are cheap; let them be fruitful and
multiply.

       Mike

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 1 Nov 2006 11:30:24 -0500

That isn't even the case in https.  When you connect to an https server, you
have no idea how the back-end gets/stores/updates its info.  It could be
creating the page by pulling from another server using tftp as far as you
know.  If that https server gets/sends emails using the contents of a
post/get https message, it says nothing about how the emails you read got to
that server, or how emails you tell it to send are sent.  Despite that your
https post message caused an email to be sent (if it worked that way), the
web server is under no obligation to refuse to send the email, or break your
https connection, just because it sends them using smtp unsecured.

-hadriel

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, November 01, 2006 10:01 AM
> To: 'Sanjay Sinha (sanjsinh)'; 'Dean Willis'; 'IETF SIP List'
> Subject: RE: [Sip] A sips: trial balloon for you to shoot down
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Nov 2006 11:52:49 -0500

Brian,

While I understand your point, and agree with it for the most part, I am 
having trouble turning it into a concrete set of rules.

In general, there are lots of things that can happen to the call 
signaling info, and the media, once it reaches the UAC or UAS. There is 
no guarantee that it is ever secure, regardless of the security of the 
link between the UAC and UAS:
- info can be displayed on a public display that can be viewed by
   parties other than the user of the device
- audio can be played in a way that can be heard by others
- some or all aspects of the session may be relayed to a peripheral
   device of the UA, e.g. a bluetooth headset, that is not secured and
   can be intercepted by others.
- the user of the UA may let someone else operate the device.

A PSTN GW is in effect no different than the bluetooth headset in this 
regard. Why should we allow one and not the other?

I think the most one can hope for is that the identity of the remote UA 
is known, and that the caller trusts the UA and its user to properly 
handle the information conveyed in the call.

When calling a phone number (e.g. +12125551234), the kinds of 
credentials that are available are somewhat dubious. I don't think we 
have any form of credential that actually states "I hold the 
responsibility for +12125551234". At best I think we may have something 
that says: "I have responsibility for sip:[email-masked]". If 
that happens to come from the operator of a gateway, then what it says 
about what happens on the other side of the gw is not clear - perhaps 
nothing.

Operationally, this might mean that if I was trying to call 
sip:[email-masked], and I receive credentials for that back, 
and the path between us is secure, then I might consider the call 
secure. But if I was calling tel:+12125551234 and I receive back 
credentials for sip:[email-masked] then I might be wise not 
to consider this secure. That leaves the problem of whether there is 
ever a way to receive credentials for tel:+12125551234.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 1 Nov 2006 11:14:54 -0600

I agree with you on this one.

> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Wednesday, November 01, 2006 7:38 AM
> To: Brian Rosen
> Cc: 'Sanjay Sinha (sanjsinh)'; 'IETF SIP List'; 'Dean Willis'
> Subject: Re: [Sip] A sips: trial balloon for you to shoot down
> 
> Brian Rosen wrote:
> 
> >Let me relate this to another offshoot of this discussion: 
> when do you 
> >get the lock icon?  Ignore, just for now, implication on the 
> media channel.
> >
> >I think the only answer possible is "yes, use a STU" (a secure 
> >telephone that can operate over an ISDN connection).  In no other 
> >circumstance would anyone consider PSTN or PBX systems to be 
> secure enough to get a lock icon.
> >
> >Therefore, I think that if a part of the call traverse a PSTN or PBX 
> >leg, it is not secured signaling, and sips should fail.
> >  
> >
> Wow, that's a pretty slippery slope -- my home phone doesn't 
> encrypt the ringer bits before it hits my ear... sounds like 
> by this definition, the call should fail there too.
> 
> What strikes me about this is that there are different 
> answers to all of this depending on context. Which is why 
> trying to encode all this into one "S"
> bit in an URI scheme is hopeless. Bits are cheap; let them be 
> fruitful and multiply.
> 
>        Mike
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 1 Nov 2006 13:44:15 -0500

There is some interpretation here.  The words in a BCP can only be so
precise.  I think the way Dean phrased it is okay.

I understand that any element may be using some protocols to do its job that
may involve some sense of security, and inappropriate choices may make the
security the endpoints think they are getting not actually be there.  I can
live with that.

I think that we don't consider the PSTN signaling to be "secure".  We
consider it more secure than open Internet in-the-clear signaling, but its
not secure.  I think sips should mean hop by hop, TLS (or equivalent as
Dean's text says) secure, and you can't do that on the PSTN.

Again, we can work on other security mechanisms that would let an endpoint
declare than a PSTN connection was acceptable.  That's not sips.

Brian

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Wednesday, November 01, 2006 11:30 AM
> To: 'Brian Rosen'; 'Sanjay Sinha (sanjsinh)'; 'Dean Willis'; 'IETF SIP
> List'
> leg,
> > it

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 1 Nov 2006 13:44:56 -0500

I am okay with what Dean wrote for rules.  What part of his proposal is
problematic for you?

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, November 01, 2006 11:53 AM
> To: Brian Rosen
> Cc: 'Sanjay Sinha (sanjsinh)'; 'Dean Willis'; 'IETF SIP List'
> leg, it

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 1 Nov 2006 13:54:30 -0600

The only difference between trusting the HTTP server and SIP proxy is
billing. And it is hop by hop. I mentioned the same case as cheater
proxy while discussing the cipher-suites.  Here Providers have enough
motivation to cheat, if enough checks are not provided.

Thx
Samir

> Sent: Wednesday, November 01, 2006 8:30 AM
> That isn't even the case in https.  When you connect to an https
server,
> you
> post/get https message, it says nothing about how the emails you read
got
> to
> web server is under no obligation to refuse to send the email, or
break
> your
> > Let me relate this to another offshoot of this discussion: when do
you
> get
telephone
> > anyone consider PSTN or PBX systems to be secure enough to get a
lock
> icon.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Nov 2006 15:06:07 -0500

> I am okay with what Dean wrote for rules.  What part of his proposal is

I find much of (4) to be problematic for the reasons stated below. I 
think the concepts it bans are fuzzy. What exactly is a gateway to 
another protocol? Is the phone with a bluetooth headset a gateway to the 
bluetooth protocol?

What about B2BUAs bridging two sips requests? What constitutes 
"bridging" vs a UA that has another sip session for some related 
purpose? For instance, a UA might accept a SIPS call, and also use SIP 
(or SIPS) to update a presence server with info about the calls it is 
in. Others might be able to obtain info (such as the identity of the 
caller of the currently active call) from the presence server via SIP. 
Does that disqualify the use of SIPS?

And BTW, if we can figure out in what cases a gw may use sips, because 
it is gatewaying to an equivently strong protocol, then we can use that 
to show that its ok to use IPsec between a pair of servers.

I only see a couple of ways to sort this out:
- agree that sips ends when it gets to the UAS. What happens
   after that must be dealt with some other way.

- begin to formally specify types of UA, more than has been done so far.
   Write specific rules for each type about what it may and may not do
   when it has a sips connection. This would cover end user devices that
   signal outside their box, various kinds of gateways, types of SBC and
   B2BUA, etc.

I think it is problematic to do the latter. It can't really be done 
without considering what the SIPS connection is being used to protect. 
That gets into our longer term problem which may not even involve sips.

So I only see the former as a workable solution.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Nov 2006 14:57:03 -0600

On Nov 1, 2006, at 10:52 AM, Paul Kyzivat wrote:

>
> A PSTN GW is in effect no different than the bluetooth headset in  
> this regard. Why should we allow one and not the other?
>

That depends on what you mean by PSTN Gateway. If you're talking  
about a "phone adapter", like a PAP-2 or larger enterprise scale  
device, then you're talking about the user interface of a SIP UA, and  
sips: is ok.

OTOH, if you're talking about a device that converts the SIP  
signaling into some other signaling format (ISDN, ISUP, MF DTMF,  
XMPP, whatever) and transmits the results to another switching  
element, then you're well outside the applicability of sips:.

--
Dean