Subject: [Sip] RE: [Geopriv] teasing apart: http as a GEOPRIV using protocol

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 27 Jul 2006 19:12:49 +0200

(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.

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.

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.

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:

   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.

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 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. 

Regards

Keith

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> 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-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> > 
> > 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 20:01:58 +0200

Hi Keith,

please find my response below:

> 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.

> location on behalf of a user, and in fact some of the examples seem to

That's explicitly supported.

> 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.

> the user's location, but to me this is covered by the following

I don't think I said that.

> a location server in an ordinary email, yet I seem to be able to do that

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.

> constraints about who can read or whatever, which identifies the

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).

Ciao
Hannes