Subject: Re: [Sipping] GRUU Issue: who did I call?

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Feb 2005 00:38:42 -0500

Cullen,

Effectively, you will ALWAYS need to pass the To header field along with 
the GRUU. As such, your proposal is more or less to do this:

sip:gruu-user-part@domain?To=sip:aor@domain

which is remarkably similar to one of the options I listed:

sip:gruu-user-part@domain;aor=sip:aor@domain

With the difference being that the latter is at least EXPLICIT about 
what is going on, whereas the former is not.

Indeed, auto-populating headers from URI header field parameters can be 
an avenue for many attacks. For this particular example, what happens if 
a malicious user sends a gruu like this:

sip:gruu-user-part@domain?To=sip:[email-masked]

and this shows up in someones call-logs as calls to a porn site?

The To field should specify the resource to which the request is being 
targeted. In this case, that remains the gruu.

-Jonathan R.

Cullen Jennings wrote:

> I read the whole thread and I think there is a very simple solution....
> 
> The problem is that with the addition of GRUU  to SIP we have two
> addressable things - ones is a user (and addressed with AOR) and other is
> device (addressed with GRUU)
> 
> Now, some times a UA wants to send a request to a specific device but you
> also want to provide the information of who the user is. In a flash of
> brilliance it came to me. We can put the device (or GRU in this case) in the
> request URI and we can put the User in the To header.
> 
> I think this solves the case and there has been a side thread that points
> out when you do a refer to a GRUU, you need to pass the AOR in an embedded
> To header if you expect the UA receiving the refer to be able to send an
> INVITE with the To set correctly.
> 
> Cullen
> 
> 
> On 1/23/05 8:02 PM, "Paul Kyzivat" <[email-masked]> wrote:
> 
> 
>>
>>Cullen Jennings wrote:
>>
>>>Hmm - this looks like it might be going down the path of confusing user
>>>Identity in things like To and From with things that go in the contact or
>>>via header. 
>>
>>I don't think the cases I am thinking of do. Consider the simple case of:
>>
>>- I check presence of sip:[email-masked]
>>
>>- I pick a tuple from that. It has a contact of
>>   sip:[email-masked]
>>
>>- I call that.
>>
>>- A month later, looking back at the call records, I wonder what I
>>   was calling.
>>
>>That does show how certain behavior by the UAC could help. If it just
>>put the presentity address in the To, and the contact address from the
>>tuple in the R-URI, then maybe the right info would be retained.
>>
>>That violates my expectation that the UAC will start out with To and
>>R-URI the same, but in this case it makes sense.
>>
>>Paul
>>
>>
>>>On 1/21/05 6:00 AM, "Paul Kyzivat" <[email-masked]> wrote:
>>>
>>>
>>>
>>>>At various times over the last several months I have had side
>>>>conversations about problems with GRUUs. This came up most recently in
>>>>the "modeling dispatchers in the data model" thread.
>>>>
>>>>A significant issue that has been brought up is:
>>>>
>>>>To an outside observer, including the client using it, a GRUU may well
>>>>have a form that doesn't correlate in any apparent way to who was
>>>>called. And the timespan over which a GRUU remains valid may be very
>>>>bounded.  This could have at least two effects:
>>>>
>>>>- when reviewing a history of past calls, (e.g. a bill), it may be
>>>>  impossible to determine "who did I call?".
>>>>
>>>>- Sending a new request to the old GRUU may well also not work.
>>>>  This negates the experimental approach to answering the "who did
>>>>  I call?" question, and also other usages, such as "I want to ask
>>>>  one more question of that guy Alice forwarded me to yesterday."
>>>>
>>>>This issue has been identified in the context of using GRUUs as the
>>>>contact addresses in PIDF tuples. But it applies equally to GRUUs used
>>>>in other contexts, such as call transfer.
>>>>
>>>>I think this subject deserves attention, so I want to kick off some
>>>>discussion on the subject.
>>>>
>>>>==================
>>>>
>>>>I don't think it means GRUUs are a bad idea. But it does mean that more
>>>>information needs to be captured for historical purposes. We need to
>>>>figure out what that is.
>>>>
>>>>In some cases there are conflicting objectives:
>>>>- obfuscation of the callee identity may be intentional
>>>>- bounding the reachability of the callee may be intentional
>>>>
>>>>In other cases this may not be so. E.g. in the case of presence there
>>>>typically in no reason to hide who this is about - the presence document
>>>> is there to make it explicit.
>>>>
>>>>Even when the callee is not interested in cooperating, the caller
>>>>typically has some context that can help - at least to qualify who the
>>>>target was and possibly to obtain a callable address even if the gruu
>>>>itself has become invalid.
>>>>
>>>>One partial answer would be to come up with a recommended way to encode
>>>>GRUUs so that the AoR is retrievable by anyone. This would of course
>>>>have to be optional for the cases where obfuscation is desired.
>>>>
>>>>Solutions that don't require cooperation are also needed. For instance,
>>>>when calling an address retrieved from a PIDF document, it would be very
>>>>helpful to include the presentity address somewhere in the request,
>>>>where it could be captured and stored as part of the call detail.
>>>>
>>>>Similarly, when acting on a REFER, it might be helpful to ensure that
>>>>info about the referror is associated with the resulting request. (This
>>>>may already be sufficiently addressed.)
>>>>
>>>>Thoughts?
>>>>Paul
>>>>
>>>>_______________________________________________
>>>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>>>This list is for NEW development of the application of SIP
>>>>Use [email-masked] for questions on current sip
>>>>Use [email-masked] for new developments of core SIP
>>>
>>>
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: David R Oran <[email-masked]>
Date: Tue, 1 Feb 2005 09:38:37 -0500

On Feb 1, 2005, at 12:38 AM, Jonathan Rosenberg wrote:

> Cullen,
>
> Effectively, you will ALWAYS need to pass the To header field along 
> with the GRUU. As such, your proposal is more or less to do this:
>
No, I think his proposal is to leave the GRUU unchanged but put the 
target AoR in the To: field. I think the motivation is that the source 
of the request needs to always have the correlation handy, not 
back-infer the To: from the AoR either explicitly by extracting 
something, or doing some computation.

> Indeed, auto-populating headers from URI header field parameters can 
> be an avenue for many attacks. For this particular example, what 
> happens if a malicious user sends a gruu like this:
>
I think being explicit in the GRUU is exactly what may open you to 
attacks.
> targeted. In this case, that remains the gruu.
Gee, I nust be in lala-land. I thought the To: was supposed to tell you 
the AoR of the thing you want to talk to, not the specific resource 
owned by that thing. It's up to the proxies and UASs associated with 
that AoR to decide whether 
sip:[email-masked] is appropriate for 
sip:[email-masked] and reject the request if the binding is not 
valid.

The To: field may not affect routing directly, but it sure ought to 
affect authorization!

Sorry if this shows I'm completely in the weeds...

>>>>> Sipping mailing list  
>>>>> https://www1.ietf.org/mailman/listinfo/sipping
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Feb 2005 10:19:59 -0500

> something, or doing some computation.

Yes. The alternative here is that the *caller* do the correlation.

In the presence case this is pretty clear - the presentity address is 
the To, and the Contact from the tuple is the R-URI. When you just call 
an AoR, the To contains the AoR, the proxy decides which contact to use 
and puts it in the R-URI. Using presence effectively moves this logic 
back to the UAC, so it makes sense to get the same result.

It is perhaps harder in the transfer case - the transferee doesn't 
necessarily know the AoR of the transfer target. So that may be a more 
interesting case to focus on.

> I think being explicit in the GRUU is exactly what may open you to attacks.

What is the problem here?
- that you got sent to a porn site?
- that the call log says "porn-site"?

Its not immediately clear to me what the desired results are in this case.

> owned by that thing.

Well, its actually kind of vague about it:

    The To header field first and foremost specifies the desired
    "logical" recipient of the request, or the address-of-record of the
    user or resource that is the target of this request.

That pretty much covers all the bases. If all you have been told is the 
address of a specific resource, then to you that *is* the logical recipient.

> It's up to the proxies and UASs associated with 

> The To: field may not affect routing directly, but it sure ought to 

While I certainly think it is *permissible* to do this, I don't think we 
should be counting on it being done. Since routing is done on the R-URI, 
it is something responsible for that which will be doing whatever 
authorization is done. If it would normally accept a call from this 
caller, I don't see why it would want to reject it because the To has a 
value it doesn't expect.

I think it is more plausible that it would either ignore it, or perhaps 
note that it is unusual and alert in a special way, so the user can take 
this into account when deciding whether to answer.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 01 Feb 2005 09:33:20 -0800

> sip:gruu-user-part@domain;aor=sip:aor@domain

And what happens when I do

sip:gruu-user-part@domain;aor=sip:aor1@domain?To=sip:aor2@domain

Do you use aor 1 or 2? Jon and I have been arguing very hard against
introducing more names and identities in SIP because there are two many
already to implement security correctly. This effectively introduces another
one and, given I see no need to introduce a new one, this seems like a bad
idea. 

> what is going on, whereas the former is not.
I disagree - it's as specific as some draft defines it to be. Wherever you
are going to define the aor= stuff for GRUU, just get explicit about
defining embedded To. What it means, that you MUST do it, and how to do it.

> and this shows up in someones call-logs as calls to a porn site?
I don't think I get your point here. What happens if you get a phone call
from hot-sip-babes and it shows up in a call log? Why would you log To? Do
you bill off To? So many questions.

Anyways, I suspect that if you want the To to be meaningful, then the
current Identity work helps provide this.

> targeted. In this case, that remains the gruu.

Should the To field specify the User or Device that the request is being
targeted to. I think it is very clear that it needs to specify the User. I'm
glad to see that your think the To should be meaningful in this way because
that is has been the crux of the arguments around the Identity work.

Cullen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Feb 2005 17:14:50 -0500

inline.

> one and, given I see no need to introduce a new one, this seems like a bad

Sorry for not being clear here. I *don't* like the ;aor=sip:user@domain 
approach. I was merely likening a solution that used an embedded To URI 
header field parameter to that approach, and arguing that I felt it was 
worse still.

> you bill off To? So many questions.

Its a question of guilt; I am doing wrong if I call such a number, not 
so if one calls me (well, unless the logs indicate a 2 hour call 
resulted ;) ).

My point is only that the general idea of using URI header field 
parameters to create the TO field is not one I like, and for the most 
part RFC 3261 warns strongly against silently accepting many such header 
field parameters.

> that is has been the crux of the arguments around the Identity work.

SIP URIs represent resources. Nothing in the specs say that these have 
to be users as opposed to devices or services. Whatever is the resource 
I have decided I want to reach, that is what goes into the TO field. 
WHen I "dial" a gruu, it means I am trying to reach a resource that is, 
in this case, an instance, and so to me that means that the GRUU belongs 
in the To header field.

Similarly, if I call an IVR service - sip:[email-masked], that 
URI should go in the request URI and the To field. There is no user here 
at all - only a service.

Thanks,
Jonathan R.