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
