Subject: [Geopriv] draft-ietf-geopriv-rfc3825bis

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Aug 2010 10:33:47 +0300

Hi all, 

during the GEOPRIV meeting I mentioned missing text in
draft-ietf-geopriv-rfc3825bis regarding security. 

DHCP does not provide confidentiality protection as a built-in feature.
As Marc mentioned in response to issue#23 (see
http://trac.tools.ietf.org/wg/geopriv/trac/ticket/23) every target would
be given the exact same location information on a shared medium.

Unfortunately, the security consideration section does not mention this
aspect with a single word. Hence, I suggest to add: 

"
   Since there is no confidentiality protection for DHCP messages, an
   eavesdropper who can monitor the link between the DHCP server and
   requesting client can discover this LCI. In cases where multiple 
   hosts share the same link and can therefore see each others DHCP 
   messages the DHCP MUST NOT hand out location for individual hosts 
   but MUST rather provide location of the DHCP relay, DHCP server, 
   or a similar device instead. This ensures that none of the end
   devices are able to learn exact information of the other hosts 
   on the same network.
"

Ciao
Hannes

---

From: Marc Linsner <[email-masked]>
Date: Tue, 10 Aug 2010 08:23:13 -0400

Hannes,

On 8/10/10 3:33 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
<[email-masked]> wrote:

> aspect with a single word.

Not true, currently in the security consideration section of the draft:

" Since there is no privacy protection for DHCP messages, an
   eavesdropper who can monitor the link between the DHCP server and
   requesting client can discover this LCI."

I don't believe more text is needed.

-Marc-

 Hence, I suggest to add:
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Aug 2010 15:25:47 +0300

But the conclusion is missing: if you are on a shared link then you must
not share location at the level of the individual hosts. I fear that
those who implement and deploy would not get the point and would
nevertheless reveal information and put the user at risk.  

> -----Original Message-----
> From: ext Marc Linsner [mailto:[email-masked]] 
> Sent: Tuesday, August 10, 2010 3:23 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> Subject: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis
> 
> Hannes,
> 
>

---

From: Ivan Shmakov <[email-masked]>
Date: Tue, 10 Aug 2010 19:45:56 +0700

>>>>> [email-masked] writes:
>>>>> Marc Linsner <[email-masked]> writes:
>>>>> [email-masked] writes:

 >>> Unfortunately, the security consideration section does not mention
 >>> this aspect with a single word. Hence, I suggest to add:

 >>>    Since there is no confidentiality protection for DHCP messages,
 >>>    an eavesdropper who can monitor the link between the DHCP server
 >>>    and requesting client can discover this LCI. In cases where
 >>>    multiple hosts share the same link and can therefore see each
 >>>    others DHCP messages the DHCP MUST NOT hand out location for
 >>>    individual hosts but MUST rather provide location of the DHCP
 >>>    relay, DHCP server, or a similar device instead. This ensures
 >>>    that none of the end devices are able to learn exact information
 >>>    of the other hosts on the same network.

 > But the conclusion is missing: if you are on a shared link then
 > you must not share location at the level of the individual
 > hosts. I fear that those who implement and deploy would not get
 > the point and would nevertheless reveal information and put the
 > user at risk.

	Somehow, I feel that this is a valid concern.  However, as there
	may be “whole network is trusted” scenarios (although unlikely),
	I'd suggest “SHOULD NOT” instead of “MUST NOT”.

-- 
FSF associate member #7257

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Aug 2010 15:48:35 +0300

> 	may be "whole network is trusted" scenarios (although unlikely),
> 	I'd suggest "SHOULD NOT" instead of "MUST NOT".

Sounds good. 

In an enterprise environment it probably does not matter. I was just
thinking about the typical hotel network, university network, etc. Where
you can see the HTTP traffic and then, also the detailed location
(room#120) along with it. It is not too far fetched to see problems with
privacy....

---

From: Marc Linsner <[email-masked]>
Date: Tue, 10 Aug 2010 08:59:17 -0400

Hannes,

What specific network type(s) are you worried about?

-Marc-

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Aug 2010 16:09:44 +0300

Think about a regular hotel network.  

> Sent: Tuesday, August 10, 2010 3:59 PM

---

From: Brian Rosen <[email-masked]>
Date: Tue, 10 Aug 2010 09:11:21 -0400

But the reality is that everyone uses switched architecture and unless you have admin access to the switch you can't do that.

I personally think the existing text is quite sufficient.  I really do give readers some credit for deductive reasoning.  Of course we put location to the level of an individual host.  We know that the value of the information far exceeds the risk of eavesdropping in the actual deployments (because of the above, the risk of eavesdropping is very low).

Brian

---

From: Marc Linsner <[email-masked]>
Date: Tue, 10 Aug 2010 09:14:11 -0400

Hannes,

Think about what you are saying.

The only medium currently in use that works as you posit is 802.11.  How
practical (or even possible) is it to use DHCP to provide device level
location values on a wireless network?  Think thru how one might implement
such a mechanism and you'll realize it ain't gonna happen!

-Marc-

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Aug 2010 15:17:33 +0200

The security consideration section in the draft is there to indicate what the potential risks are and what should be done about them. 

I have heard someone saying that "64kb ought to be enough for everyone"...

-------- Original-Nachricht --------
> Datum: Tue, 10 Aug 2010 09:14:11 -0400
> Von: Marc Linsner begin_of_the_skype_highlighting     end_of_the_skype_highlighting <[email-masked]>
> An: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>, [email-masked]
> Betreff: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Aug 2010 09:18:59 -0400

We seem to be more in danger of replicating

http://www.rinkworks.com/said/warnings.shtml

---

From: Marc Linsner <[email-masked]>
Date: Tue, 10 Aug 2010 09:22:59 -0400

On 8/10/10 9:17 AM, "Hannes Tschofenig" <[email-masked]> wrote:

> The security consideration section in the draft is there to indicate what the
> potential risks are and what should be done about them.

And I'm claiming that the risk is zero, hence we don't need any extra
guidance.

-Marc-

>> Von: Marc Linsner
>> begin_of_the_skype_highlighting     end_of_the_skype_highlighting
>> <[email-masked]>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Aug 2010 15:25:59 +0200

I recently attend the "W3C Workshop on Privacy for Advanced Web APIs" and you wouldn't imagine how browser vendors messed up their geolocation implementation (at least the privacy part). 

The same guys who previously said that they do not need any guidance about user interface aspects or other recommendations claimed at the workshop that they should have had them in the spec.

This is probably the most useful advice we can give regarding privacy in the entire document. I would rather replace the text about the DHCP authentication option, which isn't deployable. 

-------- Original-Nachricht --------
> Datum: Tue, 10 Aug 2010 09:18:59 -0400
> Von: Henning Schulzrinne <[email-masked]>
> An: "Hannes Tschofenig" <[email-masked]>
> CC: Marc Linsner begin_of_the_skype_highlighting     end_of_the_skype_highlighting <[email-masked]>, [email-masked], [email-masked]

> > The security consideration section in the draft is there to indicate
> what the potential risks are and what should be done about them. 
> >

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Aug 2010 15:26:59 +0200

You are saying that nobody is going to deploy location at the level of individual hosts (but only at the level of access points) and hence there is no risk. 

If you think so then write that into the draft. 

-------- Original-Nachricht --------
> Datum: Tue, 10 Aug 2010 09:22:59 -0400
> An: Hannes Tschofenig <[email-masked]>, [email-masked], [email-masked]

> what the

---

From: Marc Linsner <[email-masked]>
Date: Tue, 10 Aug 2010 09:55:14 -0400

Hannes,

On 8/10/10 9:26 AM, "Hannes Tschofenig" <[email-masked]> wrote:

> You are saying that nobody is going to deploy location at the level of
> individual hosts (but only at the level of access points) and hence there is
> no risk. 
> 

I don't believe it's necessary.

Further, RFC3825 includes:

" Wireless hosts can utilize this option to gain knowledge of the
   location of the radio access point used during host configuration,
   but would need some more exotic mechanisms, maybe GPS, or maybe a
   future DHCP option, which includes a list of geo-locations like that
   defined here, containing the locations of the radio access points
   that are close to the client"

Since draft-ietf-geopriv-rfc3825bis is updating RFC3825, it takes strong
consensus to add/remove text from RFC3825.  Since this text is missing from
draft-ietf-geopriv-rfc3825bis, one has to assume the wg agreed to taking it
out.

You might want to go back and figure out why this text was removed and
suggest that it's put back in, or modified and put back in.

-Marc-

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 10 Aug 2010 08:42:25 -0600

Hannes -

Very interesting. Back in Dec 2008, the Geolocation API document simply 
stated "TBD" for the privacy section. I asked the editors about this and 
they said that they were in discussions with the IETF GeoPRIV community. 
Interesting as the current version of the API is still pretty light on 
privacy - and is not even aligned well with the OMA privacy guidance.

Cheers

Carl

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 10, 2010 7:25 AM
Subject: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis

>I recently attend the "W3C Workshop on Privacy for Advanced Web APIs" and 
>you wouldn't imagine how browser vendors messed up their geolocation 
>implementation (at least the privacy part).
>
> The same guys who previously said that they do not need any guidance about 
> user interface aspects or other recommendations claimed at the workshop 
> that they should have had them in the spec.
>
> This is probably the most useful advice we can give regarding privacy in 
> the entire document. I would rather replace the text about the DHCP 
> authentication option, which isn't deployable.
>
>> CC: Marc Linsner begin_of_the_skype_highlighting 
>> end_of_the_skype_highlighting <[email-masked]>, [email-masked], 
>> [email-masked]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Aug 2010 18:31:30 +0300

Unfortunately not only the specification is weak on privacy but also the
implementations that followed afterwards. A Berkeley report nicely
summarizes the situation: 
http://dret.net/biblio/reference/dot10a

Unfortunately, there is no indication that either the Geolocation API
nor the new work on the Device API will provide better privacy
protection. 

Ciao
Hannes

> From: ext Carl Reed [mailto:[email-masked]] 
> Sent: Tuesday, August 10, 2010 5:42 PM
> To: Hannes Tschofenig; Henning Schulzrinne
> Cc: [email-masked]; [email-masked]; Tschofenig, Hannes 
> (NSN - FI/Espoo)

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 16 Aug 2010 15:37:51 -0500

>Think about a regular hotel network.

many/most wired hotel networks are DSL-like based, so this doesn't 
apply as directly as it may seem.

What you are suggesting (that the server MUST NOT hand out location 
in shared mediums) is requiring a DHCP server to have physical 
topological awareness before implementing option 123.  The same DHCP 
server can be unaware of ever network topology between it and the 
client - therefore I believe you are placing an excessive burden or 
limitation on DHCP as an LCI delivery means.

I'm concerned about the SMB or residential gateway impact of adding 
this context - which can easily lead to some vendor(s) reading what 
you are proposing and consider DHCP not appropriate for homes or 
small businesses inadvertently, where it otherwise would be logical 
to use. Many gateways of this sort have DHCP as a client to the WAN, 
and as a server to the LAN.

We need to be careful with how we word any changes.

James

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 17 Aug 2010 10:46:11 +0300

> apply as directly as it may seem.

Whether the hotel network provider uses DSL or Cable does not matter for
this purpose. 

> limitation on DHCP as an LCI delivery means.

The GEOPRIV working group is about describing what privacy properties
are being provided for the solutions we develop. You have always been
quite keen on documenting everything in detail -- particularly when
other people proposed something. 

Describing what we assume are reasonable operational considerations that
are applicable is a good thing, I believe. 
We cannot have all these chats about how important privacy is for us but
then when it actually has an operational impact then we back-off. 

In this specific case, I am not sure I understand what you mean with
additional requirements. A DHCP server better has an idea about the
network topology since otherwise how does it hand out the IP addresses
and other configuration parameters.

> We need to be careful with how we word any changes.

There are two parts here: 

1) The first part is to describe what the privacy risks are with the
technology
2) The second part is to make some recommendations for anticipated
envionments. 

With SMBs and the usage of this document you are touch on item #2. Your
recommendation would be that the privacy risks are not so dramatic in
such an environment and I believe it is OK to say that. 

You still want to talk about item #1 in the document. 

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 17 Aug 2010 10:52:41 -0500

>Whether the hotel network provider uses DSL or Cable does not matter for

huh? Cable uses BPI, and DSL systems are individually run. How are 
they the same, and why is this an issue?

>are applicable is a good thing, I believe.

and yet your text could prevent a valid design choice(s). So how is that good?

>and other configuration parameters.

for one, RAIO means it doesn't matter what topology is between the 
server and the RAIO, but your suggested text doesn't account for that.

another point, in a built wiremap database, as long as the final link 
is switched, the entire topology is immaterial - which isn't 
accounted for in your text either.

and still another point, if the final hop is within the house, and 
the house has a shared topology, does that mean the location provided 
by the home gateway (acting as a DHCP server to the home) is an 
invalid topology? You text says this home gateway MUST NOT hand out 
any location, which is just plain wrong.

>1) The first part is to describe what the privacy risks are with the

the doc already has a warning about DHCP communications not being 
secure, and that already passed IESG review in RFC 3825. What changed 
in this version that made things so much more insecure to warrant 
modifying the text about that warning?

>2) The second part is to make some recommendations for anticipated

Then I suggest you offer text about every type of topology and see if 
you can get "strong" consensus, which is required to change the text 
of a "bis" document.

>You still want to talk about item #1 in the document.

it is already there, as I and others have stated.

James

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 18 Aug 2010 11:39:49 +0300

Hi James, 

I already suggested text that should be included.
If this group cares about privacy then the document should better say
something (like it does in other documents as well). 

Ciao
Hannes

> > > > > >> Not true, currently in the security consideration 
> section of
> > > > > >> the draft:
> > > > > >>

---

From: Marc Linsner <[email-masked]>
Date: Wed, 18 Aug 2010 08:44:48 -0400

Hannes,

Do you agree that it's OK for DHCP to deliver device level location on
networks that provide confidentiality at layer 2?

-Marc-