Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C953A6AF0 for ; Sun, 8 Nov 2009 21:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5VzYbt27vYm for ; Sun, 8 Nov 2009 21:33:27 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1F5DF3A68FA for ; Sun, 8 Nov 2009 21:33:25 -0800 (PST) Received: from [128.89.252.75] (helo=host-16-79.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1N7Msv-0002hF-AF; Mon, 09 Nov 2009 00:33:50 -0500 Message-Id: From: Richard Barnes To: Richard Barnes In-Reply-To: <3B251C9E-AA57-4335-814F-141C7F90B792@bbn.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2-264751945 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 14:33:45 +0900 References: <8B0A9FCBB9832F43971E38010638454F0F2E4CE7@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F0F2E4E12@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F0F2E4E2A@SISPE7MB1.commscope.com> <3B251C9E-AA57-4335-814F-141C7F90B792@bbn.com> X-Mailer: Apple Mail (2.936) Cc: "geopriv@ietf.org" , "Dawson, Martin" , "Thomson, Martin" Subject: Re: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:33:30 -0000 --Apple-Mail-2-264751945 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable James pointed out that there's a mistake in step 2 below, since the =20 LIS isn't going to use the client IP in a third party query. Likewise =20= 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 =20 > 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 =20 > authorized to request that identifier, then use the client IP with =20 > the identifier to determine location and return it > 3. If the LIS can validate that the identifier belongs to the =20 > client, then use the client IP with the identifier to determine =20 > location and return it > 4. If neither of the above two conditions applies, return the =20 > client's own location, or nothing. > > In other words: > var returnedLocation; > var idExt =3D heldRequest.getIdentityExtension(); > var clientIP =3D heldRequest.getRemoteAddress(); > if ( scenarioSpecificOwnershipValidation(clientIP, idExt) || =20 > applicationLevelAuthorization(clientIP, idExt) ) > { > return locationFromIPandIdExt(clientIP, idExt); > } > else > { > return locationFromIP(clientIP); > } > > 1. In principle, the LIS doesn't need access to the identifier in =20 > order to authenticate it (like with passwords, where the server =20 > stores a hash) (ignoring whether this happens in practice) > 2. The above process allows the LIS to make use of the identity =20 > extension without allowing any unauthorized third parties to access =20= > 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 =96 such things are =20 >> important in understanding the decisions that people make with =20 >> respect to policy. Being able to recognize that you are making a =20 >> policy decision is the first part in then understanding the =20 >> implications of that decision. >> >> If the LIS can determine that the requester and target are the same =20= >> =96 to its satisfaction, and I wont define what that means ;) =96 = then =20 >> it can use LCP policy; otherwise the security of the system demands =20= >> that it operate on another policy. That is the crux of Cullen=92s =20= >> complaint. However, if no such alternative policy exists, then it =20= >> cannot provide location. That=92s what the draft says. >> >> --Martin >> >> From: Dawson, Martin >> Sent: Monday, 9 November 2009 1:53 PM >> To: Thomson, Martin; Bernard Aboba; fluffy@cisco.com; =20 >> geopriv@ietf.org >> Subject: RE: [Geopriv] Serious concerns about security of draft-=20 >> ietf-geopriv-held-identity-extensions >> >> Well sure =96 which is to say =93it=92s all semantic fluff=94. >> >> The device is asking for its own location =96 and providing an =20 >> identity value that will help with that process. I haven=92t seen the = =20 >> actual mathematical proof that says that isn=92t LCP but=85 sure=85 = I=92ll =20 >> take your word for it. There are certainly rule makers at play =20 >> somewhere. >> >> Cheers, >> Martin >> >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On =20= >> Behalf Of Thomson, Martin >> Sent: Monday, 9 November 2009 9:59 AM >> To: Bernard Aboba; fluffy@cisco.com; geopriv@ietf.org >> Subject: Re: [Geopriv] Serious concerns about security of draft-=20 >> ietf-geopriv-held-identity-extensions >> >> That is, these scenarios really are third party request scenarios =20 >> and each require explicit policy. What that conclusion, I see no =20 >> issue. >> >> Martin, your scenario is simply not =93LCP=94. If the enterprise =20 >> decides that all hosts in the network can access location =20 >> information for all other hosts, then they act as Rule Maker when =20 >> allowing this. While some of us may disagree with this policy, =20 >> that is their prerogative as Rule Maker (as long another more =20 >> powerful Rule Maker prevents it, like a legislator). >> >> --Martin >> >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On =20= >> Behalf Of Bernard Aboba >> Sent: Monday, 9 November 2009 6:04 AM >> To: fluffy@cisco.com; geopriv@ietf.org >> Subject: Re: [Geopriv] Serious concerns about security of draft-=20 >> ietf-geopriv-held-identity-extensions >> >> Is it really necessary to require that "trust extend to all hosts" =20= >> in order to use a MAC address as an identifier? If that is really =20= >> the requirement (personally, I don't think it needs to be), then =20 >> I'd agree with Cullen that this work is outside the charter of =20 >> GEOPRIV WG. >> >> In some of the architectures discussed in IEEE 802 Emergency =20 >> Services study group, the LIS is located on the emergency services =20= >> VLAN, as are the emergency callers. So the LIS can compare the =20 >> source MAC address of the requester to the MAC address identifier =20 >> in the request. >> >> There are also scenarios where the client can infer its own =20 >> location based on receiving information on the location of =20 >> landmarks such as switch ports or access points. This already =20 >> supported with LLDP-MED or IEEE 802.11k. Why shouldn't it also be =20= >> possible with HELD? Here requests are only answered if the MAC =20 >> address being requested corresponds to a landmark; unauthenticated =20= >> queries for the MAC addresses of other hosts are denied. >> >> If one of the above scenarios doesn't hold, then the query needs to =20= >> be authenticated, so that the LIS can decide whether the requester =20= >> is authorized to receive a response. >> >> >> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] >> Sent: Monday, 9 November 2009 5:40 AM >> To: Dawson, Martin; fluffy@cisco.com; geopriv@ietf.org >> Subject: RE: [Geopriv] Serious concerns about security of draft-=20 >> ietf-geopriv-held-identity-extensions >> >> In the scenario given, is it really true that =93anybody cares or is =20= >> in any way at risk if a client offers a MAC address that isn=92t its = =20 >> own=94? >> [[MCD]] It is =96 and that=92s up to the owner and users of the = network =20 >> to decide. If it wasn=92t =96 i.e. trust does not extend to all hosts = =96 =20 >> then it would not be appropriate for a LIS serving such an =20 >> environment to provide location based on proffered MAC address =20 >> alone. I can consider the events you mention; and conclude that =20 >> you=92re describing a different scenario. >> >> My understanding is that providing blanket access to the geographic =20= >> location of any employee without authorization would violate =20 >> privacy laws within some nations (I am thinking about Germany in =20 >> particular). So I=92m aware of a number of enterprise Privacy =20 >> officers who care quite a bit about this. >> >> As to whether someone is at risk, consider recent violent stalking =20= >> incidents at the University of Washington and other places. Can =20 >> we really say that no one would be put at risk by allowing their =20 >> location to be tracked in real time by an unauthorized person? =20 >> I=92m aware of quite a few people whose lives could be put at risk by = =20 >> something like this. >> >> Marc Linsner said: >> >> =93I find it very interesting that the IT department embraces the new = =20 >> functionality of providing location to network clients but refuses =20= >> to implement the tools to get the job done. Maybe they should look =20= >> at a LLDP-MED solution.=94 >> >> I know quite a few IT departments that have no plans to implement =20 >> either DHCP or LLDP-MED. Most endpoints in the enterprise do not =20= >> support DHCP location today, so even if IT has a DHCP server that =20 >> would support this, this solution will typically not be =20 >> applicable. While most switches support LLDP today, access points =20= >> typically do not and therefore a solution may be desired which =20 >> applies to both wired and wireless. >> >> In contrast, HELD offers the potential for use on both wired and =20 >> wireless media without any required changes to system-level =20 >> components. >> >> >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On =20= >> Behalf Of Dawson, Martin >> Sent: Sunday, November 08, 2009 12:00 AM >> To: fluffy@cisco.com; geopriv@ietf.org >> Subject: Re: [Geopriv] Serious concerns about security of draft-=20 >> 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 =20= >> client devices to my LIS. My LIS has access to the bridge MIBs on =20 >> all the switches in the building(s) and it has the wiremap that =20 >> relates each switch port to the location of the wall jack or area =20 >> of coverage of the wireless access point to which that port is =20 >> connected. So =96 given a MAC address, the LIS can determine the =20 >> associated switch/port and corresponding location by performing the =20= >> bridge MIB query on the switches followed by a wiremap look up. >> >> In this network the DHCP implementation is limited; it doesn=92t =20 >> support the DHCP lease query for example=85 and the IT department =20 >> refuses to change or permit it to be patched to support the =20 >> functionality. So, I=92m stuck, not being able to translate the IP =20= >> address of my requesting clients into the corresponding MAC address =20= >> that allows me to provide them with location. >> >> Now there are absolutely no interesting scenarios in this =20 >> environment where anybody cares or is in any way at risk if a =20 >> client offers a MAC address that isn=92t its own. It=92s simply not a = =20 >> problem. >> >> In this particular trust arrangement, it=92s acceptable for the LIS =20= >> to return the location to the requester. This is a real situation; =20= >> not just a hypothetical one. >> >> Trust always involves nominating where risk is considered =20 >> acceptable. Even if the DHCP server wasn=92t so =93challenged=94, the = LIS =20 >> still has to trust the information acquired from it. In principle =20 >> the DHCP server could be compromised=85 or have devious intent. In =20= >> order to obviate this concern, the trust arrangement has to =20 >> encompass the DHCP server as well. >> >> Cheers, >> Martin >> >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On =20= >> Behalf Of Bernard Aboba >> Sent: Sunday, 8 November 2009 4:38 PM >> To: fluffy@cisco.com; geopriv@ietf.org >> Subject: Re: [Geopriv] Serious concerns about security of draft-=20 >> ietf-geopriv-held-identity-extensions >> >> We've had some discussion on this topic before. The answer =20 >> probably involves >> one or more of the following: >> >> 1. Use within an architecture (such as that being discussed in the =20= >> 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 =20 >> requested >> is the same as the originator of the request. >> >> 2. Use within an architecture (such as WiMAX or 802.1ar) in the =20 >> HELD server >> could potentially verify that the MAC address being requested =20 >> corresponds >> to the MAC address in the client certificate, and that the client =20 >> certificate >> chains to a pre-established trust anchor. >> >> 3. Where the MAC being requested cannot be verified, the LIS could =20= >> only provide >> responses to queries for a set of pre-arranged MAC addresses >> for whom location is already made publicly available via existing =20 >> 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: fluffy@cisco.com >> > Date: Sun, 8 Nov 2009 13:28:23 +0900 >> > To: geopriv@ietf.org >> > Subject: [Geopriv] Serious concerns about security of draft-ietf-=20= >> geopriv-held-identity-extensions >> > >> > >> > I really hope we get some discussion on this at this meeting. =20 >> 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 =20 >> server >> > know if it should answer this or not? If it has an IP to MAC =20 >> 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 =20= >> 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 =20 >> appropriate >> > for geopriv WG. >> > >> > Cullen >> > >> > >> > _______________________________________________ >> > Geopriv mailing list >> > Geopriv@ietf.org >> > https://www.ietf.org/mailman/listinfo/geopriv >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv --Apple-Mail-2-264751945 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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 =3D = heldRequest.getIdentityExtension();
var clientIP =3D = 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


<= /div>



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

Semantic fluff?  If you = like.
 
I was trying to be precise in = definitions =96 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 =96 to its satisfaction, and I wont = define what that means ;) =96 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=92s complaint.  However, if no such = alternative policy exists, then it cannot provide location.  That=92s= what the draft says.
 
 
From: Dawson, = Martin 
Sent: Monday, 9 November 2009 = 1:53 PM
To: Thomson, Martin; Bernard = Aboba; fluffy@cisco.com; geopriv@ietf.org
Subject: RE: [Geopriv] Serious = concerns about security of = draft-ietf-geopriv-held-identity-extensions
<= /div>
 
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Thomson, = Martin
Sent: Monday, 9 November 2009 = 9:59 AM
To: Bernard Aboba; fluffy@cisco.com; geopriv@ietf.org
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 =93LCP=94.  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).
 
 
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard = Aboba
Sent: Monday, 9 November 2009 = 6:04 AM
To: fluffy@cisco.com; geopriv@ietf.org
Subject: Re: [Geopriv] Serious = concerns about security of = draft-ietf-geopriv-held-identity-extensions
<= /div>
 

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:bernard_aboba@hotmail.com] 
Sent: Monday, 9 November 2009 = 5:40 AM
To: Dawson, Martin; fluffy@cisco.com; geopriv@ietf.org
Subject: RE: [Geopriv] Serious = concerns about security of = draft-ietf-geopriv-held-identity-extensions In = the scenario given, is it really true that =93anybody cares or is in any = way at risk if a client offers a MAC address that isn=92t  its = own=94?
[[MCD]] It is =96 and that=92s up to the owner and users = of the network to decide. If it wasn=92t =96 i.e. trust does not extend = to all hosts =96 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=92re = 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=92m 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=92m aware of quite a few people whose lives could = be put at risk by something like this.
 
 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.=94
 
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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Dawson, = Martin
Sent: Sunday, November 08, 2009 = 12:00 AM
To: fluffy@cisco.com; geopriv@ietf.org
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 =96 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.
 
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=92t its own. It=92s = simply not a problem.
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard = Aboba
Sent: Sunday, 8 November 2009 = 4:38 PM
To: fluffy@cisco.com; geopriv@ietf.org
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: fluffy@cisco.com
> Date: Sun, 8 Nov 2009 13:28:23 = +0900
> To: geopriv@ietf.org
> 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
> Geopriv@ietf.org
> Geopriv@ietf.org
https://www.ietf.= org/mailman/listinfo/geopriv

= = --Apple-Mail-2-264751945--