[Sipping] [Fwd: Re: Discuss on draft-ietf-sipping-gruu-reg-event-06]

[Paul Kyzivat <[e-mail]>]

Below is a discussion I had with Cullen about the gruu-reg-event draft.
I would like to get feedback from others about this.

Based on some phone calls of interested parties about gruu, Jonathan is 
updating the gruu draft in a number of ways that will affect this draft 
as well. Of particular note, there will now be two gruus returned: a 
regular (public) one much like has been there until now, and a 
(pseudo-)anonymous gruu.

I intend to update this draft in the next few days to align with where 
the gruu draft is going. Instead of the single new <gruu> element, there 
will be separate elements for the public and anonymous gruus. Security 
considerations will differ for the two. I intend RECOMMEND that the 
anonymous gruu only be included for subscribers that are also authorized 
to REGISTER.

If anybody has different opinions, please speak up asap. I intend to 
release a new version this week.

	Thanks,
	Paul

-------- Original Message --------
From: Cullen Jennings <[e-mail]>
To: Paul Kyzivat <[e-mail]>
CC: Mary Barnes <[e-mail]>, 
[e-mail],        Jon Peterson 
<[e-mail]>
References: <[e-mail]> 
<[e-mail]>


ok - sounds reasonable to me.


On Sep 25, 2006, at 6:53 AM, Paul Kyzivat wrote:

> Cullen,
>
> Thank you for the feedback. It is appropriate. I think it would be  
> appropriate to take this discussion to the sipping list, but I have  
> not done so with this message.
>
> Comments inline.
>
> 	Paul
>
> Cullen Jennings wrote:
>> Hi All,
>> I updated my discuss comment -  and attached it below to this  
>> email since I realize it may not have made it to everyone. WIth my  
>> individual hat on, I'm glad to help work on figuring out some text  
>> to resolve this.
>> Cullen
>> -----------------
>> It's really scary to progress this ahead of GRUU.
>
> I agree. I don't think it *should* be progressed ahead of GRUU.  
> GRUU has been "almost done" for a very long time now. I had always  
> assumed that this would be in the pipeline behind it.
>
> I don't know the proper mechanism, but I have no objection with  
> having this put on hold until the GRUU issues are resolved, so that  
> it can be coordinated with whatever changes are applied to GRUU.
>
>> The issues is that it is not clear what GRUU will do with the  
>> anonymous property. If some GRUU decides to have the anonymous  
>> property, then we need to decide if the security considerations  
>> for anonymous GRUU are different than non anonymous GRUUs. It  
>> seems likely that due to the stateless implementations of GRUU,  
>> this will not be able to report every GRUU but only one non  
>> anonymous one.
>
> In addition to the question of whether is it *possible* to report  
> every anonymous gruu, there is the question of whether one *should*  
> report anonymous GRUUs.
>
>> I realized later my comment had not made it obvious enough how  
>> this could be resolved. GRUUs, being a URI, have the potential to  
>> have many properties as GRUU points out. The security section  
>> probably wants to mention say that what gets handed out in a reg  
>> event depended on the properties of the GRUU and the authenticated  
>> users of the subscribe. Specifically one could say something along  
>> lines of if a GRUU also has the anonymous property, then it MUST  
>> NOT be handed out to any one other than users that can  
>> authenticate as the same principal as the AOR in question. This  
>> allows this draft to be correct regardless what way we go on GRUU  
>> with regards to anonymous properties.
>
> The above may resolve the issue of whether one should.
>
> However, at least in some of the formulations proposed, there may  
> end up being separate gruus with public and anonymous properties.  
> If there is ever a case when both are to be returned, then the  
> draft will need to be changed to accommodate that, including  
> perhaps also identifying what properties each gruu has.
>
>> I think it would also be worth discussing what gets handed out to  
>> users that can not authenticate as the same AOR. Some systems that  
>> are deployed today allow any user anywhere, say Alice, to  
>> subscribe to Bob's reg event so that when Bob comes "on-line",  
>> Alice can send a subscribe for presence to Bob.
>
> This is certainly a possibility, though IMO it is not an ideal  
> strategy. At the least it makes the unjustified assumption that a  
> user with no registrations also has no interesting presence status.
>
>> This allows Alice to track when Bob's soft-phone is on or offline  
>> and the location of the IP address for Bob. This more or less  
>> circumvents all authorization work we did for presence.
>
> Seems like a bad idea unless the same kind of authorization is done  
> on it as for presence.
>
>> Now you can argue this is a good or bad thing but the security  
>> sections of gruu-reg-event and reg-event that it depends on don't  
>> even give a hint to implementers about what to do here or even  
>> that the issues exists.
>
> When written, I made the assumption that the gruu was no more, or  
> less, sensitive than the Contact address. And the arguments over  
> GRUU formats that make it easy to derive the AOR aren't an issue in  
> this case, since if you are subscribing to the reg event package  
> you have already demonstrated knowledge of the AOR.
>
> But the story is definitely different for anonymous GRUUs. One  
> might make the case that an anonymous GRUU should *never* be  
> provided in this way - that it is intended to be kept anonymous  
> until disclosed by the UA to which it is assigned. But what would  
> present a problem for IMS, with their implicit registration sets,  
> where this is *the* mechanism for discovering the GRUUs of  
> implicitly registered AORs.
>
>> I don't think we should get too worked up about hiding information  
>> that Alice could discover by sending a probe INVITE to Bob. I do  
>> think we should mention this.
>> I do think there are ways to get this done before GRUU.
>
> There is no compelling reason to get this done *before* gruu, since  
> it is of no value without. But there is good reason to want to get  
> it done at the *same* time as GRUU.
>
> If it is decided to split off work on anonymous gruus, to follow  
> behind the work on public gruus, then I'd like to see this progress  
> in step with the public gruu work. If support for anonymity is to  
> be added to *the* gruu draft, then I think it makes sense to modify  
> this draft to track that.

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