Subject: [Geopriv] Location signing daydream

From: Richard Barnes <[email-masked]>
Date: Wed, 14 Mar 2007 09:18:57 -0400

So I got to daydreaming about location signing systems yesterday, and 
came up with an idea:

<figure>

                +-------+    ID(UA;LIS), ID(UA;VSP) 

                |       |---------------------------+
                |  VSP  |                           |
                |       |<----------------------+   |
                +-------+        SLO1           |   |
                 ^    |                         |   |
                 |    |                         |   |
          ID(LIS)|    |SLO2                     |   |
       ID(UA;LIS)|    |                         |   |
                 |    V                         |   V
                +------+                      +-------+
       ID(LIS)  |      |        ID(VSP)       |       |
LCP----------->|  UA  |--------------------->|  LIS  |
                |      |      ID(UA;VSP)      |       |
                +------+                      +-------+
                    |
                    |         +------+
                SLO3|         |      |
                    +-------->|  LR  |
                              |      |
                              +------+
<legend>
ID(A;B) = identifier of A in the context of B
SLO* = signed location objects
</legend>
</figure>

Generating a signed LO (SLO):
1. UA gets the ID of the LIS via an LCP
2. UA notifies the LIS that its VSP will be contacting it
3. UA tells its VSP the ID of its LIS, and the identifier that 
identifies it to that LIS
4. VSP requests users location using provided identity
5. LIS returns a signed object of the form
       SLO1 = LIS{ ID(UA;LIS), Location Information}
6. VSP returns a signed object of the form
       SLO2 = VSP{ ID(UA;VSP), SLO1 }
7. UA can optionally construct a third signed object of the form
       SLO3 = UA{ rules, SLO2 }
* NB: VSP role could be played by a trusted module on the UA device.

Semantics:
-- LIS signature asserts ID(UA;LIS) at specified location
-- VSP signature asserts ID(UA;VSP) and ID(UA;LIS) identify the same entity
-- UA signature binds rules to rest of LO

Assumptions:
1. UA authenticated to VSP using ID(UA;VSP)
    (e.g., using SIP digest auth)
2. UA authenticated to LIS using ID(UA;LIS)
    (e.g., via physical / MAC layer authentication)
3. For any other UA' under the same LIS
4. LIS and VSP are trusted to work properly
5. Location is determined by the LIS and ID(UA;LIS)

Security properties:
1. It's hard for the UA to spoof either identity:
-- If it lies to the LIS about ID(UA;VSP), then the one sent by the VSP 
in its request won't match up
-- If it lies to the VSP about ID(UA;LIS), then the one in the VSP's 
request won't match the UA that notified the LIS.
2. Because, in particular, the LIS ID can't be spoofed, location can't 
be spoofed.

Remaining attacks:
1. This would allow two attackers served by the same VSP and LIS to 
exchange locations by swapping the ID(*;VSP) values sent to the LIS and 
the ID(*;LIS) values sent to the VSP.  This can be mitigated, e.g., by 
restricting the coverage area of any particular LIS.

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Mar 2007 09:16:19 -0500

Very nice Richard - very clever.

I assume LR is location recipient?

I think this adds two things:

* It eliminates the one-off replay of a location object from a remote
device (i.e. drone is present in the access, retrieves location,
provides it to remote third party who makes single call using that
object)

* It includes a signed voice service subscriber identity in the signed
package (I think it's more than a location object by now - since VSP
subscriber identity isn't a location attribute).

For a non-VSP scenario, the VSP collapses into the UA (they are their
own VSP) and this reduces to obtaining the signed location object from
the LIS with a device provided identity.

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Thursday, 15 March 2007 12:19 AM
To: 'GEOPRIV'; Matt Lepinski
Subject: [Geopriv] Location signing daydream

<figure>

Semantics:
-- LIS signature asserts ID(UA;LIS) at specified location
-- VSP signature asserts ID(UA;VSP) and ID(UA;LIS) identify the same
entity
-- UA signature binds rules to rest of LO

Assumptions:

Security properties:

Remaining attacks:

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 14 Mar 2007 13:50:19 -0400

It's an interesting proposal, but I don't think VSPs can be trusted,
necessarily. The big ones can probably be trusted (with regard to this),
but I think it's dangerous to require people to use "well-known and
trusted" VSPs. And without such a requirement, it will be very easy to
create an "untrustworthy" VSP. It's also possible to use no VSP at all,
unless there's some intention to prevent that?
Barbara 

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 9:19 AM
To: 'GEOPRIV'; Matt Lepinski
Subject: [Geopriv] Location signing daydream

<figure>

Generating a signed LO (SLO):
1. UA gets the ID of the LIS via an LCP
2. UA notifies the LIS that its VSP will be contacting it 3. UA tells
its VSP the ID of its LIS, and the identifier that identifies it to that
LIS 4. VSP requests users location using provided identity 5. LIS
returns a signed object of the form
       SLO1 = LIS{ ID(UA;LIS), Location Information} 6. VSP returns a
signed object of the form
       SLO2 = VSP{ ID(UA;VSP), SLO1 }
7. UA can optionally construct a third signed object of the form
       SLO3 = UA{ rules, SLO2 }
* NB: VSP role could be played by a trusted module on the UA device.

Semantics:

Assumptions:
1. UA authenticated to VSP using ID(UA;VSP)
    (e.g., using SIP digest auth)
2. UA authenticated to LIS using ID(UA;LIS)
    (e.g., via physical / MAC layer authentication) 3. For any other UA'
under the same LIS 4. LIS and VSP are trusted to work properly 5.
Location is determined by the LIS and ID(UA;LIS)

Security properties:

Remaining attacks:

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 14 Mar 2007 17:18:19 -0500

I like the concept, it's linkage of the identifiers ID(UA;VSP) and ID(UA;LIS) is novel.  Note that demonstrates use of location by reference by the VSP.

I don't think that this has significant advantages over the methods proposed in:

<http://tools.ietf.org/html/draft-thomson-geopriv-location-dependability-00>
(which is in turn based on the idea presented in the l7-lcp-ps draft)

Your proposal requires the VSP to perform linkage between ID(UA;VSP) and ID(UA;LIS).  In many senses, VSP is not the right term for this -- the VSP is acting as an Identity Provider in the SAML sense.

The other proposal doesn't require VSP interaction:

1. UA discovers LIS (I don't think that the LCP is the right term for this step BTW)
2. The UA requests a signed LO.
	SLO = Sig { ID(UA;LIS), f{ ID(UA;VSP) }, LI, ... }
3. The UA uses that signed LO, authenticating with ID(UA;VSP) when it is used.

Your proposal requires that the UA provide its identity to the LIS.  Some may perceive that as a problem; it was cited as such.  While the above can be based on providing the identity (i.e. f{} is unity), a hash function provides adequate linkage between ID(UA;VSP).

Note that the UA would have to authenticate using ID(UA;VSP) in either proposal, that being the identity that is known.

Cheers,
Martin

p.s. I like the notation!  Very useful.

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Thursday, 15 March 2007 4:50 AM
> To: Richard Barnes; GEOPRIV; Matt Lepinski
> Subject: RE: [Geopriv] Location signing daydream
> 
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If
> you received this in error, please contact the sender and delete the
> material from all computers. GA622
> 
> 
>