Re: [Sip] GRUU and sips

Jonathan Rosenberg <jdrosen@cisco.com> Mon, 08 November 2004 14:44 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14054 for <sip-web-archive@ietf.org>; Mon, 8 Nov 2004 09:44:38 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAlc-0002lz-Ms for sip-web-archive@ietf.org; Mon, 08 Nov 2004 09:45:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAPE-0003Py-4Q; Mon, 08 Nov 2004 09:22:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAGG-0001Id-FA for sip@megatron.ietf.org; Mon, 08 Nov 2004 09:12:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10415 for <sip@ietf.org>; Mon, 8 Nov 2004 09:12:46 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAGo-0001mw-31 for sip@ietf.org; Mon, 08 Nov 2004 09:13:22 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2004 06:23:41 -0800
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA8EC8nC007241; Mon, 8 Nov 2004 06:12:09 -0800 (PST)
Received: from [130.129.135.140] (sjc-vpn1-592.cisco.com [10.21.98.80]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFP06381; Mon, 8 Nov 2004 06:12:11 -0800 (PST)
Message-ID: <418F7EBB.4040104@cisco.com>
Date: Mon, 08 Nov 2004 09:12:11 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>
Subject: Re: [Sip] GRUU and sips
References: <BD293668.BBEF%fluffy@cisco.com> <5.2.1.1.0.20040806093622.01542d40@pop.mcilink.com> <4113A68C.60704@cisco.com> <418D7220.80907@nostrum.com>
In-Reply-To: <418D7220.80907@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA10415
Cc: Alan Johnston <alan.johnston@mci.com>, Cullen Jennings <fluffy@cisco.com>, Paul Kyzivat <pkyzivat@cisco.com>, "sip@ietf.org" <sip@ietf.org>, Robert Sparks <rsparks@dynamicsoft.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955
Content-Transfer-Encoding: quoted-printable


Adam Roach wrote:

> I'm getting in a bit late on this thread (sorry), but I've been under 
> the impression for quite some time that sip:foo and sips:foo are 
> *defined* to be the same resource under all circumstances. Section 19.1 
> of 3261 seems rather clear on this point:
> 
>>    Any resource described by a SIP URI can be
>>    "upgraded" to a SIPS URI by just changing the scheme, if it is
>>    desired to communicate with that resource securely.
> 
> 
> 
> So, if we just hand out sip: URIs, then full 3261 implementations *know* 
> that they can use it with a sips: scheme and get the same resource. 

Thanks for pointing this out; I had forgotten this was in there. I think 
this at least implies that the two URIs, if they exist, point to the 
same resource. But, it doesnt address questions like whether both have 
to exist, or more specific questions about sips URI in GRUU.


> Perhaps it is worth reiterating this point in the GRUU document, but it 
> seems like this is a non-problem.

I think we need to say the following:

If a sip and sips URI exist, they should point to the same resource
   Existence of sip doesn’t imply sips and vice a versa
If contact is sip, gruu is a sip URI, but the server creates the sips
   resource (i.e., it will accept and handle sips if it can do a secure
   connection)
If the contact is sips, the gruu is sips, but the server does not create
   the sip resource
     Allows for sips only resources

I'll be talking about this today in sip

Thanks,
Jonathan R.

> 
> /a
> 
> 
> Paul Kyzivat wrote:
> 
>> Alan,
>>
>> Did you see my later message on this subject?
>>
>> As far as bid down, that is only a problem if the UAS isn't aware that 
>> it happened. Note that no matter what we say, bad guys can make the 
>> change, so it isn't the change that matters, but how it is handled 
>> along the path.
>>
>> In a direct connection, the UAS can see whether the r-uri is sip/sips. 
>> If the r-uri is sip it may conclude that the session isn't secure. For 
>> indirect connections it becomes the obligation of the proxies along 
>> the path to use a sip r-uri if the connection can't be guaranteed 
>> secure to them.
>>
>> My concern, beyond understanding how GRUU should work, is that a UAS 
>> that wants to support both secure and insecure communication should 
>> only need to make one registration. I have feeling people widely think 
>> things should work this way, but the standard isn't clear if/how this 
>> can be achieved.
>>
>>     Paul
>>
>> Alan Johnston wrote:
>>
>>> At 10:35 AM 7/27/2004 -0400, Paul Kyzivat wrote:
>>>
>>>
>>>> Cullen Jennings wrote:
>>>>
>>>>> Sounds like a possibility. Can you think of a way where I do not 
>>>>> have to
>>>>> Register twice to get both a sip and sips URL?
>>>>> Perhaps we should just say that is a proxy hands out a sip GRUU 
>>>>> sip:foo then
>>>>> sips:foo MUST also be a valid GRUU with the contact moved to sips 
>>>>> from sip.
>>>>
>>>>
>>>>
>>>>
>>>> That would rule out proxies that support gruu but not TLS.
>>>>
>>>> I think the converse might make more sense - if the proxy hands out 
>>>> sips:foo then sip:foo MUST also be a valid GRUU.
>>>
>>>
>>>
>>>
>>> Are you sure this is a good idea?  Doesn't this open a bid down 
>>> attack for the GRUU + grid dialog identifier described by Robert in 
>>> his dialog reuse draft?
>>>
>>> Here's the example - I have a secure SIP dialog with you.  You are 
>>> using a secure SIP GRUU + grid dialog identifier.  I pass this GRUU 
>>> to another party, such as Robert with a Replaces header field in a 
>>> REFER for the intent to transfer you to Robert.  Robert changes the 
>>> URI to a regular SIP GRUU and sends the INVITE with Replaces.  If you 
>>> accept this, you have replaced a secure SIP session with an insecure 
>>> session - not a good idea.  Better for this transfer to fail if 
>>> Robert tries to downgrade the security on the connection.
>>>
>>> I would say a sips:foo GRUU MUST NOT be valid as sip:foo to avoid 
>>> this kind of attack.
>>>
>>> Thanks,
>>> Alan Johnston
>>>
>>>
>>>>         Paul
>>>>
>>>>> If I get a sip GRUU, others can still use TLS to contact it. I 
>>>>> would like to
>>>>> make sure that the following case works:  a UA only does UDP to 
>>>>> it's proxy,
>>>>> however, it want communications from outside the domain to use TLS 
>>>>> to the
>>>>> proxy. I think this works fine with what you are proposing.
>>>>> On 7/23/04 12:27 PM, "Jonathan Rosenberg" <jdrosen@dynamicsoft.com> 
>>>>> wrote:
>>>>>
>>>>>> The current GRUU spec says very little about interactions between 
>>>>>> GRUU
>>>>>> and sips, and I think its sufficiently non-obvious that a 
>>>>>> discussion is
>>>>>> warranted.
>>>>>>
>>>>>> Specifically, under what conditions would the registrar provide the
>>>>>> client with a gruu that is a sips URI?
>>>>>>
>>>>>> I think the right answer here is that if teh Contact URI is a sips 
>>>>>> URI,
>>>>>> then the registrar MUST return a gruu which is a sips URI. If the
>>>>>> contact URI is not a sips URI, the registrar MUST NOT return a 
>>>>>> sips URI.
>>>>>>
>>>>>> Other thoughts?
>>>>>>
>>>>>> Thanks,
>>>>>> Jonathan R.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>> This list is for NEW development of the core SIP Protocol
>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>>>> Use sipping@ietf.org for new developments on the application of sip
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>> This list is for NEW development of the core SIP Protocol
>>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>>> Use sipping@ietf.org for new developments on the application of sip
>>>
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>>
>>
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip