Subject: [Ecrit] Location hiding: another alternative

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 6 Jun 2007 09:08:58 -0400

Motivated by a side remark by Andy, here's another alternative that  
(I believe) avoids some of the architectural contortions of using the  
L7 LCP or DHCP as a LoST transport mechanism.

The basic idea is that we define a new location type, namely an  
opaque token. This token is specific to LoST, i.e., possession of the  
token can only be used to get a LoST result. This is logically  
somewhat similar to the "additional code" (CAtype 32) in DHCP-civic.  
This new location format can be returned by HELD, DHCP or any other  
location configuration protocol. Indeed, it could probably be added  
as another CAtype in DHCP-civic. The LIS provider decides on the  
token format, which could be a hashed IP address, some customer  
identity (for DSL) or even an encrypted civic/geo address, with the  
key known only to the ISP.

The client does what we have discussed for any other location format:  
It blindly copies the new location information into a LoST query.

The LoST resolver/server/proxy, operated by the ISP, runs some  
internal protocol to get the location information from the LIS. This  
is a private matter left to the ISP. With that information, the  
"proxy" constructs a normal LoST query, of whatever kind, and gets  
the result, which it returns to the original querier.

Since this token is local to a specific LoST server, the actual token  
returned would be a LoST URL, such as

lost:lost.isp.com/fav8z98fa

The VSP can perform URL verification using this token, if desired.

This mechanism has the advantage that it maintains the same  
architecture as without location hiding and avoids conflating the  
functionality of two protocols. It doesn't need any special LbyR  
mechanisms with the attendant access issues, as the LoST URL serves  
only one purpose.

It's not perfect, in that the VSP verification relies on the VSP  
trusting the ISP lookup results, but it is likely "good enough" for  
fraud prevention.

This requires no fundamental changes to LoST and thus can (and should  
be) done later. Thus, I believe this is in the spirit of Andy's  
compromise proposal, but illustrates that there's more than one way  
to do this beyond Solution 1.

Henning

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 06 Jun 2007 11:22:14 -0500

Henning

Perhaps I'm not reading this correctly, but as you have offered this 
new token as part of a CAType, to be used for emergency calling, 
wouldn't that mean RFC 3825 (currently without the ability to simply 
add a token to it) would no longer function as this alternative 
expects emergency calling to?

I know a great number of folks are biased towards Civic formats in 
DHCP, but nothing to date has actively prevented the Geo format from 
working.  Does this alternative do that?

Again, I may be missing something - or combining something I 
shouldn't be to get to this conclusion.

Also, what happens to this alternative when location is measured by 
the endpoint itself (like a GPS chip), or even manual config?

Just curious how these factor in...

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 6 Jun 2007 13:22:56 -0400

On Jun 6, 2007, at 12:22 PM, James M. Polk wrote:

> Henning
>
> Perhaps I'm not reading this correctly, but as you have offered  
> this new token as part of a CAType, to be used for emergency  
> calling, wouldn't that mean RFC 3825 (currently without the ability  
> to simply add a token to it) would no longer function as this  
> alternative expects emergency calling to?
>

James,

the whole discussion only applies to location hiding cases. Thus,  
3825 and any other mechanism can and should be used to convey  
location information. I'm hoping that location hiding remains the  
exception, used, if at all, mainly for residential DSL (and cable),  
but that's a separate discussion.

I have not spent a whole lot of time thinking of whether such a token/ 
LoST URL should be conveyed in DHCP-civic or in a new DHCP option (in  
addition to L7 LCP). I can make a case for either, but it seems  
secondary at this point.

> DHCP, but nothing to date has actively prevented the Geo format  
> from working.  Does this alternative do that?

I don't understand. The whole point of location hiding is that you  
want to convey neither (accurate) geo nor civic. You could obviously  
combine "fuzzed" location (Solution 1) with this approach, if you  
desire. They are not mutually exclusive.

> the endpoint itself (like a GPS chip), or even manual config?

Nothing special happens. Again, this is only about the location  
hiding case, as indicated by the subject line of my message. If a  
device has GPS data, the ISP can't hide that location from their  
customer. (This is why I believe, by the way, that location hiding  
will be largely pointless for wireless since most above-$50 cell  
phones will have GPS, if only to allow navigation to work, as well as  
other consumer features, such as annotating cell phone pictures with  
location information.)

The whole point is that the approach looks, to the end device, pretty  
much the same either way, whether location is revealed or hidden.

> Just curious how these factor in...

I have to admit that I'm confused by your question. You seem to have  
a somewhat different mental picture of the whole system. Let me know  
if the attempt at explanation above missed your question.

Henning

---

From: Richard Barnes <[email-masked]>
Date: Wed, 06 Jun 2007 13:58:32 -0400

Henning,

Just to keep things organized, isn't this essentially Solution 2 from 
our earlier discussion?
<http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHiding>

The "token" is a reference that indicates a LoST server that's 
authorized to dereference it.  You could just as well have a regular 
reference, and some ancillary information alongside it in the LCP & 
signaling that specifies which LoST server to use it with.  I agree that 
this is an architecturally cleaner proposal than many, and worth 
investigating, especially in the context of Andy's compromise proposal.

--Richard

Henning Schulzrinne wrote:
> Motivated by a side remark by Andy, here's another alternative that (I 
> believe) avoids some of the architectural contortions of using the L7 
> LCP or DHCP as a LoST transport mechanism.
> 
> The basic idea is that we define a new location type, namely an opaque 
> token. This token is specific to LoST, i.e., possession of the token can 
> only be used to get a LoST result. This is logically somewhat similar to 
> the "additional code" (CAtype 32) in DHCP-civic. This new location 
> format can be returned by HELD, DHCP or any other location configuration 
> protocol. Indeed, it could probably be added as another CAtype in 
> DHCP-civic. The LIS provider decides on the token format, which could be 
> a hashed IP address, some customer identity (for DSL) or even an 
> encrypted civic/geo address, with the key known only to the ISP.
> 
> The client does what we have discussed for any other location format: It 
> blindly copies the new location information into a LoST query.
> 
> The LoST resolver/server/proxy, operated by the ISP, runs some internal 
> protocol to get the location information from the LIS. This is a private 
> matter left to the ISP. With that information, the "proxy" constructs a 
> normal LoST query, of whatever kind, and gets the result, which it 
> returns to the original querier.
> 
> This mechanism has the advantage that it maintains the same architecture 
> as without location hiding and avoids conflating the functionality of 
> two protocols. It doesn't need any special LbyR mechanisms with the 
> attendant access issues, as the LoST URL serves only one purpose.
> 
> compromise proposal, but illustrates that there's more than one way to 
> do this beyond Solution 1.
> 
> Henning
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 06 Jun 2007 14:07:13 -0500

At 12:22 PM 6/6/2007, Henning Schulzrinne wrote:

>a somewhat different mental picture of the whole system.

I think it's more of a case of me attempting to determine if there 
are any new (mental) pictures happening.  I have, in the past, missed 
a 5 or 10 degree course change within this (emergency services 
focused) group that over time, becomes not-so-subtle. I was asking 
early in this discussion (of the new alternative) if this is one such 
case.  Thank you for your explanation!

>Let me know if the attempt at explanation above missed your question.

I think you've confirmed that to me this is not new, and is in many 
ways rather pointless to work towards - since there are so many ways 
right in front of us around it.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 6 Jun 2007 21:05:33 -0400

On Jun 6, 2007, at 1:58 PM, Richard Barnes wrote:

> Henning,
>
> Just to keep things organized, isn't this essentially Solution 2  
> from our earlier discussion?

They are related, but not the same. Among other differences, the  
solution proposed ("4") avoids the need for *every* LoST server to  
resolve references (only the ISP-LIS would deal with these) and  
avoids having to return a rough location or having special trust  
relationships between ISP/LIS and VSP/LoST server.

Since it is unrealistic to assume that every LoST server has a trust  
relationship with every LIS, the LbyR solution imposes some  
uncertainty since the user can never know which LoST server will  
actually work.

The objection to other solutions is the need to maintain rough  
location information; standard location references don't avoid this  
problem unless there's this unscalable trust relationship.

> authorized to dereference it.  You could just as well have a  
> regular reference, and some ancillary information alongside it in  
> the LCP & signaling that specifies which LoST server to use it  
> with.  I agree that this is an architecturally cleaner proposal  
> than many, and worth investigating, especially in the context of  
> Andy's compromise proposal.

On the negative side, my proposal requires the end system to use a  
specific LoST server (which is the same as in Proposal 2,  
effectively) and has somewhat weaker verification properties for PSAP  
URLs (where Proposal 2 has none).

For that reason, I continue to believe that solution 1 is a better  
trade-off and thus support Andy's compromise. This new proposal just  
provides a different set of trade-offs, closer to those in Proposal  
3, without some of the architectural warts of tunneling LoST.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 09 Jun 2007 10:05:19 +0200

Hi Henning,

thank you for the proposal.

If the emergency call to the VSP contains a PSAP URI and this token then 
the verification at the VSP would be performed as follows:

* VSP puts the token into a FindService query

* The VSP authenticates the VSP's LoST server
   - If the VSP knows the ASP/ISP then lost.isp.com can be assumed to 
belong to isp.com.
   - If the VSP does not know the ASP/ISP then there is a problem 
because an adversary can just obtain a certificate for a lost.isp.com 
and claim it is running a LoST server. I think that there is a missing 
piece here.**

* When LoST returns the FindServiceResponse with the PSAP URI to the VSP 
then it can be compared with the one provided by the end host. If they 
match then the call is forwarded. If they do not match the PSAP URI that 
was recently fetched is used for routing the emergency call and a log 
entry regarding the mismatch is created (since this might potentially an 
attempt to cheat by the user.)
 
**: Even if we make use of the registry for access networks, as 
established with RADIUS GEOPRIV, then the problem is not solved since 
the rights to use a given realm name from the operator namespace "REALM" 
are obtained coincident with acquiring the rights to use a particular 
Fully Qualified Domain Name (FQDN). Also, RADIUS GEOPRIV does not say 
(intentionally) anything about the fact that this access network 
identity might be associated with a particular type of certificate.

Ciao
Hannes

Henning Schulzrinne wrote:
> token. This token is specific to LoST, i.e., possession of the token 
> can only be used to get a LoST result. This is logically somewhat 
> similar to the "additional code" (CAtype 32) in DHCP-civic. This new 
> location format can be returned by HELD, DHCP or any other location 
> configuration protocol. Indeed, it could probably be added as another 
> CAtype in DHCP-civic. The LIS provider decides on the token format, 
> which could be a hashed IP address, some customer identity (for DSL) 
> or even an encrypted civic/geo address, with the key known only to the 
> ISP.
>
> "proxy" constructs a normal LoST query, of whatever kind, and gets the 
> result, which it returns to the original querier.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 9 Jun 2007 09:37:14 -0400

On Jun 9, 2007, at 4:05 AM, Hannes Tschofenig wrote:

> because an adversary can just obtain a certificate for a  
> lost.isp.com and claim it is running a LoST server. I think that  
> there is a missing piece here.**
>
> established with RADIUS GEOPRIV, then the problem is not solved  
> since the rights to use a given realm name from the operator  
> namespace "REALM" are obtained coincident with acquiring the rights  
> to use a particular Fully Qualified Domain Name (FQDN). Also,  
> RADIUS GEOPRIV does not say (intentionally) anything about the fact  
> that this access network identity might be associated with a  
> particular type of certificate.

Indeed, this is the problem I alluded to. This is one of the reasons  
I still consider the rough-location approach to be preferable.

That said, getting a certificate exposes a fraudster to significant  
risk of discovery, reducing the incentive.

Also, I think, in general, we need to think about security (for  
location signing, caller verification and URI verification) as being  
more probabilistic than absolute. In this case, a combination of

- unknown ISP
- E.164 address (since the VSP doesn't much care about routing calls  
to sip:[email-masked], since those calls don't generally incur  
costs)
- E.164 number that hasn't been seen before in a legitimate LoST  
resolution
- purported ISP is in a different country than the number dialed

will trigger a fraud alert. If a single VSP subscriber does more than  
one of these, maybe it's time for the fraud control department to  
call that number and find out if this really is a PSAP.

There is another solution that we have discussed before for different  
reasons, namely that the LoST <mapping> is digitally signed by a PSAP  
authority. This would avoid the problem altogether.