Re: [Geopriv] Comments regardingdraft-ietf-sip-location-conveyance-05.txt

Hi Brian,

thanks for the quick response. Please find my comments inline:

Brian Rosen wrote:
> Thanks for your detailed review comments.  My views are inline.
> 
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[email protected]]
>> Sent: Tuesday, November 21, 2006 6:06 AM
>> To: IETF SIP List; GEOPRIV
>> Subject: [Geopriv] Comments regardingdraft-ietf-sip-location-conveyance-
>> 05.txt
>>
>> Hi Brian,
>> Hi James,
>>
>> I have reviewed the document.
>>
>> First, I would like to thank you for improving the document. But, I
>> still have a few comments:
>>
>> Questions:
>>
>>
>> You write:
>> "
>>
>>     A dereference of a location-by-reference URI using SUBSCRIBE is not
>>     violating a PIDF-LO 'retransmission-allowed' element value set to
>>     'no', as the NOTIFY is the only message in this multi-message series
>>     of transactions that contains the UAC's location, with the location
>>     recipient being the only SIP element to receive location - which the
>>     purpose of this extension: to convey location to a specific
>>     destination.
>> "
>>
>> I wasn't quite sure what you are about to say with this statement. If the
>>
>> Location Recipient receives a reference and it resolves it then you are
>>
>> saying that this is OK even if the retransmission-allowed flag says "no".
>>
>> Correct?
> Yes, correct.  In fact if 3 proxies on the path sequentially resolve the
> reference when retransmission-allowed='no' that is okay.  However, none of
> those proxies may retransmit the location.

I see. I think it would be good to exactly add this example.

> 
>>
>> Technical Aspects:
>>
>> * Proxy Usage
>>
>> When a proxy adds a reference to a PIDF-LO then a number of issues remain
>>
>> unclear (as discussed throughout the Geopriv work), namely:
>>
>>    - What does the PIDF-LO contain that is created by the SIP proxy?
> First of all, you are making an assumption that the proxy creates the value
> returned by the reference it adds.  That is not likely the case.  It's more
> likely that the proxy has access to a LIS which supplies it the reference to
> include.

> 
> I think the reference resolves to the same PIDF-LO that the LIS would have
> given the endpoint.  If indeed the proxy actually is the dereference agent,
> then it would return a PIDF-LO that would look exactly like a LIS would
> provide.  I'm expecting such a PIDF-LO would have very few of the fields
> defined in PIDF.  For example, a "Contact" is unlikely to be present.  Most
> importantly, I think the proxy, like the LIS, has to include a ruleset that
> conforms to the preferences of the target.
> 
> I'm not sure that there needs to be any text in conveyance that says that.


In some sense it refers to the discussion we have in the Geopriv L7 LCP 
work. An approach of requesting a reference to a PIDF-LO from the LIS by 
the end host, then adding the reference to a SIP message compared to the 
approach of a LIS providing the reference to a proxy that then adds then 
the reference sounds somewhat similar except that the latter one is more 
complicated since the end user is not involved at all which limits the 
user's ability to influence something.

After the discussions we had in the past and the challenges we 
investigated I essentially see only one reasonable option: 
Copy-and-paste the text from Section 6 of 
http://tools.ietf.org/wg/geopriv/draft-schulzrinne-geopriv-locationref-00.txt

I think that everything else is a huge privacy problem.

>>
>> * How does the proxy know that location information has to be added?
>>
>>    - There is a privacy problem if the SIP proxy acts without explicit
>>
>> indication that location information is added.
> The use case we know about is the emergency case, where location is not
> provided by the endpoint and the proxy knows where the endpoint is.  The
> only circumstance that is likely to be true is where the SIP network and the
> access network are the same domain, or they have pre-established
> relationship, and a way of correlating identifiers such that the SIP network
> can get the correct location (or reference).
> 
> Here, perhaps we need text that explains this.  I had expected this would
> appear in ecrit-framework, but I'm not sure now that it's a good idea to
> limit proxy add of location to the emergency case.
> 
> I do think we get into pretty serious sticky wickets with what we can say
> for the non-emergency case.  I would expect we have to say that the proxy
> has explicit permission, and a ruleset by the target for the location it is
> adding, but that doesn't really express the wishes of the target of WHEN it
> is okay to add location.

I was actually referring only to the case where the proxy uses some 
information to conclude that location information has to be added.

I see only two ways to get this accomplished in a way that there is not 
a huge privacy problem:

a) Applicability statement to focus on the emergency service case only. 
There, the emergency service identifier (or in some cases the emergency 
service number) can help to determine the context. Does not work in the 
general case.

b) SIP UAC attaches a context tag to the SIP signaling message to 
indicate the context. We came up with this idea in SIP SAML since we had 
a similar problem there when it comes to determining the context. See
issue#4: http://www.tschofenig.com:8080/saml-sip/issue4
> 
>>
>> * Using Protocol
>>
>> You write:
>> "
>>     Other protocols used in the Location URI MUST be reviewed against
>>     the RFC3693 criteria for a using protocol.
>> "
>>
>> Later, in Section 3.6 you write:
>> "
>> Use of other protocols for dereferencing
>>     of a pres: URI is not defined, and such use is subject to review
>>     against RFC3693 using protocol criteria.
>> "
>>
>> I disagree that the protocol used to resolve the reference has to be a
>> using
>>
>> protocol. Hence, I suggest to delete this sentence.
> Well, perhaps this should be discussed in the LbyR design team.  Certainly,
> the location value is carried in the protocol.  I don't understand how it
> could not be viewed as a using protocol.

In our past discussions I saw two aspects:

a) SIP is per-se accepted as a using protocol.
b) HTTP is per-default not accepted as using protocol.

For (a): The proxy server/LIS is not the same as the LS/Presence Server 
in my view. Please see the recent discussion on this topic (pointing to 
terminology).

For (b): I know no fundamental problem to get HTTP to perform a 
dereferencing step from a reference to an LO.

As such, in order to be sensible to the past discussions I would 
appreciate if the strange RFC 3693 terminology is not stressed too much 
in this document based on what we already know after the long, long 
discussions we had. It is not an important and major change though.


> 
>>
>> * Privacy Rules
>>
>> You write:
>> "
>>     Entities receiving location information MUST honor the usage element
>>     rules per RFC4119.  Such entities MUST NOT alter the rule set.
>> "
>>
>> The last sentence is not correct. Let me give you an example: A SIP UAC
>>
>> obtains location information from GPS and uses a PUBLISH to upload the
>>
>> PIDF-LO to the Location Server/ Presense Server. This server has rules
>> that
>>
>> control access to location information. As part of these rules the content
>>
>> of the Location Object including the rules might be modified.
> While I can imagine a way to express a rule that modifies the ruleset, I
> don't think we have ever discussed that kind of rule.  If we allow such
> things that we need some pretty convoluted language.  If you want such a
> capability, then please propose wording that permits a rule to modify a rule
> set, but doesn't allow an arbitrary modification of the ruleset and show me
> some other place where we have used that language.  This has to be the same
> as, for example, presence.

Hmmm. Please find the already specified the rules in Section 8 of 
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-08.txt

I am not referring to a new thing.

I think everything is correct if you delete the following sentence: 
"Such entities MUST NOT alter the rule set.".

>  
>>
>> * The examples pick unfortunate references
>> (sips:server5.atlanta.example.com/alice123)
>> that give me the impression that the reference contains the user identity.
>> The document clearly needs to point out that this is not the case. The
> I think this is a good point and we should modify the example text.

OK.

> 
>> document also does not indicate
>>
>> that the reference is only kept for a certain period of time (soft-state).
>> The document does not even mention security aspects when retrieving the
>>
>> reference.
> The notion of a time limited reference is specific to the scheme.  It was
> proposed in Henning (et al)'s SIP based LCP for example, but not in all LbyR
> mechanisms.  I don't know if -conveyance is the right place to discuss that
> issue.
> 
> We don't have any mechanism that discusses how long any element should keep
> a reference, regardless of whether the dereference mechanism has an
> expiration.  Another LbyR design team topic?
> 
> I'd prefer that -conveyance not be the place that defines such things.
> 

But how long should the LIS/Proxy Server keep the reference? You cannot 
expect the reference to stay there for ever.

You can always say that

"
The reference that is added by the Proxy is keep for an unspecified 
period of time. The Location Recipient that performs the dereferencing 
step should not make any assumption about the    ability to resolve the 
reference. The reference creating entity might at any point in time 
decide to destroy the reference as part of a garbage collection process. 
It is RECOMMENDED that the reference that points to the Location Object 
is stored for at least 2 minutes.
"

I think we need to state something. I know that it is not perfect.
We do, however, also want to let people realize that a proxy doing some 
actions on behalf of the SIP UAC is not an ideal solution and suffers 
from a number of problems.

>>
>> * Security in Section 5 SIP Element Behavior
>>
>> I am confused with the text in Section 5. What MUST and what SHOULD be
>> used
>>
>> when protecting a location-by-value and a location-by-reference?
>>
>> SHOULD for TLS usage with location-by-value and location-by-reference.
> Yeah, we should clean up the language here.  I think both.

Here is my suggestion:

* Non-Emergency Based Scenarios

If the location-based routing has to be performed then TLS is MUST. 
S/MIME is not possible.

For the other case S/MIME is a SHOULD. SHOULD only because it is 
difficult to use.

* Emergency Based Scenarios

SHOULD for TLS; fall-back to non-security version if TLS does not work
S/MIME non possible.


> 
>> No statement about usage of S/MIME.
> Right.  Need some text that S/MIME SHOULD be used to protect a value or
> reference if the intention is that the only element that should get it is
> the opposite UA.

I agree that the location by reference / location by value case should 
not be treated differently with respect to this security issue.

> 
>> I wonder why self-signed certificates shouldn't be used as stated with:
>> "
>>     Self-signed certificates SHOULD NOT be used for protecting PIDF,
>>     as the sender does not have a secure identity of the recipient.
>> "
>> For encryption (and that's what we are talking about here) it heavily
>>
>> depends on the way how the self-signed certificate was obtained. I might
>>
>> share my certificate with you and hence that's an extemely useful way todo
>>
>> compared to the usage of TLS in a hop-by-hop way where a number of
>> entities
>>
>> see my location along the path.
> Perhaps you would send some text to cover this case.  I tried a couple of
> ways and didn't think my attempts made any sense.

Ok. I can try something.

> 
>> Identity info in the PIDF. In previous discussion I was wondering and
>> asking
>>
>> the Geopriv group whether there is some semantic associated with the
>>
>> identity in the PIDF. If there is, then you cannot put anything you like
>>
>> into the PIDF. If there isn't then why should we ever want to put
>> something
>>
>> meaningful in there since it greatly impacts the privacy risks.
> I don't understand this.  If it's LbyV and the endpoint puts it in, then it
> controls the identity, and it CAN put anything it wants to.

That's true. The LbyV case for the end point is easy.

> 
> In a case of LbyR, then the LIS, or whomever is constructing the PIDF needs
> a mechanism to allow the target to specify a ruleset, and probably needs to
> allow it to specify the identity as well.

But this only works if the end host is allowed to interact with the LIS 
when putting anything meaningful in there. This, however, depends on the 
outcome of the Geopriv L7 work. I would argue that this is outside the 
scope of this document (for good reasons)

For the case where the proxy adds the reference I see the need to put a 
randomized identity in there, if it does not harm. In scope.

I think it would be useful to distinguish these cases.

> 
>> I see a problem with retargeting and forking where the Location
>> Recipient is actually not know ahead of time and S/MIME usage is
>> actually not really feasible. Would some guidance be useful?
> Not sure I know what you mean.  I've long considered the problem that the
> hop by hop mechanism allows any proxy on the path to see location, but it
> also allows the opposite UA to see it.  There isn't a way to say "I trust
> the proxies, but I don't trust the endpoint".  On the other hand,
> retarget/fork may be precisely the reason S/MIME can't be used, and TLS is
> very appropriate.

Ideally, it would be great to use S/MIME to allow true protection of 
location information (Additional remark: If location-based routing by 
proxies is not used; again, if the end point determines the ultimate 
target then it does not need to consult proxies todo so.).

Now, the problem we see to in various places is that due to retargeting 
and forking even the idea of S/MIME usage is not only difficult (due to 
the lack of the deployed certs) but also due to technical issues.

This is not particularly good.

I see only one solution: Don't sent location with the initial message. 
Wait until you see to whom you are talking to. Send location later.

Is this something that could work?

> 
> I do think at least mentioning the issue here is warranted.  I don't see
> need for more mechanism.

> 
>> * Section 7.
>>
>> The document refers to 'using protocols' for both the UAC <-> UAS and to
>> the dereferencing protocol. I assume that Section 7 only addresses the
>> UAC <-> UAS communication. Since I am in favor of not treating the
>> derefencing protocol a 'using protocol' I am fine with it.
>>
>> Actually, I would prefer to move Section 7 into the appendix since this
>> is just such an artifical story that it makes me nervous. It is not your
>> fault; it is just the way how RFC 3693 was written.
> See above; I fail to see how the dereference can possibly avoid being a
> using protocol.


See my response above.

Regardless of the using protocol discussion I don't think that Section 7 
  is too valuable. For example, why is 'Single Message Transfer' 
anything useful from a privacy or security point of view?

Well, maybe I got a bit frustrated on this topic...

> 
>> * The security consideration section isn't particularly good. If I have
>> time I rewrite it.
> Suggestions are welcome.  Send text, or at least talking points.

I will try todo something.

> 
>>
>>
>> Editorial Aspects:
>>
>> The term 'Location' is written with a capital letter (see for example
>> first
>>
>> paragraph in Section 1) whereas other RFC3693 terms that are meant to be
>>
>> written with a capital letter aren't (example: 'target', 'location
>> object',
>>
>> 'using protocol', 'location recipient'). I suggest to stick with RFC3693.
> Good point.  We'll fix this.
> 
>>
>> "
>>     This document describes how Location can be "conveyed" (that is,
>>     sent on the Internet) from a SIP user agent, or in some
>>     circumstances a proxy server acting on behalf of a user agent, to
>>     another entity using the SIP [RFC3261] protocol.
>>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> "
>>
>> Either write using SIP [..] or using the Session Initiation Protocol
>> [...].
> Okay
> 
>>
>> I suggest to rewrite the following paragraph from:
>>
>> "
>>     As recited in RFC3693, location often must be kept private.  The
>>     location object (PIDF-LO) contains rules which are binding on the
>>     location recipient and controls onward distribution and retention of
>>     the location.  This document describes the security and privacy
>>     considerations that must be applied to location conveyed with SIP.
>>
>> "
>>
>> to:
>>
>> "
>>     The
>>     Location Object contains rules which provide guidance for the Location
>>
>> Recipient on the onward distribution and retention of
>>     the received location information.  This document describes the
>> security
>>
>> and privacy
>>     considerations that must be applied to location conveyed with SIP.
>> "
> I don't understand your objection to the text as written.  Are you objecting
> to the reference to 3693, the explicit mention of PIDF-LO, the word
> "binding" or something else?


The reason why I suggest the change is that we provide two ways to keep 
location private: First, we offer access control solutions using 
policies. Second, we attach rules as hints how to treat location info.

I think I rephrased it in such a way that it focuses on the second 
aspect by removing 'location often must be kept private.'. If you keep 
this sentence in there then you also need to talk about the access 
control aspect.

I also had problems with the term 'binding' since I didn't quite 
understand what it means.



> 
>>
>> I don't know what this sentence should mean in Section 1 at this part of
>> the
>>
>> section.
>> "
>> Often, location is sent from the User Agent Client to the User Agent
>>     Server, or vice versa for purposes that are beyond the scope of this
>>     document.
>> "
>>
>> There seems to be a copy-and-paste problem.
> We'll look at it
> 
>>
>> You write:
>>
>> "
>>     The Geolocation header is introduced to signify that location is
>>     included in a SIP message to provide either a content identifier
>>     (cid:) pointer to the body part containing the UAs PIDF-LO, or a
>>     location-by-reference URI that may subsequently be "dereferenced" by
>>     a using protocol (which may be SIP or another protocol).
>> "
>>
>> Please delete the following part " by
>>     a using protocol (which may be SIP or another protocol)" since we
>> haven't
>>
>> concluded in our discussion that the dereferencing protocol is indeed a
>>
>> using protocol.
> See above
> 
>> Actually, I think that the entire paragraph is not particularly useful in
>>
>> the introduction and the subsequent paragraph fits much better to the
>>
>> previous one.
>>
>>
>> You write:
>> "
>> The Geolocation header MUST contain one two types of URIs:
>>                                      ^^^^^^^^^^^^
>>                                      one of two types
>> "
> OK
> 
>>
>> The example contains a company name
>>
>> (<gp:provided-by>www.cisco.com</gp:provided-by>) although it should,
>>
>> according to the guidelines something like "www.example.com".
> OK
> 
>>
>> Section 4.3 uses the term 'LIS' and does not mention what it is.
>> Just avoid it.
> Hmmm.  We really do have to agree on terminology, no question.  The notion
> that LIS is not acceptable is very disconcerting.  Outside of IETF, LIS is a
> well understood term.  Location Generator is not. 


Hmm. What should we do?

> 
>>
>> IDNITS:
>>
>>    Experimental warnings:
>>    - Missing Reference: 'RFC3851' is mentioned on line 343, but not
>> defined
>>      'resulting resolution, per [RFC3851], resolves to a sip: or sips:...'
>>
>>    - Unused Reference: 'ID-Loc-Reg' is defined on line 891, but not
>>
>> referenced
>>      '[ID-Loc-Reg]...'
> Will fix
> 
>>
>>    Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>>    - It seems as if not all pages are separated by form feeds - found 0
>> form
>>      feeds but 26 pages
> Hmmm, tool problem.  James uses the Word template.

Don't use the word template. Use XML to RFC.


> 
>>
>> tmp/draft-ietf-sip-location-conveyance-05.txt(294): Line has weird
>> spacing:
>>
>> '...     Rr    ar ...'
>> tmp/draft-ietf-sip-location-conveyance-05.txt(298): Line has weird
>> spacing:
>>
>> '...     Rr    ar ...'
> OK
> 

Ciao
Hannes

_______________________________________________
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