RE: [Geopriv] Consensus on changes to location-conveyance

At 2:45 PM -0400 7/25/06, Rosen, Brian wrote:
>Summarizing, you think hop-by-hop security (TLS) is acceptable when the
>location is sent for the purposes of location based routing, but you are
>not in favor of defining "retransmission=no" to permit sending the
>location to the routing database (e.g. LoST).  You want a more explicit
>permission.

Yes.

>I don't think a cid: with a ruleset is acceptable, as it would not
>permit location by reference added by a proxy to specify this.

Fair enough.



>If this is the consensus, I think we would have to add a bit to the PIDF
>to explicitly control this behavior.

I think an extension that says "retransmission for routing=yes" is the cleanest
way to go.


>Why do you think we must specify an HTTP dereference procedure in this
>document?  What is the purpose when the SIP based method is available?
>We had believed we had to have SOME method of dereferencing to make
>location-by-reference meaningful in the document.  If we have one sip
>based method, we meet the requirement.  Having more options, especially
>completely new HTTP based protocols IN THIS DOCUMENT seems unnecessary
>and unwise.  For example, if we define such a protocol, it becomes a
>geopriv "using protocol" and needs an explicit analysis against the
>geopriv criteria.

I don't think we have to do it in this document, but I read your previous
message as a statement of consensus about the HTTP dereference mechanisms
that have been discussed.   I don't agree with that statement, since I think the
HTTP discussions somewhat over-thought the potential problems.  In particular, a
lot of the discussion was around the idea that http://dereference.example.org/foo-pidf-lo
might mean lots of different things, depending on what http meant.  There are
already ways to deal with that; none of them are perfect (see, for example,
the discussion in draft-reschke-webdav-mount-05.txt and its appendix A for a similar
problem in a different context), but they can work, especially if you set a baseline
approach.

				regards,
					Ted Hardie



>Brian
>
>> -----Original Message-----
>> From: Ted Hardie [mailto:[email protected]]
>> Sent: Tuesday, July 25, 2006 2:19 PM
>> To: Rosen, Brian; [email protected]
>> Cc: [email protected]
>> Subject: Re: [Geopriv] Consensus on changes to location-conveyance
>>
>> At 1:38 PM -0400 7/25/06, Rosen, Brian wrote:
>> >4. We proposed to explicitly allow hop-by-hop TLS security for
>location
>> >when the endpoint wished to allow routing based on location.  We
>further
>> >proposed to interpret "Do not Distribute" flags as allowing sending
>of
>> >the location to the routing database (LoST for example).  Hannes
>pointed
>> >out that there was a proposal to allow two Location headers, one of
>> >which could be used for routing and another for onward forwarding to
>the
>> >recipient.  Hannes' message seemed to agree that "Do not distribute"
>> >would allow sending of the location to the routing-by-location
>database,
>> >but would obligate the proxy that did that to remove the location
>before
>> >it forwarded the message.  There were no other messages on this
>thread.
>>
>> Actually, I commented on the same problem, though it may have been
>> connected to one of the related threads; here's the text of that
>message:
>>
>> >At 5:23 PM -0400 7/19/06, Brian Rosen wrote:
>> >>NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT
>> ONLY TO
>> >>GEOPRIV
>> >>However, this opens up the issue of geopriv privacy concerns because
>the
>> >>sender does not know the identity of the element (proxy) that will
>route
>> the
>> >>call using LoST.  It may be that the UAC itself does this, but it
>may be
>> >>some other intermediary.
>> >>
>> >>If the identity of the intermediary is not known, then protecting
>the
>> >>location information becomes more difficult, because we cannot
>encrypt
>> using
>> >>keying material from the intended recipient.
>> >
>> >Just to mention this, it appears to also rule out the idea of
>encrypting
>> >with the user's key, since there is no way of knowing whether the
>> "intended
>> >recipient" has that key material either.  Intended recipient is
>actually
>> >a bit of a problematic term here, since it's really the on-path
>network
>> elements
>> >which consume the information.  They aren't the intended recipient of
>> >the communication, they are the recipients of the signaling (of which
>> location
>> >is now a part).
>> >
>> >This is a bit confusing because it seems to be possible to include a
>> >"re-transmission allowed"  rule with a value of "no" (intended to be
>> >consumed by the "intended recipient" of the underlying
>communication),
>> >while still wanting to allow the location to be passed along the
>path.
>> >
>> >>In fact, we would need to use
>> >>hop-by-hop security, with transitive trust.  This is what the
>emergency
>> case
>> >>does, but it also allows no channel security if necessary (usually
>> meaning,
>> >>try it with TLS and if that fails, try again without TLS).
>> >
>> >While I certainly encourage hop-by-hop security, I don't think it
>really
>> >meets the geopriv privacy concerns.  I think you  have to have some
>way
>> of
>> >expressing "re-transmission for routing permitted" (and likely
>retention
>> >limited), since that is a separate statement.
>> >
>> >Just typing aloud here, but could we come up with a way to use an
>> >external ruleset to express this?  With an embedded cid, that would
>> >not actually require dereferencing.
>> >					Ted
>> >
>>
>>
>>
>> >We conclude that allowing hop-by-hop security for location based
>routing
>> >is acceptable, and Do Not Distribute DOES allow forwarding to a
>routing
>> >database, but requires that the proxy doing the location based route
>to
>> >remove the location it uses for that purpose.
>>
>> To reiterate this, I do not believe that this is sufficient; I think
>you
>> have to
>> have some way of saying "re-transmission for routing permitted" before
>> you meet the geopriv privacy concerns.
>>
>> >5. We proposed to create a parameter and a registry to distinguish
>> >multiple ways to dereference a location where HTTP(S) was the
>transport.
>> >Resolution of this issue depends on resolution of issue 6.
>>
>> I believe that an HTTP GET of a PIDF-LO object is a reasonable
>baseline.
>> Saying that other mechanisms should update this document with their
>> dereferencing mechanisms if they could be confused with the baseline
>> seems to me to be sufficient.  I'm not sure a registry is needed.  In
>> practice,
>> I don't think we would hit the interoperability problems often. These
>> days,
>> extensions to HTTP commonly use different  mime types to indicate the
>> special
>> handling, and I expect anyone creating a more feature-rich
>dereferencing
>> mechanism built on HTTP would not end up using pidf-lo.
>>
>> That means the "uri confusion" aspects of the discussion are probably
>not
>> that severe.  The only issue is if someone supports only the more
>feature-
>> rich
>> alternative and not a baseline GET of the pidf-lo.  I think we should
>> discourage that, by establishing a real baseline.
>>
>> Note also that HTTP URIs don't indicate the HTTP Method directly;
>often
>> they
>> support multiple methods (e.g. HEAD and GET).
>>
>> >6. We proposed to allow sip/sips and pres: in the location header.  I
>> >later speculated that if we allow this, it forms a simple way to do
>> >location-by-reference, and we could eliminate the raw HTTP(S) Get
>> >proposal, with the parameter and registry entirely.  There was some
>list
>> >traffic in favor of this.  Martin Thompson is skeptical that SIP
>> >Presence Subscribe/Notify is actually allowed as a geopriv "using
>> >protocol".  Several of think that it is.  If we don't get any more
>> >comments on this proposal, we will allow sip/sips and pres, not have
>any
>> >http(s) resolution text, and not propose a parameter and accompanying
>> >registry.
>>
>> I share some of Martin's skepticism here, but I won't fall on my sword
>> if the WG goes in this direction.
>>
>> Thanks for the clear set of issues and opportunity to comment,
>>
>>					Ted Hardie


_______________________________________________
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