RE: [Geopriv] Location signing daydream

"Thomson, Martin" <Martin.Thomson@andrew.com> Wed, 14 March 2007 22:18 UTC

Return-path: <geopriv-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRbne-0002lq-KM; Wed, 14 Mar 2007 18:18:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRbne-0002lZ-BE for geopriv@ietf.org; Wed, 14 Mar 2007 18:18:26 -0400
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRbnc-0008Rk-Jk for geopriv@ietf.org; Wed, 14 Mar 2007 18:18:26 -0400
X-SEF-Processed: 5_0_0_910__2007_03_14_17_24_21
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 14 Mar 2007 17:24:21 -0500
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 17:18:22 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Geopriv] Location signing daydream
Date: Wed, 14 Mar 2007 17:18:19 -0500
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF1029A7AE1@AHQEX1.andrew.com>
In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA031B2A06@crexc41p>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] Location signing daydream
Thread-Index: AcdmO2ddEanWVaepTbSE5Q0MzabcGQAJYZaAAAhA+LA=
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Stark, Barbara" <Barbara.Stark@BellSouth.com>, Richard Barnes <rbarnes@bbn.com>, GEOPRIV <geopriv@ietf.org>, Matt Lepinski <mlepinski@bbn.com>
X-OriginalArrivalTime: 14 Mar 2007 22:18:22.0185 (UTC) FILETIME=[AD430590:01C76686]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Cc:
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1557708518=="
Errors-To: geopriv-bounces@ietf.org

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.

> -----Original Message-----
> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]
> Sent: Thursday, 15 March 2007 4:50 AM
> To: Richard Barnes; GEOPRIV; Matt Lepinski
> Subject: RE: [Geopriv] Location signing daydream
> 
> 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:rbarnes@bbn.com]
> Sent: Wednesday, March 14, 2007 9:19 AM
> To: 'GEOPRIV'; Matt Lepinski
> Subject: [Geopriv] Location signing daydream
> 
> 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
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> *****
> 
> 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
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv