Subject: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-01

From: "James M. Polk" <[email-masked]>
Date: Fri, 15 Feb 2008 18:24:12 -0600

Section 5.1 has this requirement

"
C4. Random Generated:  The location URI MUST be hard to guess, i.e., 
it MUST contain a cryptographically random component.

Motivation: There is some benefit to the client if the location URI 
is generated in an obscured manner so that its sequence, for example 
in the case of a client's location update, can't be easy guessed.
"

Why does this need to be cryptographically random?

As long as my badge number is "3199", why can't my LbyR URI be

         sips:cisco3199.cisco.com

The domain part is already revealed in the URI, and who know who is 
assigned to cisco3199?  My identity can't be derived from it, and 
maybe my domain assigns the next available number to the next 
requester of location.  Perhaps after a certain amount of time 
without an assignment, I go back to being unassigned, and get the 
next available number from the cisco.com domain.

Also, if it has to be cryptographically random, where's the guidance 
on what that means, what that is, and how I know I've met the 
requirement?  This at least is a glaring hole in the ID, and likely a 
huge burden on the providers of location.

Further, what constitues a "sequence" -- which is referred to in the 
Motivation for the requirement? Is that numeric only, or can it be 
alpha too? Is it UTF-8 only, or can it be UTF-16?  Does it have to be 
as random as "unique through space and time" as the Call-ID header in 
SIP needs to be?  Where's the guidance in this hint (that acts like a 
requirement itself)?

I think at the very least, this should be a SHOULD, and not a MUST, 
"...hard to guess..." requirement.

James 

_______________________________________________
Geopriv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/geopriv

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 17 Feb 2008 12:45:43 +0100

Hi James, 

This is also a good question. 
See my thoughts inline:  

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von ext James M. Polk
> Gesendet: Samstag, 16. Februar 2008 02:24
> An: [email-masked]
> Betreff: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-01
> 

First, the reference must not contain the user identity. 
Second, one should make sure that the reference cannot easily be guessed or that one searches through the space easily in order to retrieve the location of all the Targets in a network. This is mainly motivated by the fact that possession of the reference is essentially equal to possessing the location itself. Hence, there is no additional authorization check. 

As such, it is important from a security and privacy point of view that part of the URI is randomly created. I would say with at least 128 bit of randomness. 

> As long as my badge number is "3199", why can't my LbyR URI be

Easy to search through the space and learn the location of the Targets. 

> assigned to cisco3199?

You might not know the real identity of the Target; maybe - unless someone puts an appropriate value into the PIDF-LO. 

>  My identity can't be derived from it, and 

I doubt that a network operator wants to let other people know where end hosts are. 

> huge burden on the providers of location.

Providing random numbers is not a huge problem. This is a common aspect in all security protocols. I would follow the guidelines in: 
http://www.ietf.org/rfc/rfc4086.txt

> SIP needs to be?  Where's the guidance in this hint (that acts like a 

I wouldn't use the term sequence in the description. It is indeed misleading. 
Random (with at least 128bit of entrophy) and difficult to guess would be fine for me. 

> "...hard to guess..." requirement.
I believe that this is a really important requirement that implementers are likely to get wrong and it will subsequently lead to a lower level of security and privacy. Hence, a MUST is justified. 

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 17 Feb 2008 19:22:27 -0600

>This is also a good question.

comments in-line

>First, the reference must not contain the user identity.

this doesn't make it have to be 
"cryptographically random", just NOT contain user identity.

>Second, one should make sure that the reference 
>cannot easily be guessed or that one searches 
>through the space easily in order to retrieve 
>the location of all the Targets in a network.

This constraint isn't placed on email addresses. 
Why is it here?  The URI itself doesn't reveal 
location of the Target. Remember, the LIS will also challenge each request.

>This is mainly motivated by the fact that 
>possession of the reference is essentially equal 
>to possessing the location itself.

Goodness this is wrong.

For example:

If I get a Location URI of
         sips:cisco3199.cisco.com
the first time I ask for a URI, this doesn't reveal anything about my location.

If I time out that URI by not keeping it 
currently fresh, and I get I get this Location 
URI the next time I ask for a ask
         sips:cisco10993.cisco.com

What have you learned about my location?

answer: nothing...

This scenario easily accomplishes what you are 
wanting, and it's not "cryptographically random".

>  Hence, there is no additional authorization check.

Authorization check of what, of the URI? That is 
done when a request is sent to the LIS, 
regardless of whether I have the same URI or 
different URI *AND* regardless of whether this 
URI is "cryptographically random".

True or not?

>As such, it is important from a security and 
>privacy point of view that part of the URI is randomly created.

Again, why? When the LIS is the only entity that 
can actually produce a PIDF-LO from this URI, why 
isn't the burden on the LIS to make sure its 
challenges are robust. This also burdens the 
[RFCF3693] rulemaker to have a good policy for each target.

>I would say with at least 128 bit of randomness.
>
> >

how?

>You might not know the real identity of the 
>Target; maybe - unless someone puts an appropriate value into the PIDF-LO.

correct!

>other people know where end hosts are.

exactly!

>Providing random numbers is not a huge problem. 
>This is a common aspect in all security 
>protocols. I would follow the guidelines in:

In this context, it doesn't get us anywhere, ever

>I wouldn't use the term sequence in the description.

so that needs to be changed

>It is indeed misleading.

I still want to know why it has to be a random 
number. I'll give you that it has to be randomly 
selected for each client, and perhaps randomly 
assigned each time a new non-active location URI 
is asked for, but it then doesn't have to be a 
random number -- not when there is a server that 
challenges all requests for the PIDF-LO of the Target.

>I believe that this is a really important 
>requirement that implementers are likely to get 
>wrong and it will subsequently lead to a lower 
>level of security and privacy. Hence, a MUST is justified.

I agree with the first part of the sentence, but 
not the conclusion.  I think implementors can be 
it wrong with this little guidance. However, with 
more guidance, they won't, and URI length and randomness will not be necessary.

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 17 Feb 2008 19:40:05 -0600

I don't have an opinion on whether "MUST" and "cryptographically random" are both imperatives.

The intent should certainly be that the reference doesn't convey any identifying information in its construction.

Wrt "> > As long as my badge number is "3199", why can't my LbyR URI be
     > >          sips:cisco3199.cisco.com"
>

I'm not sure why you would want your employee badge number in the reference (it seems unlikely the LIS would know this anyway) but I would suggest that such an arrangement *should* be such that it was a breach of the reference requirements. It's up to the implementer whether they want to comply with the requirements anyway.

If you wanted your location plotted on a free Internet mapping service, and happened to be sending your location by reference, I don't think you'd want that application to be able to infer both your employer's identity and your employee ID. If you have an application where you'd like them to know this information, then you'd send that information in the application protocol along with a properly anonymous reference.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James M. Polk
Sent: Monday, 18 February 2008 12:22 PM
To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
Subject: Re: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-01

comments in-line

Goodness this is wrong.

For example:

answer: nothing...

True or not?

how?

correct!

exactly!

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

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 17 Feb 2008 20:21:02 -0600

At 07:40 PM 2/17/2008, Dawson, Martin wrote:
>I don't have an opinion on whether "MUST" and 
>"cryptographically random" are both imperatives.
>
>The intent should certainly be that the 
>reference doesn't convey any identifying information in its construction.

I agree completely

>I'm not sure why you would want your employee badge number in the reference

actually, this purposely isn't my employee badge 
number (otherwise I'd be a LOT richer). this is 
just a number that doesn't equate to me as a user or person.

>  (it seems unlikely the LIS would know this 
> anyway) but I would suggest that such an 
> arrangement *should* be such that it was a 
> breach of the reference requirements.

I think what we give guidance towards is "no user 
identifying information" which includes phone 
extensions, badge numbers, first or last names, etc...

>It's up to the implementer whether they want to 
>comply with the requirements anyway.

sure

>If you wanted your location plotted on a free 
>Internet mapping service, and happened to be 
>sending your location by reference, I don't 
>think you'd want that application to be able to 
>infer both your employer's identity and your employee ID.

See above about the employee ID number (which it 
isn't (purposely) in my example), and guidance we can give about not doing that

sure, but I can't believe enterprises who own one 
or more LIS will not have their company part in 
the URI, being an internal server.

>If you have an application where you'd like them 
>to know this information, then you'd send that 
>information in the application protocol along 
>with a properly anonymous reference.

sure

(see... you can I can agree ;-)

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of James M. Polk

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 11:07:30 +0200

Hi James,

I think we need to distinguish two models:

* Authorization Model

In this model there are authorization policies uploaded by the Target to 
the LIS to restrict access to location information.
These authorization policies tell the LIS which entities are allowed to 
retrieve location information.

In this model the reference does not need to be random.

* Possession Model

In this model there are no authorization policies uploaded by the Target 
to the LIS to restrict access to location information.
For this model the reference MUST contain a random component.

I am interested in the "possession model" since I believe it is more 
likely to see some deployment. If you want to work also on the 
authorization model then you need to describe how authorization policies 
from the Target get to the LIS.

If you allow these two options then you need to allow the Target to 
state which model it wants to follow in order to prevent privacy problems.

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 19 Feb 2008 03:09:07 -0600

Hannes,

I believe that the authorization model mandates the use of authentication techniques also.

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Tuesday, 19 February 2008 8:08 PM
> To: James M. Polk
> Cc: [email-masked]; Tschofenig,Hannes (NSN - FI/Espoo)
> Subject: [Geopriv] Authorization Models: Q2 aboutdraft-ietf-geopriv-lbyr-
> requirements-01
> 
> Hi James,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 11:10:48 +0200

James example is quite good to illustrate the impact of the two 
authorization models I described in a previous mail.

* "Possession Model" with this example:

If I get to know your badge number then I can use the LIS to query for 
your location -- whenever I like.
You might not like it but you cannot prevent it in this model.

* "Authorization Model" with this example:

In this model you, James, would upload authorization policies to 
indicate whether I am allowed to see your location.
I would know from your badge number (which I can probably get from the 
corporate directory) and then I would retrieve your location.

Ciao
Hannes

---

From: Richard Barnes <[email-masked]>
Date: Tue, 19 Feb 2008 10:34:47 -0500

To say this another way, an LS MUST do one of the following when it 
generates a reference

Case 1: Access limited by policy. LS applies authentication and access 
control at dereference.  In this case, the URI can be of any form chosen 
by the LS.

Case 2: Access limited by distribution.  LS does not apply 
authentication and access control at dereference.  In this case, the URI 
MUST be difficult to guess (so that possession can be used to imply 
authorization).

--RB

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 19 Feb 2008 16:36:22 +0100

Sounds good 

> Von: ext Richard Barnes [mailto:[email-masked]] 
> Gesendet: Dienstag, 19. Februar 2008 17:35
> An: [email-masked]
> Cc: James M. Polk; [email-masked]; Tschofenig, Hannes (NSN 
> - FI/Espoo)
> Betreff: Re: [Geopriv] Authorization Models: Q2 about 
> draft-ietf-geopriv-lbyr-requirements-01
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 19 Feb 2008 16:44:29 -0600

Hi Hannes,

One comment with respect to the Possession Model below.

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Tuesday, 19 February 2008 8:11 PM
To: Dawson, Martin
Cc: James M. Polk; Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
Subject: Privacy Violation: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-01

If I get to know your badge number then I can use the LIS to query for 
your location -- whenever I like.
You might not like it but you cannot prevent it in this model.
[[MCD]] I'm not sure about this specific example; it sounds like OBO. It sounds like the URI might exist even if the target device didn't request it to be created. If that's not the intent then that's fine but, otherwise, I'd say this is not consistent with the intention of location-by-reference - and it's actually referring to an acquisition protocol that happens to incorporate the query key in the URI..

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 20 Feb 2008 09:13:23 +0200

Hi Martin,

> [[MCD]] I'm not sure about this specific example; it sounds like OBO. It sounds like the URI might exist even if the target device didn't request it to be created. If that's not the intent then tha…
I wanted to refer to James's model and there was no further information 
where this reference comes from. I ignored this aspect for the 
illustration.
But you are right that one would have to further differentiate these two 
aspects in a complete description.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 20 Feb 2008 09:14:31 +0200

Correct.

Richard Barnes wrote:
> control at dereference.  In this case, the URI can be of any form 
> chosen by the LS.
>
> authentication and access control at dereference.  In this case, the 
> URI MUST be difficult to guess (so that possession can be used to 
> imply authorization).
>
> --RB
>
> Hannes Tschofenig wrote:
>> Hi James,
>>
>> In this model there are authorization policies uploaded by the Target 
>> These authorization policies tell the LIS which entities are allowed 
>> to retrieve location information.
>>
>> In this model there are no authorization policies uploaded by the 
>> Target to the LIS to restrict access to location information.
>> authorization model then you need to describe how authorization 
>> policies from the Target get to the LIS.
>>
>>> this doesn't make it have to be "cryptographically random", just NOT 
>>> contain user identity.
>>>
>>>   
>>
>>>> Second, one should make sure that the reference cannot easily be 
>>>> guessed or that one searches through the space easily in order to 
>>>> retrieve the location of all the Targets in a network.
>>>>     
>>> This constraint isn't placed on email addresses. Why is it here?  
>>> The URI itself doesn't reveal location of the Target. Remember, the 
>>> LIS will also challenge each request.
>>>
>>>  
>>>> This is mainly motivated by the fact that possession of the 
>>>> reference is essentially equal to possessing the location itself.
>>>>     
>>> Goodness this is wrong.
>>>
>>> For example:
>>>
>>> If I time out that URI by not keeping it currently fresh, and I get 
>>> I get this Location URI the next time I ask for a ask
>>> This scenario easily accomplishes what you are wanting, and it's not 
>>> "cryptographically random".
>>>
>>>  
>>> Authorization check of what, of the URI? That is done when a request 
>>> is sent to the LIS, regardless of whether I have the same URI or 
>>> different URI *AND* regardless of whether this URI is 
>>> "cryptographically random".
>>>
>>> True or not?
>>>
>>>
>>>  
>>>> As such, it is important from a security and privacy point of view 
>>>> that part of the URI is randomly created.
>>>>     
>>> Again, why? When the LIS is the only entity that can actually 
>>> produce a PIDF-LO from this URI, why isn't the burden on the LIS to 
>>> make sure its challenges are robust. This also burdens the 
>>>> You might not know the real identity of the Target; maybe - unless 
>>>> someone puts an appropriate value into the PIDF-LO.
>>>>     
>>> correct!
>>>
>>>  
>>>> Providing random numbers is not a huge problem. This is a common 
>>>> aspect in all security protocols. I would follow the guidelines in:
>>> I still want to know why it has to be a random number. I'll give you 
>>> that it has to be randomly selected for each client, and perhaps 
>>> randomly assigned each time a new non-active location URI is asked 
>>> for, but it then doesn't have to be a random number -- not when 
>>> there is a server that challenges all requests for the PIDF-LO of 
>>> the Target.
>>>
>>>
>>>  
>>>> I believe that this is a really important requirement that 
>>>> implementers are likely to get wrong and it will subsequently lead 
>>>> to a lower level of security and privacy. Hence, a MUST is justified.
>>>>     
>>> I agree with the first part of the sentence, but not the 
>>> conclusion.  I think implementors can be it wrong with this little 
>>> guidance. However, with more guidance, they won't, and URI length 
>>> and randomness will not be necessary.
>>>
>>>
>>>  
>>>> Ciao
>>>> Hannes
>>>>
>>>>    
>>>>> James
>>>>>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 20 Feb 2008 02:11:29 -0600

At 01:14 AM 2/20/2008, Hannes Tschofenig wrote:
>Correct.
>
>Richard Barnes wrote:
>>To say this another way, an LS MUST do one of 
>>the following when it generates a reference
>>
>>Case 1: Access limited by policy. LS applies 
>>authentication and access control at 
>>dereference.  In this case, the URI can be of any form chosen by the LS.
>>
>>Case 2: Access limited by distribution.  LS 
>>does not apply authentication and access 
>>control at dereference.  In this case, the URI 
>>MUST be difficult to guess (so that possession 
>>can be used to imply authorization).

but aren't we (geopriv, and this group of folks) 
all about "once a piece of information is 
transmitted, it really can't be controlled"? If 
this is the case, the above (case #2) cannot be a 
destination, without assuming zero security 
properties.  Case in point, a UA will sent this 
out whenever it calls 911/112 (or sos), without 
any security properties.  That same UA will send 
this URI out to Pizza Hut to route both the call 
and the delivery guy to the most appropriate 
store for the UA's present location.

All this says is that possession of the URI 
shouldn't mean authorization, because anyone 
snooping in from of Pizza Hut's SIP server will 
have every authorized URI of everyone that wants 
Pizza on any given night, and this *could* be on 
a regional or national or international scale.

At least I think case #2 needs to be thought out some more...

James

>>>In this model there are authorization policies 
>>>uploaded by the Target to the LIS to restrict access to location information.
>>>These authorization policies tell the LIS 
>>>which entities are allowed to retrieve location information.
>>>
>>>In this model there are no authorization 
>>>policies uploaded by the Target to the LIS to 
>>>restrict access to location information.
>>>I am interested in the "possession model" 
>>>since I believe it is more likely to see some 
>>>deployment. If you want to work also on the 
>>>authorization model then you need to describe 
>>>how authorization policies from the Target get to the LIS.
>>>
>>>If you allow these two options then you need 
>>>to allow the Target to state which model it 
>>>wants to follow in order to prevent privacy problems.
>>>
>>>Ciao
>>>Hannes
>>>
>>>
>>>
>>>James M. Polk wrote:
>>>>>Second, one should make sure that the 
>>>>>reference cannot easily be guessed or that 
>>>>>one searches through the space easily in 
>>>>>order to retrieve the location of all the Targets in a network.
>>>>>
>>>>The URI itself doesn't reveal location of the 
>>>>Target. Remember, the LIS will also challenge each request.
>>>>
>>>>
>>>>>possession of the reference is essentially 
>>>>>equal to possessing the location itself.
>>>>>
>>>>Goodness this is wrong.
>>>>
>>>>For example:
>>>>
>>>>currently fresh, and I get I get this 
>>>>Location URI the next time I ask for a ask
>>>>This scenario easily accomplishes what you 
>>>>are wanting, and it's not "cryptographically random".
>>>>
>>>>
>>>>Authorization check of what, of the URI? That 
>>>>is done when a request is sent to the LIS, 
>>>>different URI *AND* regardless of whether 
>>>>this URI is "cryptographically random".
>>>>
>>>>True or not?
>>>>
>>>>
>>>>
>>>>Again, why? When the LIS is the only entity 
>>>>that can actually produce a PIDF-LO from this 
>>>>URI, why isn't the burden on the LIS to make 
>>>>sure its challenges are robust. This also 
>>>>burdens the [RFCF3693] rulemaker to have a good policy for each target.
>>>>
>>>>
>>>>>Providing random numbers is not a huge 
>>>>>problem. This is a common aspect in all 
>>>>>security protocols. I would follow the guidelines in:
>>>>>Random (with at least 128bit of entrophy) 
>>>>>and difficult to guess would be fine for me.
>>>>>
>>>>I still want to know why it has to be a 
>>>>random number. I'll give you that it has to 
>>>>be randomly selected for each client, and 
>>>>perhaps randomly assigned each time a new 
>>>>non-active location URI is asked for, but it 
>>>>then doesn't have to be a random number -- 
>>>>not when there is a server that challenges 
>>>>all requests for the PIDF-LO of the Target.
>>>>
>>>>
>>>>
>>>>>requirement that implementers are likely to 
>>>>>get wrong and it will subsequently lead to a 
>>>>>lower level of security and privacy. Hence, a MUST is justified.
>>>>>
>>>>I agree with the first part of the sentence, 
>>>>but not the conclusion.  I think implementors 
>>>>can be it wrong with this little guidance. 
>>>>However, with more guidance, they won't, and 
>>>>URI length and randomness will not be necessary.
>>>>
>>>>
>>>>
>>>>>Ciao
>>>>>Hannes
>>>>>
>>>>>
>>>>>>James
>>>>>>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 20 Feb 2008 09:33:17 +0100

Hi James, 

> properties.

That's not true. It depends what is behind the URL and the intention of the 
Target. For the former case there we had a discussion at the last IETF meeting 
To approach this topic a bit more structured.

>  Case in point, a UA will sent this 
> any security properties.
Good that you mention the 911 case: I seriously doubt that the Target will upload authorization policies to the LIS and require the PSAP to authenticate to the LIS in order to get access to the location information.

>  That same UA will send 

There is no need for the UA to sent the same URI to different entities if the expected "security level" is different. 
The UA could also put the URI to it's presence server and make use of it's policies there to control access. 

> a regional or national or international scale.

I disagree; When we remove the ability for HELD to deal with the GEOPRIV authorization policies from HELD at the time when it became a working group we argued that this is not necessary in many cases.  

> At least I think case #2 needs to be thought out some more...
Well. We are talking about this case for 2+ years already. 
I actually thought that this is already cast in stone. 

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 20 Feb 2008 02:49:56 -0600

Hannes

At 02:33 AM 2/20/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>Good that you mention the 911 case: I seriously 
>doubt that the Target will upload authorization 
>policies to the LIS and require the PSAP to 
>authenticate to the LIS in order to get access to the location information.

ok, I'll go with that, but the UA will still have 
one URI that used for any service (from the same 
LIS, or the same domain the LIS is in), right?

>There is no need for the UA to sent the same URI 
>to different entities if the expected "security level" is different.

now you're talking about UAs have multiple URIs 
that point to the same record, or multiple URIs 
that each point to different records (even though 
the location is the same in each record)...

>The UA could also put the URI to it's presence 
>server and make use of it's policies there to control access.

this is what I expect, but this doesn't fall 
under the umbrella of "possession of a URI implied authorization"...

To me, possession of a URI means location can be 
sought, at the LIS, by a dereference, which can 
be accepted or denied.  Plus, based on who 
requested the location of a particular user, that 
user could have policies establishing what pieces 
or precision of location are given in the 
response.  Is that not how you are thinking?

>I disagree; When we remove the ability for HELD 
>to deal with the GEOPRIV authorization policies 
>from HELD at the time when it became a working 
>group we argued that this is not necessary in many cases.

well, prague was an interesting meeting, wasn't it?

;-)

>Well. We are talking about this case for 2+ years already.

I guess I'm not clear on this then, because we're 
not talking about always applying security 
properties to every URI, which means the URI 
shouldn't control authorization. I think the LIS 
should, based on the challenge it engages in with the location seeker.

I might be alone in that believe...

>I actually thought that this is already cast in stone.

I thought "accuracy" and "circles" and 
"uncertainty" were removed from this WG based on 
WG consensus (i.e., that this was equally cast in 
stone)... so things change when you don't expect it to sometimes, eh?

hehe

 >:^ )

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 20 Feb 2008 11:01:00 +0200

Hi James,

James M. Polk wrote:
>> Good that you mention the 911 case: I seriously doubt that the Target 
>> will upload authorization policies to the LIS and require the PSAP to 
> ok, I'll go with that, but the UA will still have one URI that used 
> for any service (from the same LIS, or the same domain the LIS is in), 
> right?
>
None of our documents mandates anything like that.
It is up to the UA to decide what it wants.

>> There is no need for the UA to sent the same URI to different 
>> entities if the expected "security level" is different.
>
> now you're talking about UAs have multiple URIs that point to the same 
> record, or multiple URIs that each point to different records (even 
> though the location is the same in each record)...

The HELD document allows the UA to request multiple URIs.
To make sense, these URIs would point to different things. For example, 
one URI might point to location information that contains only location 
information at the time when the reference was created.

The different forms of URIs are discussed in Henning's IETF#70 presentation
http://www.cs.columbia.edu/~hgs/papers/2007/IETF70-geopriv-ref.ppt
and the corresponding text can be found in:
http://www.ietf.org/internet-drafts/draft-garcia-simple-indirect-presence-publish-00.txt
(To put the text into this draft is not ideal; we might move it into 
Richard's security document.)

> this is what I expect, but this doesn't fall under the umbrella of 
> "possession of a URI implied authorization"...
 From the point of view of the LCP it does.

>
> To me, possession of a URI means location can be sought, at the LIS, 
> by a dereference, which can be accepted or denied.  Plus, based on who 
> requested the location of a particular user, that user could have 
> policies establishing what pieces or precision of location are given 
> in the response.  Is that not how you are thinking?

This is not what I call "possession model". Your description would 
correspond to the authorization model.

I think that Richard's security document should describe these different 
cases with examples in more detail.

>> I disagree; When we remove the ability for HELD to deal with the 
>> GEOPRIV authorization policies from HELD at the time when it became a 
>> working group we argued that this is not necessary in many cases.
>

Unfortunately, I wasn't there since I had to chair the DIME meeting at 
the same time :-(

> I guess I'm not clear on this then, because we're not talking about 
> always applying security properties to every URI, which means the URI 
> shouldn't control authorization. I think the LIS should, based on the 
> challenge it engages in with the location seeker.
>
I think we need a better description. It might well be that we are 
actually agreeing to the approach but have a different architectural 
picture in mind.

> I thought "accuracy" and "circles" and "uncertainty" were removed from 
> this WG based on WG consensus (i.e., that this was equally cast in 
... well. I should have thought that you are going to use the same 
argument against me :-)

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 20 Feb 2008 12:54:50 -0600

Hey Hannes

At 03:01 AM 2/20/2008, Hannes Tschofenig wrote:
>>>Good that you mention the 911 case: I 
>>>seriously doubt that the Target will upload 
>>>authorization policies to the LIS and require 
>>>the PSAP to authenticate to the LIS in order 
>>>to get access to the location information.
>>
>>ok, I'll go with that, but the UA will still 
>>have one URI that used for any service (from 
>>the same LIS, or the same domain the LIS is in), right?

I don't believe the UA gets to decide it only has 
one, or it can have more than one URI in this 
case. It is totally dependent on what the LIS 
will provide.  In other words, if the LIS only 
gives out one URI, the UA is stuck with one 
URI.  I don't think regular users (your mom, 
neighbor or non-engineering office worker) will 
know what a URI is to know to be satisfied with 
one or ask for more than one URI.

this is a practicality issue, as much as anything.

Users barely can keep up with their multiple 
phone numbers (home, office, cell), let alone a 
new format of an identifier (such as a URI, 
that's cryptographically unique -- let's not forget that requirement  ;-)

>>>There is no need for the UA to sent the same 
>>>URI to different entities if the expected "security level" is different.
>>
>>that each point to different records (even 

See my practicality comment above. Users won't be 
able to keep up with these cryptographically 
unique sequences enough to want one, much less 
two of them. This is all behind the scenes stuff 
to users. It has to be for it to work at all.

>To make sense, these URIs would point to different things.

So, to tease this out a bit, you (or "the HELD 
advocates") are suggesting there are multiple 
URIs, each pointing at different location objects 
(PIDF-LOs), per locatable device or application in the world.

Who's going to manage that?

How is a user and the UI to remember that

         [email-masked] is for precise location
and
         [email-masked] 
is for coarse location
?

How is a user to track this to know which to give out?

>For example, one URI might point to location 
>information that contains only location 

so this URI might look like this:

         [email-masked]

which is different from the two above? And who is 
going to keep track of this? If it is the list, a 
pseudonym can be used for each, not a URI (facing towards the user), right?

>http://www.cs.columbia.edu/~hgs/papers/2007/IETF70-geopriv-ref.ppt

this aren't cryptographically unique, hence these 
longer values above... it makes a difference when 
reviewing what could be what you're talking about

>(To put the text into this draft is not ideal; 
>we might move it into Richard's security document.)
>
>>

I'm not sure yet I understand what your answer 
means.  An LCP hands out URIs, so do conveyance 
and tracking protocols.  The URI is the same for 
each for the same endpoint.  So how does 
possession of the URI to an LCP that has already 
handed out the URI mean authorization to possess 
the URI?  Can you explain this a bit more?

>>To me, possession of a URI means location can 
>>be sought, at the LIS, by a dereference, which 
>>can be accepted or denied.  Plus, based on who 
>>requested the location of a particular user, 
>>that user could have policies establishing what 
>>pieces or precision of location are given in 
>>the response.  Is that not how you are thinking?
>
>This is not what I call "possession model". Your 
>description would correspond to the authorization model.

...and I'm confused because what I call a 
"possession model", you're describing as an 
authorization model -- and I don't believe the two have the same definition.

>I think that Richard's security document should 
>describe these different cases with examples in more detail.
>
>>
>>
>>> >
>>>I disagree; When we remove the ability for 
>>>HELD to deal with the GEOPRIV authorization 
>>>policies from HELD at the time when it became 
>>>a working group we argued that this is not necessary in many cases.
>>
>Unfortunately, I wasn't there since I had to 
>chair the DIME meeting at the same time :-(

you missed all the fun... yeah, I remember 
thinking your wouldn't have liked a lot of what 
was said there (and commented at the mic)

;-)

>>I guess I'm not clear on this then, because 
>>we're not talking about always applying 
>>security properties to every URI, which means 
>>the URI shouldn't control authorization. I 
>>think the LIS should, based on the challenge it 
>>engages in with the location seeker.
>>
>I think we need a better description. It might 
>well be that we are actually agreeing to the 
>approach but have a different architectural picture in mind.

fair... I'm just not seeing it yet.

>>"uncertainty" were removed from this WG based 
>>on WG consensus (i.e., that this was equally 
>>cast in stone)... so things change when you don't expect it to sometimes, eh?
>... well. I should have thought that you are 
>going to use the same argument against me :-)

what goes around comes around.....  :-O

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 20 Feb 2008 15:53:56 -0600

It's been an interesting discussion.

> Who's going to manage that?

I have a device, it has a HELD client.  The HELD client doesn't do
anything special except for discovery and a few bits where it
understands the HELD protocol.  Applications on my device use this
client to request location information in the form that best suits them.
Two of those applications are implemented in a SIP UA that does
emergency calling and presence.

The emergency calling app is dumb in that it just gets whatever the LIS
decides it needs, which is good enough for emergency calls (it knows
enough to distinguish between a URI and a PIDF-LO so that it knows where
to put them, but that's all).  

The presence application can request a different URI (read the context
management draft) with different properties.  Currently, there is no way
to specify how an authorization policy applies to a URI (it IS planned),
but you can specify number of uses and expiry times and so forth.

Each application has only one URI (or as many as they are able to
handle), and a URI can be created to meet their needs.  Note that a SIP
UA potentially embodies multiple applications, you don't need to treat
the SIP UA as a single conceptual entity, even if that helps you from a
rhetorical perspective.  If you were architecting the UA under the
assumption that it can only have one piece of location information, then
you need to understand that you are introducing a limitation - but that
limitation is as a result of your decision, not a result of a problem in
a protocol.

Cheers,
Martin

---

From: Richard Barnes <[email-masked]>
Date: Wed, 20 Feb 2008 19:38:18 -0500

James,

Let me try to clarify the security thinking around Case 2:  In this 
case, you have to consider not just how the referenced thing can be 
accessed, but also what the referenced thing is.   The URI can point to 
a single, fixed LO, the real-time, dynamic location, or something in 
between.   The set of things that are exposed is the set of values that 
the URI points to over time. 

Now, we trust the endpoint with its own LO when we provide location by 
value.  Note that this is equivalent in terms of risk to an 
unauthenticated "case 2" URI that only ever dereferences to that LO (the 
set of referenced locations is the single LO).  The risk is slightly 
higher if the location updates, say, weekly (slightly bigger set), and 
the risk is highest when the location is updated continuously (very big 
set).

It's the policy of the LS referenced in the URI (influenced by the Rule 
Maker) that determines the set of things to which a URI refers over 
time.  So the requirement here is that if the LS is not going to apply 
authentication and authorization policy to a reference then it SHOULD 
set dereference policy to minimize the set of locations to which that 
URI refers.

We have some language to this effect in draft-barnes-geopriv-lo-sec-02, 
which will come out some time in the next few days.

--Richard

James M. Polk wrote:
>>> Case 1: Access limited by policy. LS applies authentication and 
>>> access control at dereference.  In this case, the URI can be of any 
>>> form chosen by the LS.
>>>
> but aren't we (geopriv, and this group of folks) all about "once a 
> piece of information is transmitted, it really can't be controlled"? 
> If this is the case, the above (case #2) cannot be a destination, 
> without assuming zero security properties.  Case in point, a UA will 
> sent this out whenever it calls 911/112 (or sos), without any security 
> properties.  That same UA will send this URI out to Pizza Hut to route 
> both the call and the delivery guy to the most appropriate store for 
> the UA's present location.
>
> All this says is that possession of the URI shouldn't mean 
> authorization, because anyone snooping in from of Pizza Hut's SIP 
> server will have every authorized URI of everyone that wants Pizza on 
> any given night, and this *could* be on a regional or national or 
> international scale.
>
>>>> In this model there are authorization policies uploaded by the 
>>>> These authorization policies tell the LIS which entities are 
>>>> allowed to retrieve location information.
>>>>
>>>> I am interested in the "possession model" since I believe it is 
>>>> more likely to see some deployment. If you want to work also on the 
>>>>> this doesn't make it have to be "cryptographically random", just 
>>>>> NOT contain user identity.
>>>>>
>>>>>
>>>>
>>>>> The URI itself doesn't reveal location of the Target. Remember, 
>>>>> the LIS will also challenge each request.
>>>>>
>>>>>
>>>>> If I time out that URI by not keeping it currently fresh, and I 
>>>>> get I get this Location URI the next time I ask for a ask
>>>>> This scenario easily accomplishes what you are wanting, and it's 
>>>>> not "cryptographically random".
>>>>>
>>>>>
>>>>> Authorization check of what, of the URI? That is done when a 
>>>>> request is sent to the LIS, regardless of whether I have the same 
>>>>> URI or different URI *AND* regardless of whether this URI is 
>>>>>> As such, it is important from a security and privacy point of 
>>>>>> view that part of the URI is randomly created.
>>>>>>
>>>>> produce a PIDF-LO from this URI, why isn't the burden on the LIS 
>>>>> to make sure its challenges are robust. This also burdens the 
>>>>>> You might not know the real identity of the Target; maybe - 
>>>>>> unless someone puts an appropriate value into the PIDF-LO.
>>>>>>
>>>>> correct!
>>>>>
>>>>>
>>>>> I still want to know why it has to be a random number. I'll give 
>>>>> you that it has to be randomly selected for each client, and 
>>>>> perhaps randomly assigned each time a new non-active location URI 
>>>>> is asked for, but it then doesn't have to be a random number -- 
>>>>> not when there is a server that challenges all requests for the 
>>>>> PIDF-LO of the Target.
>>>>>
>>>>>
>>>>>
>>>>>> implementers are likely to get wrong and it will subsequently 
>>>>>> lead to a lower level of security and privacy. Hence, a MUST is 
>>>>>> justified.
>>>>>>