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

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 23:23:12 -0600

On Oct 31, 2006, at 3:12 PM, Sanjay Sinha ((sanjsinh)) wrote:

>
> It is my understanding is that SBC is esentially a B2BUA or an IP-IP
> gateway, if one leg is SIP and another one is say, H323/MGCP. A pstn
> gateway is termination point of IP leg signaling. It will have fxs/ 
> pots
> or a PBX interface on the other leg. So I can have an IAD with pots
> phones hanging off of fxs port in a small branch office and know that
> interface is secure/trusted.
>

Ok, that's fair. I wouldn't describe that as a PSTN Gateway so much  
as I would describe it as a multi-user UA that uses telephone  
handsets to implement its user interface devices. By the same token,  
it would be OK to run sips: to a Mac that uses a Bluetooth headset,  
even though Bluetooth isn't TLS.

By PSTN gateway, I mean a box that converts the SIP call into a  
signaled call on a PSTN line (especially a "trunk" line).

Of course, once you stick an fxo line on that multiuser-UA box and  
start pumping calls back into the P (that's Public) STN, you have a  
security problem again. This could easily happen with a PBX, so that  
could be a problem. It might be legit to say that a PBX simply can't  
do sips:, because it can't meet the security assurances of sips:.

--
Dean

_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Wed, 1 Nov 2006 10:34:32 -0600

There is a difference however between and SBC and PSTN Gateway, in that
their security model are quite different.

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Tuesday, October 31, 2006 9:23 PM
> To: Sanjay Sinha ((sanjsinh))
> Cc: IETF SIP List
> Subject: Re: [Sip] A sips: trial balloon for you to shoot down
> 
> 
> > pots or a PBX interface on the other leg. So I can have an IAD with 
> > pots phones hanging off of fxs port in a small branch 
> office and know 
> > that interface is secure/trusted.
> >
> 
> Ok, that's fair. I wouldn't describe that as a PSTN Gateway 
> so much as I would describe it as a multi-user UA that uses 
> telephone handsets to implement its user interface devices. 
> By the same token, it would be OK to run sips: to a Mac that 
> uses a Bluetooth headset, even though Bluetooth isn't TLS.
> 
> By PSTN gateway, I mean a box that converts the SIP call into 
> a signaled call on a PSTN line (especially a "trunk" line).
> 
> Of course, once you stick an fxo line on that multiuser-UA 
> box and start pumping calls back into the P (that's Public) 
> STN, you have a security problem again. This could easily 
> happen with a PBX, so that could be a problem. It might be 
> legit to say that a PBX simply can't do sips:, because it 
> can't meet the security assurances of sips:.
> 
> --
> Dean
> 
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Nov 2006 12:04:31 -0500

> their security model are quite different.

I don't see the difference.

In either case, the call has reached a UA. From that point on you are 
trusting that the UA will do the right thing. The best you can do is 
determine the identity of that UA and decide if it is one you wish to trust.

If you have phone service from a provider that uses SBCs at its 
connection to the internet, when I call "you" I am really calling that 
SBC. All security and authentication properties are with it, not you or 
your devices. I must trust it. The same is true if I call a gateway.

	Paul

---

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

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Wednesday, November 01, 2006 9:05 AM
> To: Audet, Francois (SC100:3055)
> Cc: Dean Willis; Sanjay Sinha ((sanjsinh)); IETF SIP List
> > There is a difference however between and SBC and PSTN Gateway, in 
> > that their security model are quite different.
> 
> In either case, the call has reached a UA. From that point on 
> you are trusting that the UA will do the right thing. The 
> best you can do is determine the identity of that UA and 
> decide if it is one you wish to trust.

The difference is that there is a level of "security" on PSTN. You can't
do IP address spoofing for example. You can't tap into a hub. 

(Yes, I know: there are ways to tap into analog lines too).

The point is that for many people, they are happy with the security
level provided by the PSTN, but not with the one provided by IP
telephony
or SIP when there is no TLS/SRTP/whatever.

That's my point.

So, I can see that, as Michael Thomas said, putting all the "attributes
of security" into the letter "s" is not terribly useful.

On the specific issue of "is sips allowed" when you leave the "network",
I am a bit
ambivalent.

I think if you are Leaving SIP and going to another IP protocol (say
H.323) then we
shouldn't allow SIPs.

However, for the PSTN case, I'm not sure. I think I'm ok either way. I
think arguments
on both sides are valid.

> If you have phone service from a provider that uses SBCs at 
> its connection to the internet, when I call "you" I am really 
> calling that SBC. All security and authentication properties 
> are with it, not you or your devices. I must trust it. The 
> same is true if I call a gateway.
> 
> 	Paul
> 
> >> handsets to implement its user interface devices.
> >> By the same token, it would be OK to run sips: to a Mac 
> that uses a 
> >> Bluetooth headset, even though Bluetooth isn't TLS.
> >>
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >>
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

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

On Nov 1, 2006, at 10:34 AM, Francois Audet wrote:

> that

How do you know? Specifically, how do you as a UA user on the SIP  
side of an SBC, B2BUA, or gateway know? All you have is trust that  
the widget honors the contract of sips:.

Sure, if it's a sips: compliant SBC/B2BUA, it could reasonably  
produce sips: on the other side and stay compliant to the intent of  
sips:.

But if it's converting to anything else (sip:, xmpp, ISDN, ISUP,  
whatever) it can't maintain the contract of transitive trust implied  
by sips:, and it MUST therefore NOT use sips:.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Nov 2006 15:00:31 -0600

On Nov 1, 2006, at 11:04 AM, Paul Kyzivat wrote:
> connection to the internet, when I call "you" I am really calling  
> that SBC. All security and authentication properties are with it,  
> not you or your devices. I must trust it. The same is true if I  
> call a gateway.

The point is that you are trusting the SBC to perform in a manner  
consistent with the intent of sips:. By accepting the sips:  
connection, it has essentially contracted with you to comply with sips:.

If it does NOT comply with the intent of sips: and translates the  
dialog into something that isn't protected and is then "sent out"  
beyond its immediate sphere of control (its user interface, if it is  
a UA), then it has failed to honor that contract.

--
Dean

---

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

> However, for the PSTN case, I'm not sure. I think I'm ok either way. I

Since the PSTN call could (and very well may) turn back into a sip:  
session, and we have no way to send the "please make this back into a  
secure session when you go back to IP" request over PSTN, then I  
don't think you can claim to have met the intent of sips:.

That's not to say a gateway couldn't use SIP security techniques --  
for example, it could (and should) use TLS. It just can't claim to  
have met the requirements of sips:.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 1 Nov 2006 15:10:16 -0600

I'm not saying I'm against your proposal.

I'm just saying others may view the "network boundary" to be
the IP network. It is a valid opinion.

Others may even just view it to be SIP. 

Even if it sips end-to-end, I can have a bluetooth headset to take the
example that Paul K. had.

I could duck-tape another phone on my sip phone and do analog coupling. 
Undetectable.

> Sent: Wednesday, November 01, 2006 12:49 PM
> Cc: Sanjay Sinha ((sanjsinh)); IETF SIP List
> How do you know? Specifically, how do you as a UA user on the 
> SIP side of an SBC, B2BUA, or gateway know? All you have is 
> trust that the widget honors the contract of sips:.
> 
> Sure, if it's a sips: compliant SBC/B2BUA, it could 
> reasonably produce sips: on the other side and stay compliant 
> to the intent of sips:.
> 
> whatever) it can't maintain the contract of transitive trust 
> implied by sips:, and it MUST therefore NOT use sips:.
> 
> --
> Dean
> 
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 01 Nov 2006 13:24:13 -0800

Dean Willis wrote:

>> not you or your devices. I must trust it. The same is true if I  call 
>> a gateway.
>
>
Contracted? Heavens. If it's really come to this, we're seriously 
wrapped around
the axle.

          Mike

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Nov 2006 15:33:37 -0600

> I could duck-tape another phone on my sip phone and do analog  

And if you did, and you used this tape-spliced phone to downgrade  
from sips: to sip:, then what you would be doing would NOT be a "Best  
Current Practice". In fact, it would be a violation of the proposed  
"Best Current Practice" wording.

We can't reasonably design useful guns that keep you from  
deliberately shooting yourself in the head. We can, however, write  
training manuals that suggest you not do it deliberately, and we can  
write guidelines like "don't point at something you aren't planning  
to shoot" that will help keep you from doing it accidentally.

Based on the principle of "If it hurts, don't do it", Best Current  
Practice documents exist to tell people things that are likely to  
hurt and provide suggestions for alternatives that are expected to  
hurt less.

 From that perspective, translating a sips: request to something that  
is not secured and is likely to be sent somewhere else would also not  
be a Best Current Practice.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Nov 2006 15:38:23 -0600

On Nov 1, 2006, at 3:24 PM, Michael Thomas wrote:

>>> connection to the internet, when I call "you" I am really  
>>> calling  that SBC. All security and authentication properties are  
>>> with it,  not you or your devices. I must trust it. The same is  
>>> true if I  call a gateway.
>>
>>
>> beyond its immediate sphere of control (its user interface, if it  
>> is  a UA), then it has failed to honor that contract.
>>

;-)

Actually, its the same sort of "contract" that an API or function- 
call implies.

--
Dean

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 1 Nov 2006 17:21:20 -0500

Let's take your examples.

First was Bluetooth.  I agree this is a judgment call, but because I think
we're all thinking the same thing: the phone is the phone is the phone and
it's not the headset, I think it's not in the signaling path.  

Now you want to talk about acoustic coupling.  I think that one is easy.  If
both sides of the coupling are TLS end to end, then you have a poor man's
B2BUA and the sips sticker is awarded.  If one or the other side does not
maintain TLS end to end, it doesn't meet Dean's words.  I don't think there
is much of a judgment there.

Dean's proposal DOES admit to judgment calls. It's not perfect, but it's
useful.

Brian

> From: Francois Audet [mailto:[email-masked]]
> Sent: Wednesday, November 01, 2006 4:10 PM
> To: Dean Willis
> Subject: RE: [Sip] A sips: trial balloon for you to shoot down
>