Subject: [Simple] About sip and sips buddies

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Nov 2010 20:19:03 +0100

Hi, if my user receives a subscription request from
sip:[email-masked] and later from sips:[email-masked], will them
be considered as two different AoR's by the presence server? if so,
does my user need to add these two AoR's to his resource-lists
document as two diffferent AoR's?

If so (and I expect it is) IMHO is a bit ugly, as "sips" just should
concern security aspects.

Perhaps I am wrong and this case can be addressed in a more ellegant way.

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 18 Nov 2010 20:46:29 +0100

In my understanding that sip or sips just have to do with the transport. The URI is the same.

On Nov 18, 2010, at 8:19 PM, Iñaki Baz Castillo wrote:

> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Nov 2010 14:17:40 -0600

> In my understanding that sip or sips just have to do with the transport. The URI is the same.

Adrian is correct. RFC5630, section 4.1, says the following:

"SIP and SIPS URIs that are identical except for the scheme itself (e.g., sip:[email-masked] and sips:[email-masked]) refer to the same resource.  "

This is implied in 3261, but not stated as clearly.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Nov 2010 22:13:51 +0100

> This is implied in 3261, but not stated as clearly.

Thanks to both. Just one question more please:

If alice receives a subscription request (NOTIFY Event:
presence.winfo) from "sips:[email-masked]" and accept him, should she
store "sip:[email-masked]" or "sips:[email-masked]" in his
resource-lists?
I expect it doesn't matter :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 18 Nov 2010 22:15:48 +0100

I would say that the RLS and resource list XML data should store user@domain only, sips or sips is a matter of your reach somebody rather than  part of the uri.

Adrian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Nov 2010 22:19:20 +0100

> I would say that the RLS and resource list XML data should store user@domain only, sips or sips is a matter of your reach somebody rather than  part of the uri.

Hum, RFC 5630 section 3.3:

      When used as the Request-URI of a request, the SIPS scheme
      signifies that each hop over which the request is forwarded, until
      the request reaches the SIP entity responsible for the domain
      portion of the Request-URI, must be secured with TLS; once it
      reaches the domain in question it is handled in accordance with
      local security and routing policy, quite possibly using TLS for
      any last hop to a UAS.  When used by the originator of a request
      (as would be the case if they employed a SIPS URI as the address-
      of-record of the target), SIPS dictates that the entire request
      path to the target domain be so secured.

Note the last phrase:

      When used by the originator of a request
      (as would be the case if they employed a SIPS URI as the address-
      of-record of the target), SIPS dictates that the entire request
      path to the target domain be so secured.

So if Alice stores "sips:[email-masked]" in resource-lists, then her
device would fail when trying to contact "sips:[email-masked]" in case
Bob is just registered using UDP/TCP (not TLS). Am I wrong?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Nov 2010 22:20:32 +0100

> Bob is just registered using UDP/TCP (not TLS). Am I wrong?

Yes, I'm wrong. Just the "entire request path to the target domain"
must be secure :)

sorry.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 18 Nov 2010 22:29:17 +0100

This 'sips' stuff is a utopian concept. Even if is a must, Nobody can guarantee that each hop really uses TLS. So you should never rely on it or use for security or any other purposes.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Nov 2010 22:41:09 +0100

> This 'sips' stuff is a utopian concept. Even if is a must, Nobody can guarantee that each hop really uses TLS. So you should never rely on it or use for security or any other purposes.

But they should. This is, intermediary proxies MUST use TLS if RURI
(and Route?) contains "sips". Just the last proxy (responsible for the
target domain) can choose whenever using sip or sips.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 18 Nov 2010 22:42:47 +0100

Yes, but if they do not do it you do not know and you cannot force it.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Nov 2010 22:44:51 +0100

> Yes, but if they do not do it you do not know and you cannot force it.

The UAC can check it by inspecting the schema of the route ser URI's
in the 200 response, right? :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 18 Nov 2010 22:47:15 +0100

Not if there is a stateless proxy in the path. You will never know.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Nov 2010 23:13:33 +0100

> Not if there is a stateless proxy in the path. You will never know.

Why would a stateless proxy ignore the RURI scheme?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 18 Nov 2010 23:15:59 +0100

You do not know, is not yours you and your have no control over it. sips is not end-to-end security is just Leap of Faith.

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 18 Nov 2010 23:16:52 +0100

sips =  http://bit.ly/bpmgIe

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Nov 2010 23:53:17 +0100

> You do not know, is not yours you and your have no control over it. sips is not end-to-end security is just Leap of Faith.

Yes sure, but it doesn't depend on the type of proxy (transaction
stateful or stateless) :)

-- 
Iñaki Baz Castillo
<[email-masked]>