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

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.

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.

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

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.

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