FW: IETF Geopriv Questions

From: Cuellar Jorge ^lt;Jorge.R.Cuellar@mchp.siemens.de>
Date: Thu May 16 2002 - 07:22:17 EDT

Dan,

> I am the chair of the Location Interoperability Forum's "Standards
> Influencing Group". We are interested in specifying a protocol in
> conformance to your Geopriv requirements. However, this is not a
> liaison from LIF, but some questions from me.
 
> I've made a quick review of IETF draft-cuellar-geopriv-reqs-02.txt, and
> have some questions.

> In early paragraphs you make a big point about the user setting privacy
> policies, but then distinguish the "rule maker" from the user and say
> that the rule-maker has control. I think you should review the text to
> make this more clear.

Yes, you are right, the text is not clear. We use the term "user"
up to the end of section 2 only informally, while on section 3 as the
"person behind the device", which is usually the rule-maker, but
in general different from it.

> I think you should have a requirement that individuals or components may
> decline revealing their identity, but if they do so this must be a
> designated type of identity, allowing the policy to prohibit anonymous
> location-getting or serving. This is similar to the rules of caller-id.
> You can set your phone to disallow anonymous calls. You should be able
> to "disallow location-requests unless the recipient reveals their
> identity".

I am not sure if I understand you correctly: the rule-maker in his
policy may of course write: only the following group of IDs may get
my location information (in this or that form). Do you mean there
should be a syntactically definable class of IDs that are "non-anonymous",
so that the rule-maker may specify: "only non anonymous IDs may obtain
my location information"? Well, if there is a way of syntactically defining
the group of IDs which are anonymous, this is easy, and I believe
this requirement is already a consequence of the ones stated in the
draft. But if you mean that the system should ensure either that
  - the class of anonymous IDs be syntactically definable,
or if not possible,
  - the system is able somehow to know if the ID is anonymous or no and in
  this case the rule-maker is able to use this as his criteria for his
  policies,
then I see a problem with the second option: in a "closed system",
perhaps even SIP, there may be rules to decide if something is an
anonymous ID, in the open internet there is no way of knowing this.

One way of circumventing the problem is to ask, together with the ID,
for a "class X" certificate, which would mean that this identity is
of a certain type, interpreted as: it is not anonymous.

> Requirement 14 says
> Req. 14. The combined protocol MUST be able to hide the real
> identity of the Location Recipient to the Location Server.
> Give an example where hiding the identity of the Location Recipient
> is what should be required: The target is not concerned about the
> Server identifying him and knowing his location, but identifying his
> business partners, and therefore habits, etc.>

> I do think an example is required.

Any location seeker with explicit non-anonymous ID may ask for
my location, even if Req. 14 is to hold. What the requirement
says is that the system should offer the possibility to the
rule-maker to code his rules in such a way that the IDs of
those location seekers which do in fact obtain the location
(the location recipients) remain anonymous to the location
server.

Now an example: I do not trust too much my location server; at
least for certain kinds of information, I would prefer my
Location Server not to know where I am going to go. Perhaps I
have just asked the church of scientology to send me driving
directions, but at least in Germany it could be problematic if
someone knows that I have some relationship to that
church. (Or, in many other countries with Amnesty
International or whatever). I do not want to let my location
server know about this. Even if my server is trustworthy,
better if this explicit information was never disclosed to
anybody. There are many errors or hackers around, I do not
want to pay the risk. Another example: I am an employee of
Company "A" an I use a Server of Company "A" to locate the
human resource dept of Company "B". Another reason for not
wanting the Server to know the real identity of the location
recipients is that the dossier telling who has obtained my
location information over the last 6 months gives quite a lot
of information on my habits, movements, etc. Again, even
if the location service providers agree to respect the privacy
of the user, are compelled by laws or regulations to protect
the privacy of the user, and misbehavior or negligence of the
Location Server can be ruled out, there is still a chance that
personal data may become available to unauthorized persons
attacks from hackers or other outsiders, unauthorized access
from insiders or technical or human errors.

> Would this be the case of the
> location recipient is a police officer?

No, nobody is obliged to hide his Identity. In particular,
an enforcement agent (as any other location seeker)
may always ask for my location. The system may decide to grant
him access to my location based on
   A)- policies that have been communicated to the rule-maker and
   are requirements for offering the service (emergency situations,
   law enforcement)
or
   B)-user-defined policies.

> If this is the case, should the
> requirements allow for an override of the Rule-Maker? Would this, in
> some degree, invalidate Req. 2 that policies are user-defined?

You may see the rules in A) above as an overriding of B).

> Requirement 18 has text that is hard to understand, here it is:
> Req. 18. The embedded protocol MUST be able to secure the
> Location Object for the following message flows (mutual
> end-point authentication, data object integrity, data
> object confidentiality, replay protection, in the absence
> of a time parameter): LI, Pol, LIF, LRequest, and PolInfo.

> I believe that the LIF is actually a typo, and you mean "FLI" (we are
> LIF, it is FLI).

Yes, this a typo.

> To what does the phrase "in the absence of a time parameter refer"?

Suppose that you are not using timestamps with your messages (that is:
"messages lack a time parameter"). Then eventually old messages may
be re-played by attackers as part of a larger attack. This should be
forbidden somehow. But if the messages have a time-stamp, replaying
messages would only work in small time windows, which is generally nor
a security danger.

> I would love to work with you in your co-authoring efforts. BigTribe is
> based in San Francisco, near Dierdre's office I suspect. Would it be
> possible to help out?

Sure! We will still have much to do! See you in San Diego.

But, did I answer all your questions?

Best regards,

Jorge

-----Original Message-----
From: Dan Greening [mailto:greening@bigtribe.com]
Sent: Monday, May 13, 2002 11:30 PM
To: Jorge.Cuellar@mchp.siemens.de; dmulligan@law.berkeley.edu;
jmorris@cdt.org
Subject: IETF Geopriv Questions

Jorge, Dierdre and John,
 
I am the chair of the Location Interoperability Forum's "Standards
Influencing Group". We are interested in specifying a protocol in
conformance to your Geopriv requirements. However, this is not a
liaison from LIF, but some questions from me.
 
I've made a quick review of IETF draft-cuellar-geopriv-reqs-02.txt, and
have some questions.
 
In early paragraphs you make a big point about the user setting privacy
policies, but then distinguish the "rule maker" from the user and say
that the rule-maker has control. I think you should review the text to
make this more clear.
 
I think you should have a requirement that individuals or components may
decline revealing their identity, but if they do so this must be a
designated type of identity, allowing the policy to prohibit anonymous
location-getting or serving. This is similar to the rules of caller-id.
You can set your phone to disallow anonymous calls. You should be able
to "disallow location-requests unless the recipient reveals their
identity".
 
Requirement 14 says
 
      Req. 14. The combined protocol MUST be able to hide the real

            identity of the Location Recipient to the Location Server.

 

   <Give an example where hiding the identity of the Location Recipient

   is what should be required: The target is not concerned about the

   Server identifying him and knowing his location, but identifying his

   business partners, and therefore habits, etc.>

 

I do think an example is required. Would this be the case of the
location recipient is a police officer? If this is the case, should the
requirements allow for an override of the Rule-Maker? Would this, in
some degree, invalidate Req. 2 that policies are user-defined?

 
Requirement 18 has text that is hard to understand, here it is:
 
      Req. 18. The embedded protocol MUST be able to secure the

            Location Object for the following message flows (mutual

            end-point authentication, data object integrity, data

            object confidentiality, replay protection, in the absence

            of a time parameter): LI, Pol, LIF, LRequest, and PolInfo.

 

I believe that the LIF is actually a typo, and you mean "FLI" (we are
LIF, it is FLI).
 
To what does the phrase "in the absence of a time parameter refer"?
 
I would love to work with you in your co-authoring efforts. BigTribe is
based in San Francisco, near Dierdre's office I suspect. Would it be
possible to help out?
 

Dan Greening, Ph.D. CEO, BigTribe Corporation
              330 Townsend Street, Suite 209, San Francisco, CA
94107-1662
              greening@bigtribe.com +1(415)995-7151 fax 995-7155

 
Received on Thu May 16 07:26:31 2002

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST