Re: [Sip] GRUU and sips

[Adam Roach <[e-mail]>]

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. 
Perhaps it is worth reiterating this point in the GRUU document, but it 
seems like this is a non-problem.

/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" <[e-mail]> 
>>>> 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 [e-mail] for questions on current sip
>>>> Use [e-mail] 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 [e-mail] for questions on current sip
>>> Use [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip