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

From: "Attila Sipos" <[email-masked]>
Date: Wed, 1 Nov 2006 16:00:01 -0000

>> 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.
>> 

Imagine a system where you have PBX and an ISDN/SIP
gateway.  The office which uses the PBX want to be able
make secure SIP calls to the global internet.

So, if, as is said, "sips should fail", then these
users won't be able to use sips.

I don't think it is right to take sips ability away from
these users.  I mean, you could have the PBX in a secured room.
Wouldn't that be secure enough?

And how does one define "secured signaling" anyway?  And there's
nothing to stop anyone getting a SIPS phone and interfacing
it to something which is "insecure".

In my opinion, whether to allow SIPS must be decided by
the administrator and not nailed down in a standard.

regards,

	Attila

_______________________________________________
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: "Brian Rosen" <[email-masked]>
Date: Wed, 1 Nov 2006 11:13:57 -0500

Clearly, we don't agree.

I would say that the PBX can't provide security to any other call, how could
it possibly provide security to a sips call?  One end is insecure.   

Dean has a proposed wording for what we mean, and I'm happy with that.  PSTN
(or PBX) doesn't do that.  

There are no protocol police, so of course you are correct that anyone can
break the rules and get away with it.  

We have standards to define what things mean, and this is an example of
needing such a definition.

I think we all agree that sips is not the only thing we need for signaling
security, and many of the ideas that have been discussed for further work
beyond sips (and S/MIME) have the notion that there is not a black/white
setting, one end should express it's desired security properties, and have a
way to determine if those properties have been met.  I like those thoughts,
will contribute to the development of such a mechanism, and think it will
address your concerns.  That's not sips.

Brian

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

---

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

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, November 01, 2006 11:14 AM
> 
> Clearly, we don't agree.
> 

It did provide security for a sips session.  That session is between the UAC
and the sips UAS.  The UAS is the end, as far as sip/sips is concerned.  Are
you suggesting sips is more than a specific uri scheme for SIP, and somehow
a cross-protocol, universal fiat, based on an ambiguous definition of
"secure"?  :)

Will the BCP start listing all device types and roles, and whether they are
allowed to accept a sips request or not?  A Bluetooth handset is allowed to,
a home cablemodem (IAD) with an FXO interface is allowed to, but if that IAD
is classified as a PBX then not.  Unless that "PBX" is an open-source app in
my house PC.  But if my PC gets moved, then it needs to stop accepting sips.

This would be like classifying pornography.  "I know it when I see it."

-hadriel

---

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

I think Dean's formulation is a sensible set of rules.  It's not airtight,
nor could it be.  It can be misinterpreted, accidentally or deliberately.  I
think the intent is clear, and I think the "Best Current Practice" language
is clear enough.  

I don't think that security across one set of UAC to UAS in the presence of
B2BUAs and gateways is useful to anyone.  I keep imagining TLS protection
from UAC to the edge of his own domain, through an SBC across the open
Internet with zero security to another domain, with another SBC and TLS from
that to the UAS.  Does that meet anyone's needs?  Does it have anything to
do with any sense of secure?  I think not.

Brian 

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

---

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

A thought to ponder
When Calls on *IP only* are secured, how long PSTN / MGW will last ?

I think we are mature enough with enough feature differentials at our
hand.
Only missing things are security, security .... 911 ...

I feel we should just focus on IP only stuff first. Any opinion on this
is welcome.

For any patches to SIPS to work , I would like to see concrete proposal
catering
A) How it will interwork with future more elegant / complete proposals.
B) How it will transport other URI schemes.
C) How it will control the features outside of dialog. Like Presence
event
   Subscribers, REG-EV subscribers
D) How it will control the cipher-suite selection?

IMHO, let us accept SIPS is broken and not patchable in reasonable way. 

Thx
Samir

> Sent: Wednesday, November 01, 2006 10:50 AM
> To: 'Hadriel Kaplan'; 'Attila Sipos'; 'Sanjay Sinha (sanjsinh)'; 'Dean
> Willis'; 'IETF SIP List'
> nor could it be.  It can be misinterpreted, accidentally or
deliberately.
> I
> I don't think that security across one set of UAC to UAS in the
presence
> of
> Internet with zero security to another domain, with another SBC and
TLS
> from
> > > I would say that the PBX can't provide security to any other call,
how
> > > could
> > It did provide security for a sips session.  That session is between
the
> > UAC
> > and the sips UAS.  The UAS is the end, as far as sip/sips is
concerned.
> > Are
> > Will the BCP start listing all device types and roles, and whether
they
> > are
> > allowed to accept a sips request or not?  A Bluetooth handset is
allowed
> > to,
> > a home cablemodem (IAD) with an FXO interface is allowed to, but if
that
> > IAD
> > is classified as a PBX then not.  Unless that "PBX" is an
open-source
> app
> > in
> > my house PC.  But if my PC gets moved, then it needs to stop
accepting
> > sips.

---

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

> When Calls on *IP only* are secured, how long PSTN / MGW will last ?

To be cynical, if IP calls are really secured, then they will probably 
be ruled illegal. Sellers of equipment and services will be forbidden 
from offering this capability.

	Paul

---

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

> from offering this capability.

  You need to have B2BUA in between providing CALEA. We need to specify
B2BUA behavior.

Thx
Samir

---

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

Is a call providing CALEA a secure call? Not in my book. Not if the only 
two choices are "secure" and "insecure". If there are more than two 
choices, then "secure except subject to CALEA" might be one of them.

	Paul

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 1 Nov 2006 14:28:11 -0600

As far as I know, FCC will not let you deploy without CALEA compliance.
Am I out-of-date on this? 

IMHO, we will be having security with CALEA. This Security notion is to
avoid the Call Pattern tracking etc by attackers but the duly assigned
authorities will be open to record the conversation.

My view is "Secure except subject to CALEA" .

Thx
Samir

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, November 01, 2006 12:22 PM
> To: Srivastava, Samir (SC100:8826)
> Cc: Brian Rosen; Hadriel Kaplan; Attila Sipos; Sanjay Sinha
(sanjsinh);
> Dean Willis; IETF SIP List
> Subject: Re: [Sip] A sips: trial balloon for you to shoot down
>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 1 Nov 2006 16:01:52 -0500

> Sent: Wednesday, November 01, 2006 1:50 PM

Well, I was actually only focusing on the PSTN GW restriction.  One can of
worms at a time as it were. :)  I actually think a layman typing in a sips
uri would be fine with it going to the PSTN.  And I think trying to make any
suppositions of their wishes beyond the sips domain is virtually impossible.

With respect to SBCs, my assumption is an SBC will keep a SIPS request
received as a UAS a SIPS request as a UAC, reject it if it cannot do so,
etc.  Unless, of course, it's specifically told to do otherwise by its
owner.  I have a sneaking suspicion that would be the case of many stateful
"proxies" too. (in fact, I know of two that can do otherwise if set to)  But
if the owner set it to be clear on the public internet, they've created a
security issue for which they would have to take some responsibility
(maybe... IANAL).  

If you just want a BCP to say "a B2BUA or SBC should keep a sips request a
sips request", with all that entails, I'm cool with that.  But throwing in a
PSTN GW, PBX, IAD, MTA, Key-system, etc. is wrong, IMHO.  It is neither Best
nor Current Practice.

-hadriel