Subject: Re: [Geopriv] [sipcore] WGLC: draft-ietf-sipcore-location-conveyance-01.txt

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 29 Jul 2009 21:23:33 +0300

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: [email-masked] 
>[mailto:[email-masked]] 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 30 Jul 2009 03:28:25 -0500

I was going to write a longer comment, but Hannes has already said all that I would have anyway.  All of it.

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hannes Tschofenig
> Sent: Wednesday, 29 July 2009 8:24 PM
> To: 'Gonzalo Camarillo'; 'SIPCORE'
> Cc: [email-masked]
> Subject: Re: [Geopriv] [sipcore] WGLC:draft-ietf-sipcore-location-
> conveyance-01.txt
> 
> Hi Gonzalo,
> Hi James, Hi Brian,
> 
> Geopriv mailing list
> [email-masked]
> 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]