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

[Richard Barnes <[e-mail]>]

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:

> 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:
>
>> 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; [e-mail];  
>> [e-mail]
>> 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
>>
>> From: [e-mail] [mailto:[e-mail]] On  
>> Behalf Of Thomson, Martin
>> Sent: Monday, 9 November 2009 9:59 AM
>> To: Bernard Aboba; [e-mail]; [e-mail]
>> Subject: Re: [Geopriv] Serious concerns about security of draft- 
>> ietf-geopriv-held-identity-extensions
>>
>> 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: [e-mail] [mailto:[e-mail]] On  
>> Behalf Of Bernard Aboba
>> Sent: Monday, 9 November 2009 6:04 AM
>> To: [e-mail]; [e-mail]
>> Subject: Re: [Geopriv] Serious concerns about security of draft- 
>> ietf-geopriv-held-identity-extensions
>>
>> 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:[e-mail]]
>> Sent: Monday, 9 November 2009 5:40 AM
>> To: Dawson, Martin; [e-mail]; [e-mail]
>> 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: [e-mail] [mailto:[e-mail]] On  
>> Behalf Of Dawson, Martin
>> Sent: Sunday, November 08, 2009 12:00 AM
>> To: [e-mail]; [e-mail]
>> 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: [e-mail] [mailto:[e-mail]] On  
>> Behalf Of Bernard Aboba
>> Sent: Sunday, 8 November 2009 4:38 PM
>> To: [e-mail]; [e-mail]
>> 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
>> 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: [e-mail]
>> > Date: Sun, 8 Nov 2009 13:28:23 +0900
>> > To: [e-mail]
>> > Subject: [Geopriv] Serious concerns about security of draft-ietf- 
>> geopriv-held-identity-extensions
>> >
>> >
>> > 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>
>> >
>> >
>> > _______________________________________________
>> > Geopriv mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/geopriv
>> _______________________________________________
>> Geopriv mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geopriv