Subject: [Sip] Comments regarding draft-ietf-sip-location-conveyance-05.txt

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 21 Nov 2006 12:05:58 +0100

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?

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?

* 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.

* 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.

* 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.

* 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 
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.

* 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.
No statement about usage of S/MIME.

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.

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 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?

* 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.

* The security consideration section isn't particularly good. If I have 
time I rewrite it.

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.

"
    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 [...].

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 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.

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.

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
"

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".

Section 4.3 uses the term 'LIS' and does not mention what it is.
Just avoid it.

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]...'

   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

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 ...'

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 21 Nov 2006 08:35:07 -0500

Thanks for your detailed review comments.  My views are inline.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> 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,
> 
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.

>    - 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.
> 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.

> 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.

> 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.
 
> 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.

> The document does not even mention security aspects when retrieving the
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.

> SHOULD for TLS usage with location-by-value and location-by-reference.
Yeah, we should clean up the language here.  I think both.

> 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.

> 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.

> 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.

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.

> 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.

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

> 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.

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

> 'using protocol', 'location recipient'). I suggest to stick with RFC3693.
Good point.  We'll fix this.

>     another entity using the SIP [RFC3261] protocol.
Okay

>     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?

> There seems to be a copy-and-paste problem.
We'll look at it

> concluded in our discussion that the dereferencing protocol is indeed a
See above

> The Geolocation header MUST contain one two types of URIs:
OK

> according to the guidelines something like "www.example.com".
OK

> Section 4.3 uses the term 'LIS' and does not mention what it is.
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. 

>    - Unused Reference: 'ID-Loc-Reg' is defined on line 891, but not
Will fix

>    - It seems as if not all pages are separated by form feeds - found 0
Hmmm, tool problem.  James uses the Word template.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 21 Nov 2006 22:05:17 +0100

Hi Brian,

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

> those proxies may retransmit the location.

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

> 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.

> adding, but that doesn't really express the wishes of the target of WHEN it

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.priv.at:8080/saml-sip/issue4
> 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.

> 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.".

> I think this is a good point and we should modify the example text.

OK.

> 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.

> 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.

> reference if the intention is that the only element that should get it is

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

> ways and didn't think my attempts made any sense.

Ok. I can try something.

> controls the identity, and it CAN put anything it wants to.

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

> 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.

> retarget/fork may be precisely the reason S/MIME can't be used, and TLS is

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?

> See above; I fail to see how the dereference can possibly avoid being a

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...

> Suggestions are welcome.  Send text, or at least talking points.

I will try todo something.

> "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.

> well understood term.  Location Generator is not. 

Hmm. What should we do?

> Hmmm, tool problem.  James uses the Word template.

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

Ciao
Hannes