Subject: Re: [Sip] RE: TLS meaning

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 15:51:43 -0500

Well, many messages have come and gone since this one. So, I will 
respond to Francois's note here and make some additional points.

My own opinion:

1. no
2. yes

I fear that much of the objection to sips is wound up in its name. Its 
not "secure SIP" in the sense that there are certainly attacks that 
remain even if you use it. However, there is really no such thing as 
"secure SIP", anymore than there is really such a thing as "secure 
HTTP". I'll point out that with attacks like phishing, even https isn't 
providing people with what they think is "secure web browsing". But let 
us not throw the baby out with the bathwater.

What SIPS can do, once we fix it, is provide a particular property that 
I think is very valuable. In networks with trusted proxies, it prevents 
against a vast array of "outsider" attacks - eavesdropping, replay, 
modification, and so on. This property is very useful. I can't tell you 
how many SIP extensions have security considerations that are based on 
this property.

Just because sips doesn't address insider attacks (where the proxies are 
not trusted), does not make it useless. To be frank I fear there will 
never be a deployable solution for security where you don't trust the 
proxies. Its kind of like hoping the Internet works when you don't trust 
the routers. It would be nice but it sounds hard.

I believe we have also learned a lot since RFC 3261. WIth the arrival of 
sip-outbound, I believe we have the final tool needed to remove the last 
hop exception rule, and have a very useful security technique that is 
also extremely deployable. If you throw in DTLS as "ok" as well, you can 
even get around the TCP/UDP wars, and provide something that works for 
wireless too.

My two cents,
Jonathan R.

Francois Audet wrote:

> In case people having noticed, it is looking like we are having a
> mailing list 
> hum on the following 2 questions:
> 
> 1 - Do you favour deprecating the sips scheme altogether (yes/no)
> 
> 2 - Do you favour getting rid of the last-hop-exception rule (yes/no)
> 
> 
> Note: Voting Yes on 2 does not necessarily imply you are voting No on 1,
> but it will
> only make sense if sips is not deprecated.
> 
> I'm keeping track of the vote.
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.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: "Samir Srivastava" <[email-masked]>
Date: Thu, 2 Nov 2006 03:54:16 -0600

Hi Jonathan,

   You have your right to vote and I respect your opinion.

May I ask following question

   1) How can I route the non-sip uri over the SIP network. When I need
Proxy-Require for non SIP URI's then why not use the same Proxy-Require
tag for SIP itself. 

   2) Without any additional flag for REQUIRE tag, my presence and
reg-info is open to be sent on the unsecure channels to watchers.

   3) IMHO, Proxies and routers cannot be compared. Routers only look
into IPAddresses, where Proxies look into the complete SIP message
to,from etc .. Knowing some IP Packets going between two IP address
doesn't reveal much. But knowing To, From etc by any attacker on the
wire does mean much.

   4) SIPS doubles the entries in DNS, registrar etc.. (For SIPS, and
SIP URIS.) Whereas  Proxy-Require/Require doesn't require that.

   5) How SIPS will interwork with more workable secure solutions ? With
limited TLS (what it means still open) only, embedded with SIPS how do
you want to upgrade it for DTLS. 

   6) If you believe in cipher-suite issue, then Proxy-Require for that
makes SIPS redundant. 

Thx
Samir 

>-----Original Message-----
>From: Jonathan Rosenberg [mailto:[email-masked]] 
>Sent: Wednesday, November 01, 2006 12:52 PM
>To: Audet, Francois (SC100:3055)
>Cc: IETF SIP List
>Subject: Re: [Sip] RE: TLS meaning
>
>Well, many messages have come and gone since this one. So, I 
>will respond to Francois's note here and make some additional points.
>
>My own opinion:
>
>1. no
>2. yes
>
>I fear that much of the objection to sips is wound up in its 
>name. Its not "secure SIP" in the sense that there are 
>certainly attacks that remain even if you use it. However, 
>there is really no such thing as "secure SIP", anymore than 
>there is really such a thing as "secure HTTP". I'll point out 
>that with attacks like phishing, even https isn't providing 
>people with what they think is "secure web browsing". But let 
>What SIPS can do, once we fix it, is provide a particular 
>property that I think is very valuable. In networks with 
>trusted proxies, it prevents against a vast array of 
>"outsider" attacks - eavesdropping, replay, modification, and 
>so on. This property is very useful. I can't tell you how many 
>SIP extensions have security considerations that are based on 
>this property.
>
>Just because sips doesn't address insider attacks (where the 
>proxies are not trusted), does not make it useless. To be 
>frank I fear there will never be a deployable solution for 
>security where you don't trust the proxies. Its kind of like 
>hoping the Internet works when you don't trust the routers. It 
>would be nice but it sounds hard.
>
>I believe we have also learned a lot since RFC 3261. WIth the 
>arrival of sip-outbound, I believe we have the final tool 
>needed to remove the last hop exception rule, and have a very 
>useful security technique that is also extremely deployable. 
>If you throw in DTLS as "ok" as well, you can even get around 
>the TCP/UDP wars, and provide something that works for wireless too.
>
>My two cents,
>Jonathan R.
>
>Francois Audet wrote:
>
>> mailing list hum on the following 2 questions:
>> 
>> Note: Voting Yes on 2 does not necessarily imply you are 
>voting No on 
>> 1, but it will only make sense if sips is not deprecated.
>> 
>> 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
>> 
>
>-- 
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Nov 2006 13:57:35 -0500

> Proxy-Require for non SIP URI's then why not use the same Proxy-Require

Its a good question; I think the answer depends somewhat on whether 
these tel URI get quickly translated to sip or whether they hang around 
(see
http://www.ietf.org/internet-drafts/draft-rosenberg-rai-phone-names-numbers-00.txt)

I think you would need involvement of Route headers with sips URIs in 
these cases.

> reg-info is open to be sent on the unsecure channels to watchers.

Why? Use sips URIs for those.

> doesn't reveal much. But knowing To, From etc by any attacker on the

I don't see how this point is relevant to the discussion.

> SIP URIS.) Whereas  Proxy-Require/Require doesn't require that.

True.

> you want to upgrade it for DTLS. 

I am in the camp that views DTLS as equally OK as TLS/TCP. That is, the 
requirement is on the security mechanism, not the transport protocol.

>    6) If you believe in cipher-suite issue, then Proxy-Require for that

I do not believe in the need to signal or convey the cipher-suites.

-Jonathan R.

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 6 Nov 2006 16:17:24 -0600

Hi Jonathan,

in-line.

Thx
Samir

>> 
>>    1) How can I route the non-sip uri over the SIP network. When I 
>> need Proxy-Require for non SIP URI's then why not use the same 
>> Proxy-Require tag for SIP itself.
>
>Its a good question; I think the answer depends somewhat on 
>whether these tel URI get quickly translated to sip or whether 
>they hang around (see
>I think you would need involvement of Route headers with sips 
>URIs in these cases.

SS>> I have to take a look on this.

>Why? Use sips URIs for those.

SS>> As per 3903

          PUA                     PA                      WATCHER
         (EPA)                   (ESC)
           |                       |                         |
           |                       | <---- M1: SUBSCRIBE --- |
           |                       |                         |
           |                       | ----- M2: 200 OK -----> |
           |                       |                         |
           |                       | ----- M3: NOTIFY -----> |
           |                       |                         |
           |                       | <---- M4: 200 OK ------ |
           |                       |                         |
           |                       |                         |
           | ---- M5: PUBLISH ---> |                         |
           |                       |                         |
           | <--- M6: 200 OK ----  |                         |
           |                       |                         |
           |                       | ----- M7: NOTIFY -----> |
           |                       |                         |
           |                       | <---- M8: 200 OK ------ |

If M5 PUBLISH uses the SIPS URI, while in M1 WATCHER uses just the SIP
URI. Should we just leave the intermediary to distribute the presence on
the unsecure channel. IMHO, PUA should have the control for the security
where his presence info is going. Similar for REG-INFO. 

>requirement is on the security mechanism, not the transport protocol.

Perfect. I too believe that we should not pose any limit on the secure
protocol to be used. I believe in separate header for describing the
complete secure protocol properties clearly, instead of embedding them
like SIPS means TLS over TCP in 3261.

>I do not believe in the need to signal or convey the cipher-suites.

NULL encryption ciphers provide no confidentiality.  There are some
geographic regions where confidentiality is not permitted. (Pl correct
me if I am wrong) UAC need to know when his request is not given the
desired level of confidentiality. Here we cannot rely on the mandatory
ciphers. In this case UAC request should be failed by the proxy with
some 4xx, if downstream hop doesn't provide confidentiality. Then UAC
may resubmit. 

There was earlier discussion on Cheater Proxy , Trust and Verify etc for
its motivation.

Having a well defined mechanism of Secure-Protocol with properties is
more future proof.
After 3261, we found DTLS now we want to put DTLS. IMHO, similar can be
for ciphers.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 6 Nov 2006 17:55:46 -0500

> From: Samir Srivastava [mailto:[email-masked]]
> Sent: Monday, November 06, 2006 5:17 PM
>
> [snipped diagram]

HK> If you want a UAC to control who gets to see its presence, that should
be a package of/within presence, not a URI scheme or require of the
subscribe or publish or whatever.  The PUBLISH was addressed to the server,
and it got there.  If you use SIPS it will (hopefully) get there over TLS.

> like SIPS means TLS over TCP in 3261.

HK> I am in the exact opposite camp.  I don't think an application protocol
header should specify the transport type at all to be used for
forward-routing by other nodes, let alone the intricate details of that
transport.  Do you expect to specify whether it can be UDP, TCP, or even the
MTU as well? :)

Encryption mechanisms in particular would be bad for this.  There are so
many optional/alternate components, that for a UAC to describe all the sets
it will "allow" all proxies to use for transporting its message is just not
practical.  There's a reason negotiation mechanisms exist for encryption
protocols, and even with them we have mismatches/failures.

SIPS and SIP rely on trusting the proxies in the middle.  If you don't trust
them there's no point in adding more headers/checks when they can lie about
any/all of them.  If you DO trust them, then trust them to do the right
thing.  What they need from the UAC is to know whether the message is
sensitive enough that it should not be forwarded if a secure next-hop path
is not available. 

-hadriel

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 6 Nov 2006 19:03:05 -0600

Hi Hadriel,

In-line.

Thx
Samir

>> URI. Should we just leave the intermediary to distribute the 
>presence 
>> on the unsecure channel. IMHO, PUA should have the control for the 
>> security where his presence info is going. Similar for REG-INFO.
>
>HK> If you want a UAC to control who gets to see its presence, that 
>HK> should
>be a package of/within presence, not a URI scheme or require 
>of the subscribe or publish or whatever.  The PUBLISH was 
>addressed to the server, and it got there.  If you use SIPS it 
>will (hopefully) get there over TLS.
>

SS>> It's a question of feature. These cases are not considered earlier.
Do we have in
PIDF this support ? REGISTER just shows the IP Addresses etc. It doesn't
have a body where you can embed this.

>HK> I am in the exact opposite camp.  I don't think an application 
>HK> protocol
>forward-routing by other nodes, let alone the intricate 
>details of that transport.  Do you expect to specify whether 
>it can be UDP, TCP, or even the MTU as well? :)
>
>Encryption mechanisms in particular would be bad for this.  
>There are so many optional/alternate components, that for a 
>UAC to describe all the sets it will "allow" all proxies to 
>use for transporting its message is just not practical.  
>There's a reason negotiation mechanisms exist for encryption 
>SIPS and SIP rely on trusting the proxies in the middle.  If 
>you don't trust them there's no point in adding more 
>headers/checks when they can lie about any/all of them.  If 
>you DO trust them, then trust them to do the right thing.  
>What they need from the UAC is to know whether the message is 
>sensitive enough that it should not be forwarded if a secure 
>next-hop path is not available. 
>

SS>> For Identity etc, people don't want to trust the intermediaries,
But for the encryprion (where compromized hops reveal a lot) you want to
trust them blindly. What you want to do where confidentiality is not
permitted/provided due to whatever reasons ? 
Imagine a UAS moves from the AES256 to NULL cipher region, shouldn't the
UAC know about it ? Specially when it is IM with sensitive info in
Payload without S/MIME.