Instead, I'll just note that there are a few places where 2119 text is used to mandate behaviour that is outside the scope of the document and certainly not necessary to ensure interoperability.
For instance,
Implementations MAY choose whether or not to inform the user of this
error. The text string of "Retry Location Later with device updated
location" is RECOMMENDED, but not mandatory for usage in this
error. Implementation MAY use another text string to inform the
user that location was not received by the UAS (i.e., the called
party).
--Martin
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Hannes Tschofenig
> Sent: Wednesday, 29 July 2009 8:24 PM
> To: 'Gonzalo Camarillo'; 'SIPCORE'
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] [sipcore] WGLC:draft-ietf-sipcore-location-
> conveyance-01.txt
>
> Hi Gonzalo,
> Hi James, Hi Brian,
>
> I have done a review of the SIP Location Conveyance already earlier
> this
> year (in March 2009),
> see http://www.ietf.org/mail-archive/web/geopriv/current/msg06955.html.
> I
> re-did it
> for http://www.ietf.org/id/draft-ietf-sipcore-location-conveyance-
> 01.txt.
>
> * I believe that the document should try to avoid the term "using
> protocol"
> at all costs.
> As we know, this term is very confusing and adds no particular value.
>
> Example: Other protocols used in the Location URI MUST be reviewed
> against the RFC 3693 criteria for a Using Protocol.
>
> In human readable language this means: "You have to consider security
> and
> privacy with new extensions." Wow. What a surprising statement!
>
> * Don't understand why this document does not allow a HELD URI to be
> conveyed. I commented this already several times.
>
> Even the IANA registry appears unnecessary for me. You have error
> messages
> defined
> for the cases where the URI isn't understood.
> There aren't too many new protocols to be expected.
>
> * Based on the other list discusssions around this draft I suspect that
> information
> about what the location refers to will be described in a future version
> of
> the document.
>
> * This document is about the transport of a PIDF-LO and not about
> describing
>
> what deployments should do.
>
> Example:
> "
> Adding a new locationValue to an in-transit request SHOULD NOT
> occur for at least two reasons,
>
> #1 - SIP Servers are not the best Sighters, as defined by [RFC3693],
> of geographically where a UAC can be; meaning the location
> information is not necessarily the greatest. There MAY be
> exceptions, but this SHOULD be the rule of thumb.
>
> #2 - without appropriate caution to the fact that Location
> Recipients might not understand how to process more than one
> location, given this document's limited guidance as to what a
> Location Recipient should do when receiving more than one
> location (i.e., currently no priority instructions are given
> for which locationValue to use if there are more than one). A
> Location Recipient can easily be confused by too much location
> information, producing undesirable results. The <tuple id>
> element in the PIDF-LO XML indicates whose location is
> contained in the PIDF-LO.
> "
>
> This example also shows inappropriate usage of RFC2119 language, which
> should
> be used for interoperability.
>
> We know who wants some of this functionality and what the exact use
> case it.
>
> Btw, the term "sighter" is not defined anyway (and not in RFC3693
> either).
> Here is the relevant text part:
>
> This document gives no guidance how this is accomplished, given the
> number of ways a UAC can learn its location, or a SIP intermediary
> can **Sight** a UAC, as defined in [RFC3693].
>
> * In my previous review I complained about the error codes and the
> thought
> that went into them.
> I was wondering whether someone (maybe the authors?) has implemented
> this
> specification in the meanwhile and has gained some
> experience with the error handling already. Are the error codes
> suffient?
> Well enough described?
>
> * I might be too tired today already but the example shown in Section
> 5.1
> seems to be wrong.
>
> It says:
>
> "
> ...
> <gp:location-info>
> <gml:location>
> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
> <gml:pos>33.001111 -96.68142</gml:pos>
> </gml:Point>
> </gml:location>
> </gp:location-info>
> ...
> "
>
> It should say:
>
> "
> ...
> <gp:location-info>
> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
> <gml:pos>33.001111 -96.68142</gml:pos>
> </gml:Point>
> </gp:location-info>
> ...
> "
>
>
> *
> "
> Use of self-signed certificates is inappropriate for use in
> protecting a PIDF, as the sender does not have a secure identity of
> the recipient.
> "
>
> This sentence does not make a lot of sense to me. You can use self-
> signed
> certificates for protecting a PIDF before sending it to me.
> The important thing is to make your self-signed cert available to me.
>
> * This document does not need to repeat the text from other documents.
> Example:
> "
> When using LbyR, the location URI MUST NOT contain any user
> identifying information. For example, use something unidentifiable
> like
> "
>
> Already in the LbyR requirements document. Reference it -- no need to
> write new text. That's why we have written these other documents.
>
>
> * "
> If the Location Generator wishes to control whether any location
> included in the SIP request or added along the signaling path of
> this request can be viewed for routing decisions, the Location
> Generator adds a Geolocation header value including the
> "routing-allowed=no" parameter.
> "
>
> Replace "Location Generator" by "Rule Maker".
>
> * Remove useless statements. Example:
> "
> Unless stated otherwise by future standards-track publication(s), a
> LbyR URI only has meaning within the Geolocation header field and
> MUST NOT appear in any other SIP header field.
> "
>
> * Avoid author bias. Example:
>
> "Proxies inserting location for location-based routing are
> unable to meet this requirement, and such use is NOT RECOMMENDED."
>
> The document defines functionality to allow the proxy to add location
> and we
> know who is going to use this.
>
> The text further says:
> "
> Proxies
> conveying location using this extension MUST have the permission of
> the Target to do so.
> "
> Is a Service URN with a service:sos parameter good enough as a
> permission?
> Or what **permission** mechanism are you think about?
>
> *
> "
> Any idea of using SIP Identity is lost as soon as it is
> realized that the Geolocation header value can be added to by
> intermediaries in the signaling path.
> "
>
> That's not the problem. The problem is that the signature calculation
> of SIP
> Identity
> does not cover these new headers.
>
> * I like this acknowledgement "To Dave Oran for helping to shape this
> idea."
>
> The idea that location can be carried in SIP?
>
> * Geopriv Privacy Considerations
>
> This section is pretty useless but I wanted to ask one thing about the
> following text:
>
> "
> Quoting requirement #4 of [RFC3693]:
>
> "The Using Protocol has to obey the privacy and security
> instructions coded in the Location Object and in the
> corresponding Rules regarding the transmission and storage
> of the LO."
>
> This document requires that SIP entities sending or receiving
> location MUST obey such instructions.
> "
>
> What about a SIP node that does not understand SIP location conveyance?
> It sends and receives the messages related to location messages.
>
>
> * Avoid inappropriate treatment of subjects that are discussed
> somewhere
> else. You discuss topics that have been described elsewhere and are
> therefore
> clearly outside the scope of this document.
>
> "
> One facet within this extension is such that locations can be placed
> on a remote server, accessible with the possession of a URI. The
> concept of an LbyR URI has its own security considerations. It is
> tempting to assume that the dereference would have authentication,
> authorization and other security mechanisms that limit the access to
> information. Unfortunately, this might not be true. The access
> network the UAC is connected to can be the source of location
> reference, and it might not have any credentialing mechanism
> suitable for controlling access to location. Consider,
> specifically, a nomadic user connected to an access network in a
> hotel. The UAC has no way to provide a credential acceptable to
> the hotel Location Server (LS) to any of its intended Location
> Recipients. The recipient of a reference does not know if a
> reference has appropriate authorization policies or not. The LS
> should provide location to any requestor.
> "
>
> * I found this paragraph in the security consideration sections. It
> more
> or less argues that the authorization model based on access control
> does
> not work in a number of cases. This is sort of interesting, if one
> additional considers the other work that is being done in GEOPRIV with
> the
> DHCP-URI document where the argument goes into the opposite direction.
>
> "
> Because target locations can be placed on a remote server, called a
> Location Server accessible with the possession of a location URI,
> this URI has its own security considerations. It is tempting to
> assume that the dereference of this URI would have authentication,
> authorization and other security mechanisms that limit the access to
> information. Unfortunately, this might not be true. The access
> network the UAC is connected to can be the source of location
> reference, and it might not have any credentialing mechanism
> suitable for controlling access to a target's location. Consider,
> specifically, a nomadic user connected to an access network in a
> hotel. The UAC has no way to provide a credential acceptable of the
> hotel Location Server (LS) to any of its intended Location
> Recipients. The recipient of a reference does not know if a
> reference has appropriate authorization policies or not.
> "
>
> I am sure the security consideration section will get some more
> feedback
> as the document moves along. If you read through it essentially
> provides
> the following story:
>
> - Conveying location is privacy sensitive and hence the transport
> has to be protected.
> ==> Use S/MIME
> - Well, you cannot really use S/MIME since it isn't deployed.
> ==> Use TLS hop-by-hop.
> - TLS isn't good either since the SIP hops see the location and
> then there is also retargeting. The end host does not know
> the intermedia SIP proxies either so he might not trust them.
> ==> Use an unlinkable pseudonym by placing garbage in the
> entity attribute of the PIDF document.
> - Well. That does not work either.
> ==> Here is the solution: We just let the UA decide what todo. And
> there SHOULD be a way to ask for user consent. Users make good
> decisions!
>
> I would present the story differently:
>
> First, there are 2 important aspects to differentiate from a security
> point
> of view, namely:
> 1) Location Based Routing
> 2) Non-Location Based Routing
>
> With location based routing the idea is that intermedaries see the
> location
> since otherwise
> they cannot route according to it. So, hop-by-hop TLS is the best you
> can
> do. If you don't
> like the consequences of it then you really need to use something like
> LoST
> prior to the
> SIP exchange to discover the entity you need to route to.
>
> With non-location based routing you will have problems with retargeting
> and
> forking.
> The good thing is that nobody says that you have to send location with
> the
> first
> message. Most folks might use TLS for signaling (hopefully) and hence
> at
> least you can deal with
> entities that are eavesdropping (unless they are SIP signaling
> elements). If
> you are worried about
> these entities listening to the location flying by, then you will have
> to
> use S/MIME. To make it
> deployable you could use SIP CERT.
>
> What is probably more important from a threat point of view is the
> ability
> to observe someone's
> movements. This would be possible in a presence based environment (when
> you
> PUBLISH your location
> to a presence / location server). The draft does provide that
> functionality,
> if I correctly
> understand it, but does not discuss it. There, we have our policy work
> that
> deals with this problem,
> namely Common Policy and Geolocation Policy.
>
> Additionally, one might want to mention the attached policies that
> travel
> with location. You could
> also point to the loc-sec architecture document for this purpose (as an
> informative reference).
> If you mention these policies in the security consideration section
> then you
> could also delete the
> "Geopriv Privacy Considerations" section.
>
> Finally, you might want to say that the PIDF-LO is only bound to the
> SIP
> message if SIP Identity is
> used and the location is in the body of the message as the signature
> computation utilized by SIP
> Identity would not cover any of the header fields.
>
> Btw, I have provided text for the security consideration section in the
> past
> already. Luckily it was
> kindly ignored. So, don't expect me to write it again.
>
>
> Ciao
> Hannes
>
> >-----Original Message-----
> >From: sipcore-bounces@ietf.org
> >[mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> >Sent: 20 July, 2009 10:59
> >To: SIPCORE
> >Subject: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance-01.txt
> >
> >Folks,
> >
> >we would like to start the WGLC of the following draft:
> >
> >http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-01
> >
> >This WGLC will end on August 7th.
> >
> >Note that there are ongoing threads discussing this draft on the list.
> >The idea is to take those comments as WGLC comments.
> >
> >Also note that we have another WGLC in parallel at this point
> >(info events, whose WGLC ends on July 29th). We have chosen to
> >have this partial overlap between the two WGLCs in order to
> >take advantage of the extra cycles people put in on reviewing
> >drafts during the pre-IETF week.
> >Given that we have canceled the second SIPCORE session in
> >Stockholm, we believe this is a reasonable amount of work for
> >folks following this WG.
> >
> >Keith will be the PROTO shepherd for this draft.
> >
> >Thanks,
> >
> >Gonzalo
> >SIPCORE co-chair
> >
> >_______________________________________________
> >sipcore mailing list
> >sipcore@ietf.org
> >https://www.ietf.org/mailman/listinfo/sipcore
> >
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
