Subject: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions

From: Cullen Jennings <[email-masked]>
Date: Sun, 8 Nov 2009 13:28:23 +0900

I really hope we get some discussion on this at this meeting. Take for  
example using a MAC address as an identifier. A request arrives and  
requests the location of device with a given MAC. How does  the server  
know if it should answer this or not? If it has an IP to MAC mapping,  
why did it need the MAC, and why not use use IP.

I don't think the answer can be it knows due to something that will  
described some time later. That answer seems like it would not meet  
the IETF goals of security that can be implemented (even it it is not  
used) or the general charter of this WG.

I don't understanding how the privacy part of this is protected. I  
need to understand that or I worry that this work is not appropriate  
for geopriv WG.

Cullen <in my RAI AD role>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 7 Nov 2009 21:38:06 -0800

We've had some discussion on this topic before.   The answer probably involves
one or more of the following:

1. Use within an architecture (such as that being discussed in the IEEE 802 
Emergency Services Study Group) in which the LIS is only one hop from 
the client.   In that case, the LIS would know that the MAC being requested
is the same as the originator of the request. 

2. Use within an architecture (such as WiMAX or 802.1ar) in the HELD server
could potentially verify that the MAC address being requested corresponds
to the MAC address in the client certificate, and that the client certificate
chains to a pre-established trust anchor. 

3. Where the MAC being requested cannot be verified, the LIS could only provide
responses to queries for a set of pre-arranged MAC addresses 
for whom location is already made publicly available via existing LCPs. 
For example, LLDP-MED and IEEE 802.11k provide geospatial 
coordinates corresponding to AP or switch ports.  11k and LLDP frames 
are neither authenticated nor encrypted and are available to any host 
with access to the medium; as a result, this information can be
considered public. 

> From: [email-masked]
> Date: Sun, 8 Nov 2009 13:28:23 +0900
> To: [email-masked]
> Subject: [Geopriv] Serious concerns about security of	draft-ietf-geopriv-held-identity-extensions
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 8 Nov 2009 15:25:34 +0800

I have a slightly different perspective on this issue.  Richard and I just discussed this briefly and came to a different viewpoint that matches with Hannes’ prior expressed opinion.

I tend to see identity parameters in the first-party/LCP case as being superfluous, but harmless. There is no benefit in preventing the use of identity in first-party/LCP requests. There are almost always mechanisms where the identifier provided could be determined by other means (as cited).  For instance, there are many ways by which an IP-MAC linkage can be determined; there are simple means in 3GPP for their identifiers; and so on.

These mechanisms could, in the case where an identifier is provided, be used to authenticate the identity and authorize a request under LCP terms.  If a LIS implementation chooses to allow this, and authenticate by using these mechanisms, then applying the LCP policy as described is acceptable.

--Martin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Sunday, 8 November 2009 2:38 PM
To: [email-masked]; [email-masked]
Subject: Re: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 8 Nov 2009 16:00:20 +0800

I was thinking of a simple practical example.

I have a closed private/enterprise network with a bunch of location client devices to my LIS. My LIS has access to the bridge MIBs on all the switches in the building(s) and it has the wiremap that relates each switch port to the location of the wall jack or area of coverage of the wireless access point to which that port is connected. So - given a MAC address, the LIS can determine the associated switch/port and corresponding location by performing the bridge MIB query on the switches followed by a wiremap look up.

In this network the DHCP implementation is limited; it doesn't support the DHCP lease query for example... and the IT department refuses to change or permit it to be patched to support the functionality. So, I'm stuck, not being able to translate the IP address of my requesting clients into the corresponding MAC address that allows me to provide them with location.

Now there are absolutely no interesting scenarios in this environment where anybody cares or is in any way at risk if a client offers a MAC address that isn't its own. It's simply not a problem.

In this particular trust arrangement, it's acceptable for the LIS to return the location to the requester. This is a real situation; not just a hypothetical one.

Trust always involves nominating where risk is considered acceptable. Even if the DHCP server wasn't so "challenged", the LIS still has to trust the information acquired from it. In principle the DHCP server could be compromised... or have devious intent. In order to obviate this concern, the trust arrangement has to encompass the DHCP server as well.

Cheers,
Martin

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Sunday, 8 November 2009 4:38 PM
To: [email-masked]; [email-masked]
Subject: Re: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions

---

From: Marc Linsner <[email-masked]>
Date: Sun, 08 Nov 2009 10:13:38 -0500

Martin,

I think this use case corresponds to Cullen¹s last statement, ³ this work is
not appropriate for geopriv WG².  This is more suitable for the Geo-Non_Priv
WG.  :^)

I find it very interesting that the IT department embraces the new
functionality of providing location to network clients but refuses to
implement the tools to get the job done.  Maybe they should look at a
LLDP-MED solution.

-Marc-

On 11/8/09 3:00 AM, "Dawson, Martin" <[email-masked]> wrote:

> I have a closed private/enterprise network with a bunch of location client
> devices to my LIS. My LIS has access to the bridge MIBs on all the switches in
> the building(s) and it has the wiremap that relates each switch port to the
> location of the wall jack or area of coverage of the wireless access point to
> which that port is connected. So  given a MAC address, the LIS can determine
> the associated switch/port and corresponding location by performing the bridge
> MIB query on the switches followed by a wiremap look up.
>  
> In this network the DHCP implementation is limited; it doesn¹t support the
> DHCP lease query for exampleŠ and the IT department refuses to change or
> permit it to be patched to support the functionality. So, I¹m stuck, not being
> able to translate the IP address of my requesting clients into the
> corresponding MAC address that allows me to provide them with location.
>  
> Now there are absolutely no interesting scenarios in this environment where
> anybody cares or is in any way at risk if a client offers a MAC address that
> isn¹t its own. It¹s simply not a problem.
>  
> In this particular trust arrangement, it¹s acceptable for the LIS to return
> the location to the requester. This is a real situation; not just a
> hypothetical one.
>  
> Trust always involves nominating where risk is considered acceptable. Even if
> the DHCP server wasn¹t so ³challenged², the LIS still has to trust the
> information acquired from it. In principle the DHCP server could be
> compromisedŠ or have devious intent. In order to obviate this concern, the
> trust arrangement has to encompass the DHCP server as well.
>  
> Cheers,
> Martin
>  
> 
> 
> Subject: Re: [Geopriv] Serious concerns about security of
> draft-ietf-geopriv-held-identity-extensions
>  
>> > Subject: [Geopriv] Serious concerns about security of
>> draft-ietf-geopriv-held-identity-extensions
>> > 
>> >

---

From: Marc Linsner <[email-masked]>
Date: Sun, 08 Nov 2009 10:33:14 -0500

Martin,

This has been discussed before.  The case where the identifier is from an
application (phone number, etc.) you are assuming/forcing a relationship
between the access provider and the application provider for the purposes of
authenticating the request as a coming from the target.

-Marc-

On 11/8/09 2:25 AM, "Thomson, Martin" <[email-masked]> wrote:

> I have a slightly different perspective on this issue.  Richard and I just
> discussed this briefly and came to a different viewpoint that matches with
> Hannes¹ prior expressed opinion.
>  
> I tend to see identity parameters in the first-party/LCP case as being
> superfluous, but harmless. There is no benefit in preventing the use of
> identity in first-party/LCP requests. There are almost always mechanisms where
> the identifier provided could be determined by other means (as cited).  For
> instance, there are many ways by which an IP-MAC linkage can be determined;
> there are simple means in 3GPP for their identifiers; and so on.
>  
> These mechanisms could, in the case where an identifier is provided, be used
> to authenticate the identity and authorize a request under LCP terms.  If a
> LIS implementation chooses to allow this, and authenticate by using these
> mechanisms, then applying the LCP policy as described is acceptable.
>  
> --Martin
>  
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 8 Nov 2009 23:33:28 +0800

It's not that interesting... or unusual :)

But it still is appropriate to Geopriv because, per my comments, privacy isn't measured in terms of specific technology mechanisms; it's what's appropriate to the specific privacy domain. A DHCP server is not inherently more trustable than a host; it's the environment in which they operate that determines that.

Cheers,
Martin

________________________________
From: Marc Linsner [mailto:[email-masked]]
Sent: Monday, 9 November 2009 2:14 AM
To: Dawson, Martin; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions

Martin,

I think this use case corresponds to Cullen's last statement, " this work is not appropriate for geopriv WG".  This is more suitable for the Geo-Non_Priv WG.  :^)

I find it very interesting that the IT department embraces the new functionality of providing location to network clients but refuses to implement the tools to get the job done.  Maybe they should look at a LLDP-MED solution.

-Marc-

Cheers,
Martin

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 8 Nov 2009 10:39:31 -0800

In the scenario given, is it really true that "anybody cares or is in any
way at risk if a client offers a MAC address that isn't  its own"? 

My understanding is that providing blanket access to the geographic location
of any employee without authorization would violate privacy laws within some
nations (I am thinking about Germany in particular).   So I'm aware of a
number of enterprise Privacy officers who care quite a bit about this. 

As to whether someone is at risk, consider recent violent stalking incidents
at the University of  Washington and other places.  Can we really say that
no one would be put at risk by allowing their location to be tracked in real
time by an unauthorized person?   I'm aware of quite a few people whose
lives could be put at risk by something like this. 

 Marc Linsner said:

"I find it very interesting that the IT department embraces the new
functionality of providing location to network clients but refuses to
implement the tools to get the job done.  Maybe they should look at a
LLDP-MED solution."

I know quite a few IT departments that have no plans to implement either
DHCP or LLDP-MED.    Most endpoints in the enterprise do not support DHCP
location today, so even if IT has a DHCP server that would support this,
this solution will typically not be applicable.  While most switches support
LLDP today, access points typically do not and therefore a solution may be
desired which applies to both wired and wireless.  

In contrast, HELD offers the potential for use on both wired and wireless
media without any required changes to system-level components.  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dawson, Martin
Sent: Sunday, November 08, 2009 12:00 AM
To: [email-masked]; [email-masked]
Subject: Re: [Geopriv] Serious concerns about security of
draft-ietf-geopriv-held-identity-extensions

I have a closed private/enterprise network with a bunch of location client
devices to my LIS. My LIS has access to the bridge MIBs on all the switches
in the building(s) and it has the wiremap that relates each switch port to
the location of the wall jack or area of coverage of the wireless access
point to which that port is connected. So - given a MAC address, the LIS can
determine the associated switch/port and corresponding location by
performing the bridge MIB query on the switches followed by a wiremap look
up.

In this network the DHCP implementation is limited; it doesn't support the
DHCP lease query for example. and the IT department refuses to change or
permit it to be patched to support the functionality. So, I'm stuck, not
being able to translate the IP address of my requesting clients into the
corresponding MAC address that allows me to provide them with location.

Now there are absolutely no interesting scenarios in this environment where
anybody cares or is in any way at risk if a client offers a MAC address that
isn't its own. It's simply not a problem.

In this particular trust arrangement, it's acceptable for the LIS to return
the location to the requester. This is a real situation; not just a
hypothetical one.

Trust always involves nominating where risk is considered acceptable. Even
if the DHCP server wasn't so "challenged", the LIS still has to trust the
information acquired from it. In principle the DHCP server could be
compromised. or have devious intent. In order to obviate this concern, the
trust arrangement has to encompass the DHCP server as well.

Cheers,

Martin

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernard Aboba

We've had some discussion on this topic before.   The answer probably
involves
one or more of the following:

2. Use within an architecture (such as WiMAX or 802.1ar) in the HELD server
could potentially verify that the MAC address being requested corresponds
to the MAC address in the client certificate, and that the client
certificate
chains to a pre-established trust anchor. 

3. Where the MAC being requested cannot be verified, the LIS could only
provide

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 9 Nov 2009 04:03:03 +0800

________________________________
From: Bernard Aboba [mailto:[email-masked]]
Sent: Monday, 9 November 2009 5:40 AM
To: Dawson, Martin; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions

In the scenario given, is it really true that "anybody cares or is in any way at risk if a client offers a MAC address that isn't  its own"?
[[MCD]] It is - and that's up to the owner and users of the network to decide. If it wasn't - i.e. trust does not extend to all hosts - then it would not be appropriate for a LIS serving such an environment to provide location based on proffered MAC address alone. I can consider the events you mention; and conclude that you're describing a different scenario.

My understanding is that providing blanket access to the geographic location of any employee without authorization would violate privacy laws within some nations (I am thinking about Germany in particular).   So I'm aware of a number of enterprise Privacy officers who care quite a bit about this.

As to whether someone is at risk, consider recent violent stalking incidents at the University of  Washington and other places.  Can we really say that no one would be put at risk by allowing their location to be tracked in real time by an unauthorized person?   I'm aware of quite a few people whose lives could be put at risk by something like this.

 Marc Linsner said:

"I find it very interesting that the IT department embraces the new functionality of providing location to network clients but refuses to implement the tools to get the job done.  Maybe they should look at a LLDP-MED solution."

I know quite a few IT departments that have no plans to implement either DHCP or LLDP-MED.    Most endpoints in the enterprise do not support DHCP location today, so even if IT has a DHCP server that would support this, this solution will typically not be applicable.  While most switches support LLDP today, access points typically do not and therefore a solution may be desired which applies to both wired and wireless.

In contrast, HELD offers the potential for use on both wired and wireless  media without any required changes to system-level components.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dawson, Martin
Sent: Sunday, November 08, 2009 12:00 AM
To: [email-masked]; [email-masked]
Subject: Re: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions

Cheers,
Martin

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 8 Nov 2009 13:03:34 -0800

Is it really necessary to require that "trust extend to all hosts" in order to use a MAC address as an identifier?  If that is really the requirement (personally, I don't think it needs to be), then I'd agree with Cullen that this work is outside the charter of GEOPRIV WG. 

In some of the architectures discussed in IEEE 802 Emergency Services study group, the LIS is located on the emergency services VLAN, as are the emergency callers.  So the LIS can compare the source MAC address of the requester to the MAC address identifier in the request. 

There are also scenarios where the client can infer its own location based on receiving information on the location of landmarks such as switch ports or access points.  This already supported with LLDP-MED or IEEE 802.11k.  Why shouldn't it also be possible with HELD?  Here requests are only answered if the MAC address being requested corresponds to a landmark; unauthenticated queries for the MAC addresses of other hosts are denied.  

If one of the above scenarios doesn't hold, then the query needs to be authenticated, so that the LIS can decide whether the requester is authorized to receive a response.  

From:
Bernard Aboba [mailto:[email-masked]] 

Sent: Monday, 9 November 2009 5:40
AM

To: Dawson,
 Martin; [email-masked]; [email-masked]

Subject: RE: [Geopriv] Serious
concerns about security of draft-ietf-geopriv-held-identity-extensions

In the scenario
given, is it really true that “anybody cares or is in any way at risk if
a client offers a MAC address that isn’t  its own”? 

[[MCD]] It is – and that’s up to the owner and
users of the network to decide. If it wasn’t – i.e. trust does not
extend to all hosts – then it would not be appropriate for a LIS serving
such an environment to provide location based on proffered MAC address alone. I
can consider the events you mention; and conclude that you’re describing
a different scenario.

My understanding is
that providing blanket access to the geographic location of any employee
without authorization would violate privacy laws within some nations (I am thinking
about Germany
in particular).   So I’m aware of a number of enterprise
Privacy officers who care quite a bit about this. 

As to whether
someone is at risk, consider recent violent stalking incidents at the University of  Washington and other places.  Can
we really say that no one would be put at risk by allowing their location to be
tracked in real time by an unauthorized person?   I’m aware of
quite a few people whose lives could be put at risk by something like this. 

 Marc Linsner said:

“I
find it very interesting that the IT department embraces the new functionality
of providing location to network clients but refuses to implement the tools to
get the job done.  Maybe they should look at a LLDP-MED solution.”

I know quite a few
IT departments that have no plans to implement either DHCP or
LLDP-MED.    Most endpoints in the enterprise do not support
DHCP location today, so even if IT has a DHCP server that would support this,
this solution will typically not be applicable.  While most switches
support LLDP today, access points typically do not and therefore a solution may
be desired which applies to both wired and wireless.  

In contrast, HELD
offers the potential for use on both wired and wireless  media without any
required changes to system-level components.  

From:
[email-masked] [mailto:[email-masked]] On Behalf Of Dawson,
 Martin

Sent: Sunday, November 08, 2009
12:00 AM

To: [email-masked];
[email-masked]

Subject: Re: [Geopriv] Serious
concerns about security of draft-ietf-geopriv-held-identity-extensions

I was thinking of a simple practical
example.

I have a closed private/enterprise network
with a bunch of location client devices to my LIS. My LIS has access to the
bridge MIBs on all the switches in the building(s) and it has the wiremap that
relates each switch port to the location of the wall jack or area of coverage
of the wireless access point to which that port is connected. So – given
a MAC address, the LIS can determine the associated switch/port and
corresponding location by performing the bridge MIB query on the switches
followed by a wiremap look up.

In this network the DHCP implementation is
limited; it doesn’t support the DHCP lease query for example… and
the IT department refuses to change or permit it to be patched to support the
functionality. So, I’m stuck, not being able to translate the IP address
of my requesting clients into the corresponding MAC address that allows me to
provide them with location.

Now there are absolutely no interesting
scenarios in this environment where anybody cares or is in any way at risk if a
client offers a MAC address that isn’t its own. It’s simply not a
problem.

In this particular trust arrangement,
it’s acceptable for the LIS to return the location to the requester. This
is a real situation; not just a hypothetical one.

Trust always involves nominating where
risk is considered acceptable. Even if the DHCP server wasn’t so
“challenged”, the LIS still has to trust the information acquired
from it. In principle the DHCP server could be compromised… or have
devious intent. In order to obviate this concern, the trust arrangement has to
encompass the DHCP server as well.

Cheers,

Martin

From:
[email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba

Sent: Sunday, 8 November 2009 4:38
PM

To: [email-masked];
[email-masked]

Subject: Re: [Geopriv] Serious
concerns about security of draft-ietf-geopriv-held-identity-extensions

We've had some discussion on this topic
before.   The answer probably involves

the client.   In that case, the LIS would know that the MAC being
requested

considered public.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 9 Nov 2009 06:59:16 +0800

That is, these scenarios really are third party request scenarios and each require explicit policy.  What that conclusion, I see no issue.

Martin, your scenario is simply not “LCP”.  If the enterprise decides that all hosts in the network can access location information for all other hosts, then they act as Rule Maker when allowing this.  While some of us may disagree with this policy, that is their prerogative as Rule Maker (as long another more powerful Rule Maker prevents it, like a legislator).

--Martin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Monday, 9 November 2009 6:04 AM
To: [email-masked]; [email-masked]
Subject: Re: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions

In the scenario given, is it really true that “anybody cares or is in any way at risk if a client offers a MAC address that isn’t  its own”?
[[MCD]] It is – and that’s up to the owner and users of the network to decide. If it wasn’t – i.e. trust does not extend to all hosts – then it would not be appropriate for a LIS serving such an environment to provide location based on proffered MAC address alone. I can consider the events you mention; and conclude that you’re describing a different scenario.

My understanding is that providing blanket access to the geographic location of any employee without authorization would violate privacy laws within some nations (I am thinking about Germany in particular).   So I’m aware of a number of enterprise Privacy officers who care quite a bit about this.

As to whether someone is at risk, consider recent violent stalking incidents at the University of  Washington and other places.  Can we really say that no one would be put at risk by allowing their location to be tracked in real time by an unauthorized person?   I’m aware of quite a few people whose lives could be put at risk by something like this.

 Marc Linsner said:

“I find it very interesting that the IT department embraces the new functionality of providing location to network clients but refuses to implement the tools to get the job done.  Maybe they should look at a LLDP-MED solution.”

I have a closed private/enterprise network with a bunch of location client devices to my LIS. My LIS has access to the bridge MIBs on all the switches in the building(s) and it has the wiremap that relates each switch port to the location of the wall jack or area of coverage of the wireless access point to which that port is connected. So – given a MAC address, the LIS can determine the associated switch/port and corresponding location by performing the bridge MIB query on the switches followed by a wiremap look up.

In this network the DHCP implementation is limited; it doesn’t support the DHCP lease query for example… and the IT department refuses to change or permit it to be patched to support the functionality. So, I’m stuck, not being able to translate the IP address of my requesting clients into the corresponding MAC address that allows me to provide them with location.

Now there are absolutely no interesting scenarios in this environment where anybody cares or is in any way at risk if a client offers a MAC address that isn’t its own. It’s simply not a problem.

In this particular trust arrangement, it’s acceptable for the LIS to return the location to the requester. This is a real situation; not just a hypothetical one.

Trust always involves nominating where risk is considered acceptable. Even if the DHCP server wasn’t so “challenged”, the LIS still has to trust the information acquired from it. In principle the DHCP server could be compromised… or have devious intent. In order to obviate this concern, the trust arrangement has to encompass the DHCP server as well.

Cheers,
Martin

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 9 Nov 2009 12:52:57 +0800

Well sure - which is to say "it's all semantic fluff".

The device is asking for its own location - and providing an identity value that will help with that process. I haven't seen the actual mathematical proof that says that isn't LCP but... sure... I'll take your word for it. There are certainly rule makers at play somewhere.

Cheers,
Martin

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomson, Martin
Sent: Monday, 9 November 2009 9:59 AM
To: Bernard Aboba; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions

Martin, your scenario is simply not "LCP".  If the enterprise decides that all hosts in the network can access location information for all other hosts, then they act as Rule Maker when allowing this.  While some of us may disagree with this policy, that is their prerogative as Rule Maker (as long another more powerful Rule Maker prevents it, like a legislator).

--Martin

 Marc Linsner said:

Cheers,
Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 9 Nov 2009 13:10:45 +0800

Semantic fluff?  If you like.

I was trying to be precise in definitions – such things are important in understanding the decisions that people make with respect to policy.  Being able to recognize that you are making a policy decision is the first part in then understanding the implications of that decision.

If the LIS can determine that the requester and target are the same – to its satisfaction, and I wont define what that means ;) – then it can use LCP policy; otherwise the security of the system demands that it operate on another policy.  That is the crux of Cullen’s complaint.  However, if no such alternative policy exists, then it cannot provide location.  That’s what the draft says.

--Martin

From: Dawson, Martin
Sent: Monday, 9 November 2009 1:53 PM
To: Thomson, Martin; Bernard Aboba; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions

Well sure – which is to say “it’s all semantic fluff”.

The device is asking for its own location – and providing an identity value that will help with that process. I haven’t seen the actual mathematical proof that says that isn’t LCP but… sure… I’ll take your word for it. There are certainly rule makers at play somewhere.

Cheers,
Martin

--Martin

 Marc Linsner said:

Cheers,
Martin

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 9 Nov 2009 13:18:02 +0800

And that is what the draft should say.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomson, Martin
Sent: Monday, 9 November 2009 4:11 PM
To: Dawson, Martin; Bernard Aboba; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions

I was trying to be precise in definitions - such things are important in understanding the decisions that people make with respect to policy.  Being able to recognize that you are making a policy decision is the first part in then understanding the implications of that decision.

If the LIS can determine that the requester and target are the same - to its satisfaction, and I wont define what that means ;) - then it can use LCP policy; otherwise the security of the system demands that it operate on another policy.  That is the crux of Cullen's complaint.  However, if no such alternative policy exists, then it cannot provide location.  That's what the draft says.

--Martin

From: Dawson, Martin

Cheers,
Martin

--Martin

 Marc Linsner said:

Cheers,
Martin

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Nov 2009 14:26:49 +0900

Maybe it's helpful to re-frame the argument Martin made below in  
procedural terms, as it would look to a LIS.

1. LIS gets a HELD request with identity extension
2. If the request comes from an authenticated identity that is  
authorized to request that identifier, then use the client IP with the  
identifier to determine location and return it
3. If the LIS can validate that the identifier belongs to the client,  
then use the client IP with the identifier to determine location and  
return it
4. If neither of the above two conditions applies, return the client's  
own location, or nothing.

In other words:
var returnedLocation;
var idExt = heldRequest.getIdentityExtension();
var clientIP = heldRequest.getRemoteAddress();
if ( scenarioSpecificOwnershipValidation(clientIP, idExt) ||  
applicationLevelAuthorization(clientIP, idExt) )
{
	return locationFromIPandIdExt(clientIP, idExt);
}
else
{
	return locationFromIP(clientIP);
}

1. In principle, the LIS doesn't need access to the identifier in  
order to authenticate it (like with passwords, where the server stores  
a hash) (ignoring whether this happens in practice)
2. The above process allows the LIS to make use of the identity  
extension without allowing any unauthorized third parties to access  
location

--Richard

On Nov 9, 2009, at 2:10 PM, Thomson, Martin wrote:

> I was trying to be precise in definitions – such things are  
> important in understanding the decisions that people make with  
> respect to policy.  Being able to recognize that you are making a  
> policy decision is the first part in then understanding the  
> implications of that decision.
>
> If the LIS can determine that the requester and target are the same  
> – to its satisfaction, and I wont define what that means ;) – then  
> it can use LCP policy; otherwise the security of the system demands  
> that it operate on another policy.  That is the crux of Cullen’s  
> complaint.  However, if no such alternative policy exists, then it  
> cannot provide location.  That’s what the draft says.
>
> --Martin
>
> From: Dawson, Martin
> The device is asking for its own location – and providing an  
> identity value that will help with that process. I haven’t seen the  
> actual mathematical proof that says that isn’t LCP but… sure… I’ll  
> take your word for it. There are certainly rule makers at play  
> somewhere.
>
> Cheers,
> Martin
>
> That is, these scenarios really are third party request scenarios  
> and each require explicit policy.  What that conclusion, I see no  
> issue.
>
> Martin, your scenario is simply not “LCP”.  If the enterprise  
> decides that all hosts in the network can access location  
> information for all other hosts, then they act as Rule Maker when  
> allowing this.  While some of us may disagree with this policy, that  
> is their prerogative as Rule Maker (as long another more powerful  
> Rule Maker prevents it, like a legislator).
>
> --Martin
>
> Is it really necessary to require that "trust extend to all hosts"  
> in order to use a MAC address as an identifier?  If that is really  
> the requirement (personally, I don't think it needs to be), then I'd  
> agree with Cullen that this work is outside the charter of GEOPRIV WG.
>
> In some of the architectures discussed in IEEE 802 Emergency  
> Services study group, the LIS is located on the emergency services  
> VLAN, as are the emergency callers.  So the LIS can compare the  
> source MAC address of the requester to the MAC address identifier in  
> the request.
>
> There are also scenarios where the client can infer its own location  
> based on receiving information on the location of landmarks such as  
> switch ports or access points.  This already supported with LLDP-MED  
> or IEEE 802.11k.  Why shouldn't it also be possible with HELD?  Here  
> requests are only answered if the MAC address being requested  
> corresponds to a landmark; unauthenticated queries for the MAC  
> addresses of other hosts are denied.
>
> If one of the above scenarios doesn't hold, then the query needs to  
> be authenticated, so that the LIS can decide whether the requester  
> is authorized to receive a response.
>
>
> In the scenario given, is it really true that “anybody cares or is  
> in any way at risk if a client offers a MAC address that isn’t  its  
> own”?
> [[MCD]] It is – and that’s up to the owner and users of the network  
> to decide. If it wasn’t – i.e. trust does not extend to all hosts –  
> then it would not be appropriate for a LIS serving such an  
> environment to provide location based on proffered MAC address  
> alone. I can consider the events you mention; and conclude that  
> you’re describing a different scenario.
>
> My understanding is that providing blanket access to the geographic  
> location of any employee without authorization would violate privacy  
> laws within some nations (I am thinking about Germany in  
> particular).   So I’m aware of a number of enterprise Privacy  
> officers who care quite a bit about this.
>
> As to whether someone is at risk, consider recent violent stalking  
> incidents at the University of  Washington and other places.  Can we  
> really say that no one would be put at risk by allowing their  
> location to be tracked in real time by an unauthorized person?   I’m  
> aware of quite a few people whose lives could be put at risk by  
> something like this.
>
>  Marc Linsner said:
>
> “I find it very interesting that the IT department embraces the new  
> functionality of providing location to network clients but refuses  
> to implement the tools to get the job done.  Maybe they should look  
> at a LLDP-MED solution.”
>
> I know quite a few IT departments that have no plans to implement  
> either DHCP or LLDP-MED.    Most endpoints in the enterprise do not  
> support DHCP location today, so even if IT has a DHCP server that  
> would support this, this solution will typically not be applicable.   
> While most switches support LLDP today, access points typically do  
> not and therefore a solution may be desired which applies to both  
> wired and wireless.
>
> In contrast, HELD offers the potential for use on both wired and  
> wireless  media without any required changes to system-level  
> components.
>
>
> I have a closed private/enterprise network with a bunch of location  
> client devices to my LIS. My LIS has access to the bridge MIBs on  
> all the switches in the building(s) and it has the wiremap that  
> relates each switch port to the location of the wall jack or area of  
> coverage of the wireless access point to which that port is  
> connected. So – given a MAC address, the LIS can determine the  
> associated switch/port and corresponding location by performing the  
> bridge MIB query on the switches followed by a wiremap look up.
>
> In this network the DHCP implementation is limited; it doesn’t  
> support the DHCP lease query for example… and the IT department  
> refuses to change or permit it to be patched to support the  
> functionality. So, I’m stuck, not being able to translate the IP  
> address of my requesting clients into the corresponding MAC address  
> that allows me to provide them with location.
>
> Now there are absolutely no interesting scenarios in this  
> environment where anybody cares or is in any way at risk if a client  
> offers a MAC address that isn’t its own. It’s simply not a problem.
>
> In this particular trust arrangement, it’s acceptable for the LIS to  
> return the location to the requester. This is a real situation; not  
> just a hypothetical one.
>
> Trust always involves nominating where risk is considered  
> acceptable. Even if the DHCP server wasn’t so “challenged”, the LIS  
> still has to trust the information acquired from it. In principle  
> the DHCP server could be compromised… or have devious intent. In  
> order to obviate this concern, the trust arrangement has to

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Nov 2009 14:33:45 +0900

James pointed out that there's a mistake in step 2 below, since the  
LIS isn't going to use the client IP in a third party query.  Likewise  
in the peudo-code.  This is why I have to write documents, not code.
--Richard

On Nov 9, 2009, at 2:26 PM, Richard Barnes wrote:

> authorized to request that identifier, then use the client IP with  
> the identifier to determine location and return it
> 3. If the LIS can validate that the identifier belongs to the  
> client, then use the client IP with the identifier to determine  
> location and return it
> 4. If neither of the above two conditions applies, return the  
> client's own location, or nothing.
>
> In other words:
> var returnedLocation;
> order to authenticate it (like with passwords, where the server  
> stores a hash) (ignoring whether this happens in practice)
>> allowing this.  While some of us may disagree with this policy,  
>> that is their prerogative as Rule Maker (as long another more  
>> powerful Rule Maker prevents it, like a legislator).
>>
>> --Martin
>>
>> the requirement (personally, I don't think it needs to be), then  
>> I'd agree with Cullen that this work is outside the charter of  
>> GEOPRIV WG.
>>
>> source MAC address of the requester to the MAC address identifier  
>> in the request.
>>
>> There are also scenarios where the client can infer its own  
>> location based on receiving information on the location of  
>> landmarks such as switch ports or access points.  This already  
>> supported with LLDP-MED or IEEE 802.11k.  Why shouldn't it also be  
>> possible with HELD?  Here requests are only answered if the MAC  
>> address being requested corresponds to a landmark; unauthenticated  
>> queries for the MAC addresses of other hosts are denied.
>>
>> location of any employee without authorization would violate  
>> privacy laws within some nations (I am thinking about Germany in  
>> incidents at the University of  Washington and other places.  Can  
>> we really say that no one would be put at risk by allowing their  
>> location to be tracked in real time by an unauthorized person?    
>> I’m aware of quite a few people whose lives could be put at risk by  
>> something like this.
>>
>>  Marc Linsner said:
>>
>> would support this, this solution will typically not be  
>> applicable.  While most switches support LLDP today, access points  
>> typically do not and therefore a solution may be desired which  
>> applies to both wired and wireless.
>>
>> relates each switch port to the location of the wall jack or area  
>> of coverage of the wireless access point to which that port is  
>> environment where anybody cares or is in any way at risk if a  
>> In this particular trust arrangement, it’s acceptable for the LIS  
>> to return the location to the requester. This is a real situation;  
>> not just a hypothetical one.
>>