Re: [Geopriv] teasing apart: http as a GEOPRIV using protocol

Hi Keith,

please find my response below:

Drage, Keith (Keith) wrote:
> (As individual)
> 
> At the moment I'm afraid I don't buy the argument.


> 
> Starting from RFC 3693, section 3 defines:
> 
> 	Using Protocol: A protocol that carries a Location Object.
> 
> For which we also have:
> 
>       Location Object (LO): An object conveying location information
>          (and possibly privacy rules) to which Geopriv security
>          mechanisms and privacy rules are to be applied.
> 
> Section 4 defines the primary GEOPRIV entities and 
> this defines a model:
> 
> (Now for SIP location by value, the using protocol is SIP, and the SIP
> UAC is the location server, and the SIP UAS (or possibly proxy) is the
> location recipient.)
> 
> For SIP location by reference, the using protocol is the dereferencing
> protocol, i.e. the reader of the Location header is the location
> recipient, and the server referenced by the URI is the location server.
> The SIP protocol is this case is not a using protocol, because it does
> not contain a location object. Therefore it falls outside the rules of
> using protocols specified by GEOPRIV.

The problem is that this document was written some time ago. We haven't 
thought about many things at that time. Hence, it is fine to say that it 
has to be a using protocol but what does this tell us exactly? Nothing 
since we have to worry about privacy/security aspects with every 
document we develop.

The entire mailing list thread started with a few security related 
questions that Henning and myself raised. I do not recall that we made 
progress with any of these security questions. Instead we go along the 
road of terminology discussions.

> 
> I see nothing in RFC 3693 that prevents a third party entity holding
> location on behalf of a user, and in fact some of the examples seem to
> show exactly that.

That's explicitly supported.

> 
> Now presumably all the security and privacy constraints relating to the
> user are covered by the using protocol. The fact that I tell you that X
> has my location doesn't mean you are entitled to receive it. Further,
> while there may be some other protocol (or bilateral agreement or
> whatever) that covers the relationship between X and the user, I do not
> see any requirement in RFC 3963 that mandates that.

I believe that security is part of the architecture and in this case 
several protocols play together. I don't want to get the security work 
being pushed to the HTTP using protocol.

> 
> At the moment you seem to be arguing that information about who has my
> location is subject to some form of consent framework over and above
> that required by the using protocol itself. I'm afraid I do not see that
> argument at all. Agreed the URI of the server may say something about
> the user's location, but to me this is covered by the following
> statement in RFC 3693:

I don't think I said that.

> 
>    Excluded from this definition is the determination of location
>    information wholly without the knowledge or consent of the Target (or
>    the Target's network or access service provider), based on generally
>    available information such as an IP or e-mail address.  In some
>    cases, information like IP address can enable someone to estimate (at
>    least roughly) a location.  Commercial services exist that provide
>    rough location information based on IP addresses.  Currently, this
>    type of location information is typically less precise than the type
>    of location information addressed in this document.  Although this
>    type of location computation still raises significant potential
>    privacy and public privacy concerns, such scenarios are generally
>    outside the scope of this document.
> 
> We have specified lots of things in SIP and many other protocols that
> need lots more rules if this is going to become an issue.
> 
> Furthermore, if I follow your argument to its logical conclusion, then I
> would seem to need lots more work before I can put a URI that points at
> a location server in an ordinary email, yet I seem to be able to do that
> today.

If I just put a location server URI into the mail then there is still 
the question how you would obtain my location information.

If my email address is used for this purpose then you would have just 
created a very nice privacy leaking system. Everyone that knows the 
location server and my email address could learn my location.

Furthermore, mail relays would be able to see that information and could 
happily use it.

Btw, you can also put location information into a mail today and without 
signing and privacy rules it would be bad as well.


> 
> So in conclusion, I see location by reference as two independent
> protocols:
> 
> -	a location using protocol which is the deferencing protocol, and
> which obviously has to meet the using protocol requirements.
> 
> -	a URI carried by SIP which is subject to no normative
> constraints about who can read or whatever, which identifies the
> location server.

I would particuarly like to make anyone aware that these are not just 
two independent protocols. I strongly believe that you can make the 
security/privacy independent for each of them. You have to consider the 
big picture.

We do this all the time. Take for example, the SAML work. Two 
"independent things": SAML and SIP
Still, there are many aspects to consider.
The SAML community calls these interworking between two (or more 
protocols) 'profile'. What we do here is essentially the same.

A recent comment that the end host should indicate whether it wants the 
SIP proxy to add something is also a topic for SIP-SAML. If an entity 
acts on behalf of the end host then it needs to be aware of the context 
this entity is in (Henning would call it sphere).

> I agree that there may be arguments for giving more information to the
> location recipient so that the location recipient knows how to populate
> the dereferencing protocol. Some of this may however already be covered
> by other SIP protocol work, and to me is not directly necessary to make
> the protocol work. If we agree any information in time, we can include
> it, otherwise it can be added at a later stage. 

Ciao
Hannes



> 
> 
> Regards
> 
> Keith
> 
> 
>>-----Original Message-----
>>From: Hannes Tschofenig [mailto:[email protected]] 
>>Sent: 27 July 2006 16:36
>>To: Andrew Newton
>>Cc: IETF SIP List; GEOPRIV
>>Subject: Re: [Geopriv] teasing apart: http as a GEOPRIV using protocol
>>
>>Hi Andy,
>>
>>if we talk about location-by-reference then I think all 
>>solutions need more specification work.
>>
>>If we talk about end host adding a reference then we need to 
>>have a story about the source of the reference. This is 
>>subject to the current
>>Geopriv-L7 DT work that is not yet finished.
>>
>>If we are talking about the case where the SIP proxy adds a 
>>reference (no matter what type of reference it is) then also 
>>further work is needed.
>>
>>I think we should develop an HTTP based solution since it is 
>>very simple.
>>
>>Btw, I am not sure that the name 'using protocol' is actually 
>>appropriate in this case. We haven't used the term using 
>>protocol for the Geopriv L7 work either. Terminology is hell 
>>in this area.
>>
>>Ciao
>>Hannes
>>
>>Andrew Newton wrote:
>>
>>>There have been a number of opinions regarding HTTP as a 
>>
>>using protocol.
>>
>>>I'd like to know, how many people believe that HTTP requires no or  
>>>very little specification to meet the requirements in RFC 3693 and  
>>>RFC 3694.  If you believe this, what basis do you have for this 
>>>conclusion?  Or do you believe more specification needs to 
>>
>>be done,  
>>
>>>but it is possible for HTTP to be a GEOPRIV using protocol?
>>>
>>>Finally, how many people believe that HTTP should not be a 
>>
>>using  protocol?
>>
>>>-andy
>>>
>>>_______________________________________________
>>>Geopriv mailing list
>>>[email protected]
>>>https://www1.ietf.org/mailman/listinfo/geopriv
>>>
>>>
>>
>>
>>_______________________________________________
>>Geopriv mailing list
>>[email protected]
>>https://www1.ietf.org/mailman/listinfo/geopriv
>>
> 
> 
> 


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