Subject: [Geopriv] Location Integrity

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 06:00:33 -0400

I've proposed this in a couple of obtuse emails to the list, but after
asking a few, it appears it hasn't been understood.  I know, a draft is
needed, but for the discussion on tomorrow's agenda, I thought I would
reiterate here.

It appears there is large support for using certificates to establish a
trust between the Location Recipient and the author of the location
information.  This is possible today using a couple of different methods.
One that I'm not sure is clear is using the provided-by within the pidf-lo,
populating with a random L-by-R uri, then requesting TLS is employed while
dereferencing.  The trust is gained/denied during the dereference
operation/TLS connection establishment.  If the location value returned by
the dereference matches the L-by-V provided initially, you now have the same
level of trust that is gained with the proposed location signing.

A few of advantages of this method:

1) No IETF work required.  Faster time to market.  Everything is in-place to
do this today.  Provided-by = pres:[email-masked]

2) L-by-V is used in the SIP invite, intermediate routing proxies don't need
to dereference anything for routing, they simply use the by-value data.

3) The dereference operation provides multiple attributes: establishes the
trust via certificates, and sets up a presence subscribe/notify for tracking
a mobile client (corresponding to the rebid process deployed in NA PSAPs
today).

I'm sure there are downsides that I'm missing, please point them out.  The
obvious one is the extra step required to get the certificate initially, but
if the AOR of major providers is somewhat static and well known by PSAPs as
claimed by some, only comparison of the location data is needed, a process
that is probably prudent prior to dispatch anyway.

-Marc-

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 21 Mar 2007 05:12:34 -0500

Marc,

I will assert that the LIS providing the location by-reference still
requires a VESA certificate or the like in order for this model to
provide the same degree of trust as the signatures that have been
described. Consequently the mechanism you describe has at least the same
administrative overhead with regards to certificate management. So that
part solves nothing.

Secondly, this solution does not solve the total collusion problem of
two people swapping identity information around the place, so it doesn't
solve anything more than what has been described in the Thomson location
dependability draft. It does however, as you point out, now require a
location reference mechanism over and above the location by value
already being sent in order to provide a questionable degree a surety.
In case you hadn't guessed I don't like this proposal as it provides
nothing extra except for processing cycles.

Cheers
James

> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, 21 March 2007 9:01 PM
> To: [email-masked]
> Subject: [Geopriv] Location Integrity
> 
> One that I'm not sure is clear is using the provided-by within the
pidf-
> lo,
> the dereference matches the L-by-V provided initially, you now have
the
> same
> 1) No IETF work required.  Faster time to market.  Everything is
in-place
> to
> 2) L-by-V is used in the SIP invite, intermediate routing proxies
don't
> need
> obvious one is the extra step required to get the certificate
initially,
> but
> if the AOR of major providers is somewhat static and well known by
PSAPs
> as

------------------------------------------------------------------------------------------------
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: Andrew Newton <[email-masked]>
Date: Wed, 21 Mar 2007 06:57:43 -0400

Marc,

Thanks for using the correct terminology.  As outlined in RFC 3552,  
integrity is the desired property and requirement.  Signing is one  
method of accomplishing this.

> nothing extra except for processing cycles.

I don't think any proposal using XML D-Sig has any bragging rights  
about being efficient or less complex.

Marc's proposal is simpler and requires little standardization  
effort.  And the act of the dereference provides an opportunity to  
thwart replay attacks.

I do have concerns though.  It relies on L-by-V, which might be  
problematic with the state of multiple MIME bodies being what they  
are today.  An L-by-R in an INVITE does seem to have the advantage of  
being retrofitted into networks and software more easily.

Additionally, if the dereference act provides the trust, then why not  
just use L-by-R in the INVITE?  I must be missing something.

Finally, given the description of <provided-by> in RFC 4119...  
especially the text about SubjectAltName and certificates, it might  
be wisest to create a new element for this purpose.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 07:49:01 -0400

James, 

> I will assert that the LIS providing the location 
> by-reference still requires a VESA certificate or the like in 
> order for this model to provide the same degree of trust as 
> the signatures that have been described. Consequently the 
> mechanism you describe has at least the same administrative 
> overhead with regards to certificate management. So that part 
> solves nothing.

Ageed, CA management is required.  This seems to be accepted by those
proposing the certificate trust model.  What I suggesting is a
different/faster-to-market mechanism to perform that same level of integrity
checking.  I still have reservations about the ROI from using this model,
you are asking to spend large amounts of public money to deploy/maintain
this mechanism.

I'm also amiss at the complete dismissal of other suggestions to satisfy the
requirement that have higher ROI, hence I think consensus on the requirement
is needed.    

> 
> Secondly, this solution does not solve the total collusion 
> problem of two people swapping identity information around 
> the place, so it doesn't solve anything more than what has 
> been described in the Thomson location dependability draft.

Like I said, faster time to market with parallel benefit.

> It does however, as you point out, now require a location 
> reference mechanism over and above the location by value 

Ack

> In case you hadn't guessed I don't like this proposal as it 
> provides nothing extra except for processing cycles.

I got that.

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 07:49:01 -0400

Andy,

Marc's proposal is simpler and requires little standardization effort. And
the act of the dereference provides an opportunity to thwart replay attacks.

As I stated earlier, I do believe an update on location between sip session
establishment and responder dispatch is going to become normal procedure.
If I'm right, location integrity is best performed closest to the time it
has high-value usage.

I do have concerns though. It relies on L-by-V, which might be problematic
with the state of multiple MIME bodies being what they are today. An L-by-R
in an INVITE does seem to have the advantage of being retrofitted into
networks and software more easily. 

OK, given my ignorance on this, I have no choice but to believe you.  Is
this insurmountable? 

Additionally, if the dereference act provides the trust, then why not just
use L-by-R in the INVITE? I must be missing something. 

I see a large advantage to having L-by-V in the invite for routing purposes.
I can't imagine the time will be available during a routing decision to
either derefernce nor chase trust relationships.  L-by-V is *required* for
routing, IMO.  Remember, we are already performing LoST queries during
routing.  Plus, the REAL requirement, which is still in dispute, is to not
waste PSAP resources by dispatching to false emergencies.  With that said,
there is time between call session establishment and dispatch of responders
to perform integrity checks on the location data.

Finally, given the description of <provided-by> in RFC 4119... especially
the text about SubjectAltName and certificates, it might be wisest to create
a new element for this purpose. 

I've accepted the realization that pidf-lo will be in turmoil/change for
some time, so I don't object to a new element.  With that said, there is
nothing stopping implementations that agree to using provided-by doing so
TODAY.  
 
-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 07:49:01 -0400

James, 

I'm also amiss at the comple  problematic with the state of multiple MIME bodies being what they are =
today.=20
  An L-by-R in an INVITE does seem to have the advantage of being =
retrofitted=20
  into networks and software more easily.<SPAN =
class=3D093280711-21032007><FONT=20
  face=3DArial color=3D#0000ff =
size=3D2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D093280711-21032007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>OK, given my ignorance on this, I have no choice but to believe =

you.&nbsp; Is this insurmountable?</FONT>&nbsp;</SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV>Additionally, if the dereference act provides the trust, then why =
not=20
  just use L-by-R in the INVITE? I must be missing something.<SPAN=20
  class=3D093280711-21032007><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D093280711-21032007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>I see a large advantage to having L-by-V in the invite for =
routing=20
purposes.&nbsp; I can't imagine the time will be available during a =
routing=20
decision to either derefernce nor chase trust relationships.&nbsp; =
L-by-V is=20
*required* for routing, IMO.&nbsp; Remember, we are already performing =
LoST=20
queries&nbsp;during routing. &nbsp;Plus, the REAL requirement, which is =
still in=20
dispute, is to not waste PSAP resources by dispatching to false=20
emergencies.&nbsp; With that said, there is time between&nbsp;call =
session=20
establishment and dispatch of&nbsp;responders to perform integrity =
checks on the=20
location data.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV>Finally, given the description of &lt;provided-by&gt; in RFC =
4119...=20
  especially the text about SubjectAltName and certificates, it might be =
wisest=20
  to create a new element for this purpose.<SPAN =
class=3D093280711-21032007><FONT=20
  face=3DArial color=3D#0000ff =
size=3D2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D093280711-21032007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>I've accepted the realization that pidf-lo will be in=20
turmoil/change&nbsp;for&nbsp;some time, so I&nbsp;don't object to a new=20
element.&nbsp; With that said, there is nothing&nbsp;stopping =
implementations=20
that agree to using provided-by doing so =
TODAY.&nbsp;</FONT>&nbsp;</SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D093280711-21032007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D093280711-21032007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>-Marc-</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_006B_01C76B8D.65067030--

--===============1371099490==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1371099490==--

te dismissal of other suggestions to satisfy the
requirement that have higher ROI, hence I think consensus on the requirement
is needed.    

Ack

I got that.

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 07:49:01 -0400

Andy,

 
-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Wed, 21 Mar 2007 13:08:32 +0100

If you're going to have the certificate infrastructure anyway, why not 
just make a PIDF-LO per Marc's proposal, drop it in an S/MIME container, 
and sign it?  There's no extra standardization, and you get integrity 
and origin authentication for both the by-value and by-reference locations.

This requires no additional standardization action, other than maybe a 
BCP describing this stuff.

--RB

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 08:15:28 -0400

Richard, 

> If you're going to have the certificate infrastructure 
> anyway, why not just make a PIDF-LO per Marc's proposal, drop 
> it in an S/MIME container, and sign it? 

Who is signing it at this point?  There is other information in the pidf-lo
than what the access network LIS provides.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 21 Mar 2007 08:16:40 -0400

Leaving the detailed mechanism aside, I think there is value to  
differentiate between the CA function and the "trust" function.  
Creating a new special-purpose CA requires far more overhead, cost  
and complexity than stating that "Acme Corp, as certified by  
FalsiSign Inc, can be trusted to provide true location (or identity)  
information". FalsiSign's cert would be the normal HTTP or SIP cert,  
as applicable, already commercially available from many competing  
providers.

There are many ways to accomplish the protocol mechanics, including,  
but not limited to, transporting LOs in TLS when derefencing to  
including a verification reference in the LO. It would be helpful to  
explore these as opposed to simply reiterating the same "my sign way  
or the highway".

Henning

On Mar 21, 2007, at 6:12 AM, Winterbottom, James wrote:

>> 3) The dereference operation provides multiple attributes:  
>> establishes
> the

---

From: Richard Barnes <[email-masked]>
Date: Wed, 21 Mar 2007 13:40:07 +0100

Use the same key to sign it that the TLS cert attests.  That way, the 
same signer vouches for the PIDF-LO and the LO resulting from the 
dereference.

--RB

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 08:56:09 -0400

Richard, 
> 
> Use the same key to sign it that the TLS cert attests.  That 
> way, the same signer vouches for the PIDF-LO and the LO 
> resulting from the dereference.

Huh?  Please provide state-machine-like steps showing what gets signed
when/where/who/why.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 21 Mar 2007 08:12:57 -0500

Hi Henning

I agree the two things you mention below are different - but I don't
understand what contribution the latter makes to location integrity. How
does a recipient know that Acme Corp is trusted?

I mean, if all you are saying is that the recipient may be comfortable
with recognizing a well-known and trusted brand as certified by Verisign
- then sure. Really, that is putting Verisign in the role of VESA with
the additional requirement on location recipients to maintain the list
of signers that they will trust for location integrity.

I don't think that's a sea change as far as proposals go... much the
same process and infrastructure is involved either way. Indeed, it would
be a reasonable option for some jurisdictions.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, 21 March 2007 11:17 PM
To: GEOPRIV WG
Subject: Re: [Geopriv] Location Integrity

Henning

On Mar 21, 2007, at 6:12 AM, Winterbottom, James wrote:

> ----------------------------------------------------------------------

> --------------------------
> ----------------------------------------------------------------------

> --------------------------
> [mf2]
>
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 21 Mar 2007 08:33:38 -0500

Hi all,

There have been a number of proposals that standard S/MIME covering the
whole PIDF-LO is an acceptable signature mechanism. I think Richard is
proposing that here.

I've mentioned before that I'm not comfortable that the LIS wants to
take responsibility - or to impose control over - every element in that
structure. Ideally it would just set and sign the parts that it
contributes. On that score, Marc, it sounds like we may be agreeing.

I'm not sure what the fuss is about with respect to Marc's general
proposal. I think that appropriate signing and CA validation on
dereferencing makes perfectly good sense when the end-consumer of the
location is also the dereferencer. A certificate exchange associated
with the dereferencing seems obviously quite satisfactory as far
offering equivalent surety about the integrity of the location
information (there's a second order issue with respect to checking
device uniqueness that I won't go into). And, finally, there's no issue
with respect to other parts of the PIDF-LO being able to be defined by
other entities - this is coming straight from the LIS so no other
entities are involved.

Having said all that, I don't think that all network topologies,
application policies, or use cases in general are going to be supported
if location integrity is only able to be communicated when the final
consumer is also a dereferencer. I think there are definitely scenarios
that will involve transmission by value through an intermediary. To that
end, I think there still needs to be a defined mechanism that involves
signing the actual value. As above, I'm not a big fan of just chucking
the whole PIDF-LO into an S/MIME bucket as being that defined mechanism.

So, while I don't object to Marc's proposal - I wouldn't agree that it
represents either a mutually exclusive or a solely adequate alternative
mechanism compared to signed value for location integrity. Perhaps as
Marc suggests it will offer the best time to market if the IETF take a
long time to establish a documented value signing mechanism. I just
think that mechanism is required eventually anyway.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 21 March 2007 11:15 PM
To: 'Richard Barnes'
Cc: [email-masked]
Subject: RE: [Geopriv] Location Integrity

Richard, 

> it in an S/MIME container, and sign it? 

Who is signing it at this point?  There is other information in the
pidf-lo
than what the access network LIS provides.

-Marc-

---

From: Greg Troxel <[email-masked]>
Date: Wed, 21 Mar 2007 09:39:48 -0400

information.

I've been lurking and not paying close attention, but I have a few
brief comments.  I realize you probably know a lot of what I'm saying,
but I'm erring on the side of saying too much since that seems more
likely to be helpful.

I'm uncomfortable when people use the word 'trust'.  That properly
refers to a human interaction where one entity has confidence in
another to behave reasonably.  Here, I think we're talking about
authenticity of data, or confidence that some particular piece of data
is accurate.  I have found that avoiding the word trust tends to
result in greater clarity as then people have to describe which piece
of data and what property they want it to have.  So I suggest that the
word trust be completely eliminated from discussions of protocols.

A signature on an object is very different from authentication of
transported data.

Certificates merely bind identities to public keys (identity
certificates) or record authorization (typically via names).  While
this is a tremendously useful building block, many details remain.

  One that I'm not sure is clear is using the provided-by within the
  pidf-lo, populating with a random L-by-R uri, then requesting TLS is
  employed while dereferencing.  The trust is gained/denied during the
  dereference operation/TLS connection establishment.  If the location
  value returned by the dereference matches the L-by-V provided
  initially, you now have the same level of trust that is gained with
  the proposed location signing.

In this case, it's necessary to be clear on what entity does TLS at
the webserver that fulfills the uri request.  That could well be
different than the entity that would have signed a location.  And, one
needs to authenticate that the uri is the right one, in order to
construct a proof that the result is correct (given reasonable and
documented assumptions).

Sorry if I'm causing trouble by stepping into this without knowing
enough details.

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 21 Mar 2007 14:45:40 +0100

If there's no correspondence required between the by-value and the 
by-reference locations, then this leads to an interesting situation:

-- Botnet operator seeds bots with a valid location URI
-- Bots make up bogus LOs within the target PSAP's service area
-- Bots make emergency calls with their generated LOs
-- All calls get routed to target PSAP
-- PSAP dereferences the URI, gets a cert that matches the domain

At this point, each call has two locations:
1. The unverified by-value location that's within its service area, and
2. The verified by-reference location that's somewhere else on earth

The result:  The LO has passed your validity check (provided-by domain = 
cert domain), but is actually an invalid location.  So this is a 
validation model that doesn't actually reflect a notion of validity.

On the other hand, if you have include a comparison of the two LOs in 
your validity check, then this attack doesn't work, and this could 
actually be considered a check on the validity of the provided LO.  But 
then you'd have to standardize this comparison operation.

--Richar

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 09:45:58 -0400

Martin,

> 
> Having said all that, I don't think that all network 
> topologies, application policies, or use cases in general are 
> going to be supported if location integrity is only able to 
> be communicated when the final consumer is also a 
> dereferencer. I think there are definitely scenarios that 
> will involve transmission by value through an intermediary.

Now were back to arguing the requirement(s).  We will never converge on a
solution if the requirement/use case is constantly changing.

Can you share substantiated use cases/requirements that you are referring to
in the above statement?

Thanks,

-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Wed, 21 Mar 2007 14:50:40 +0100

What I'm proposing is that the transmitted LO (regardless of how it's 
constructed) has the following form:

S/MIME-Data {
Content-Type: application/pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence entity="pres:[email-masked]">
	...
	<provided-by>[email-masked]</provided-by>
	...
</presence>
} signed by [email-masked]

This way, you get two avenues for verification:
-- By reference (Marc): Dereference the provided-by reference and verify 
that (1) cert provided is the cert for the indicated domain and (2) the 
tranmitted LO matches (see my other message).
-- By value (Richard): Verify the signature on the LO.
These provide equivalent levels of assurance, since both methods are 
based on encryptions with the same private key: By value, the encrypted 
thing is the hash of the LO, by reference, the TLS PreMasterSecret (or 
some such).

One way that this might work:
1. UA does L7LCP discovery
2. UA sends L7LCP query to his presence server,
    with LIS URI in the requires URI (e.g.)
3. Presence server passes query to the LIS, get LO
4. Presence server creates above signed LO, returns to UA
5. UA includes signed location in emergency call
6. Location recipient does Marc's authenticating dereference

Does that make sense?

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 21 Mar 2007 09:48:36 -0400

In this case, VeriSign has no clue about emergency calls or location  
signing, so it is not "assuming that role".

As you hint at, this simply requires maintaining a list at the PSAP  
of trusted identities and a list of CAs (the latter is already  
available via typical TLS libraries).

The bigger protocol issues relate to the conveyance, i.e., things  
other than XML-DSIG, exploring

No, this is not a major change, just a way to simplify deployments  
and avoid creating a new special-purpose PKI.

On Mar 21, 2007, at 9:12 AM, Dawson, Martin wrote:

>>> It appears there is large support for using certificates to  
>>> establish
>> a
>>> I'm sure there are downsides that I'm missing, please point them  
>>> out.
>> The

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 21 Mar 2007 10:00:31 -0400

I think you have a very hard battle ahead trying to remove the term "trust"
from security discussions.  We are in fact talking about trust some times:
who does the PSAP trust to generate location objects for example.

Sometimes we do talk about authenticity of data, which is one of the
properties you might facilitate with a digital signature.  For example, a
signature can guaranty integrity of the data - it was not changed from the
signer to the recipient.  However, the usefulness of that authenticity
depends on the trust you have in the signer.  EvilCorp can legitimately sign
something so that it authentically came from EvilCorp, but the PSAP may not
trust EvilCorp to provide location.  On the other hand, I assume you want us
to use "authenticity" to mean the authentic location, regardless of who
provided it or how we got it.  Henning of course would want to point out
that "authentic location" is not the requirement, it's "prevent diversion of
PSAP and responder resources".  Authentic location data is one path to
meeting that requirement, which might require a trusted entity digitally
signing a location object.  Have I got terms straight?

I do indeed believe it is a requirement that the entity that would sign a
location be the one that would operate the server that did the provided-by
dereference (or at least that there is a chain of trust between the two).

Brian

> From: Greg Troxel [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2007 9:40 AM
> To: Marc Linsner
> Cc: [email-masked]

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 10:02:16 -0400

Richard,

> 
> On the other hand, if you have include a comparison of the 
> two LOs in your validity check, then this attack doesn't 
> work, and this could actually be considered a check on the 
> validity of the provided LO.  But then you'd have to 
> standardize this comparison operation.

This falls apart with mobile clients that are 'on the move'.  The original
by-value lo will never match the current dereferenced lo, but I agree they
should be at least close (given normal rates of mobility, cars, planes,
trains).  But, the current location is only what I really care about, that
is where I'm dispatching resources.  If the by-value included in the call
setup is in Los Angeles and the deferenced L-by-R from provided-by is New
York, that *should* raise a flag to the Los Angeles call taker.

-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Wed, 21 Mar 2007 15:35:39 +0100

(Re-creating a conversation just had with Marc)

You're absolutely right.  But what that means is that the verification 
you get from your procedure has nothing to do with the provided LO.  You 
might as well provide them completely separately.

That said, while the provided-by field provides a convenient field with 
no standardization needed, there are other standard mechanisms to convey 
both locations with the same property.  Most notably, SIP location: To 
copy an example from draft-ietf-sip-location-conveyance:

    INVITE sips:[email-masked] SIP/2.0
    ...
    Geolocation: <cid:[email-masked]>;inserted-by=endpoint,
                 <pres:[email-masked]>;inserted-by=endpoint
    Supported: geolocation

    --boundary1

    Content-Type: application/sdp

    ...SDP here

    --boundary1

    Content-Type: application/pidf+xml
    Content-ID: [email-masked]

    ... PIDF-LO here
    --boundary1--

You get the (possibly bogus) PIDF-LO object as a body part pointed to by 
the CID URI, and the verifiable reference in the PRES URI.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Wed, 21 Mar 2007 15:36:47 +0100

Henning,

To say it a different way, you're differentiating between two different
types of trust:

1. FalsiSign is trusted to attest to the identity of Acme Corp

2. Acme Corp is trusted to attest to the reliablility of location
information

Both types of attestations are made, as you say, in various ways.  But
the standard way to make these attestations is to use public-key
mechanisms, whether by creating signed objects (by value) or by
communicating objects over an authenticated deference channel.

I think we agree,
--Richard

Henning Schulzrinne wrote:
> differentiate between the CA function and the "trust" function. Creating 
> a new special-purpose CA requires far more overhead, cost and complexity 
> than stating that "Acme Corp, as certified by FalsiSign Inc, can be 
> trusted to provide true location (or identity) information". FalsiSign's 
> cert would be the normal HTTP or SIP cert, as applicable, already 
> commercially available from many competing providers.
> 
> There are many ways to accomplish the protocol mechanics, including, but 
> not limited to, transporting LOs in TLS when derefencing to including a 
> verification reference in the LO. It would be helpful to explore these 
> as opposed to simply reiterating the same "my sign way or the highway".
> 
> Henning
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 21 Mar 2007 11:45:03 -0400

> solution if the requirement/use case is constantly changing.

Bingo!  Everybody in Prague should buy Marc a beer.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 12:42:53 -0400

I'll second that (and third, and fourth, and ....)
 
-Marc-

  _____  

From: Andrew Newton [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 11:45 AM
To: Marc Linsner
Cc: 'Dawson, Martin'; [email-masked]
Subject: Re: [Geopriv] Location Integrity

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 12:51:59 -0400

Richard, 
 
> To say it a different way, you're differentiating between two 
> different types of trust:
> 
> 2. Acme Corp is trusted to attest to the reliablility of 
> location information
> 
> Both types of attestations are made, as you say, in various 
> ways.  But the standard way to make these attestations is to 
> use public-key mechanisms, whether by creating signed objects 
> (by value) or by communicating objects over an authenticated 
> deference channel.

Unless we relinguish control of network operation to a some entity higher
that a human being, it is very hard to assertain that the location
information supplied is the actual location of the host in question,
trusting the entity that supplied the information is probably the best
possible with today's technology.

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Mar 2007 16:14:04 -0400

Greg,

I saw Brian's reply and I'm not trying to gang up on you. But.... 

> I've been lurking and not paying close attention, but I have 
> a few brief comments.  I realize you probably know a lot of 
> what I'm saying, but I'm erring on the side of saying too 
> much since that seems more likely to be helpful.
> 
> I'm uncomfortable when people use the word 'trust'.  That 
> properly refers to a human interaction where one entity has 
> confidence in another to behave reasonably.  Here, I think 
> we're talking about authenticity of data, or confidence that 
> some particular piece of data is accurate.  I have found that 
> avoiding the word trust tends to result in greater clarity as 
> then people have to describe which piece of data and what 
> property they want it to have.  So I suggest that the word 
> trust be completely eliminated from discussions of protocols.
> 
> A signature on an object is very different from 
> authentication of transported data.
> 
> certificates) or record authorization (typically via names).  
> While this is a tremendously useful building block, many 
> details remain.

You, like Richard, seem to be implying that it is possible for IETF defined
Internet protocols to provide absolute assurance that the location conveyed
about an IP host is absolutely the location of such host.  I'd like to hear
how that is accomplished without complete upheaval of the current Internet
(and I do have data that suggests such upheaval is not warranted).   

> In this case, it's necessary to be clear on what entity does 
> TLS at the webserver that fulfills the uri request.  That 
> could well be different than the entity that would have 
> signed a location.  And, one needs to authenticate that the 
> uri is the right one, in order to construct a proof that the 
> result is correct (given reasonable and documented assumptions).

Yes, I am assuming that the entity providing the L-by-V to the IP host
initially, knows how to represent itself in the L-by-R supplied at the same
time such that the cert used for TLS during dereference represents the same
entity.  Given acceptance that a PSAP can only really 'trust' the provider
of the location data, not the exact data itself, I don't see any problems.
If you do, please advise.

-Marc-

---

From: Greg Troxel <[email-masked]>
Date: Wed, 21 Mar 2007 16:49:53 -0400

"Brian Rosen" <[email-masked]> writes:

> I think you have a very hard battle ahead trying to remove the term
> "trust" from security discussions.  We are in fact talking about
> trust some times: who does the PSAP trust to generate location
> objects for example.

That's fair enough, but then we aren't talking about "certificates
establishing trust", but rather certificates binding identity or
recording human decisions about trust.  I was really just asking for
more clarity of language because have been finding this difficult to
follow.  The word trust is a trigger for me because I've seen the
casual use of the word (not recognizing the above distinction on which
we agree) strongly positively correlated with fuzzy thinking in other
contexts.

> properties you might facilitate with a digital signature.  For
> example, a signature can guaranty integrity of the data - it was not
> changed from the signer to the recipient.  However, the usefulness
> of that authenticity depends on the trust you have in the signer.
> EvilCorp can legitimately sign something so that it authentically
> came from EvilCorp, but the PSAP may not trust EvilCorp to provide
> location.

Agreed.

> On the other hand, I assume you want us to use "authenticity" to
> mean the authentic location, regardless of who provided it or how we
> got it.  Henning of course would want to point out that "authentic
> location" is not the requirement, it's "prevent diversion of PSAP
> and responder resources".  Authentic location data is one path to
> meeting that requirement, which might require a trusted entity
> digitally signing a location object.  Have I got terms straight?

Yes, that's fine and I understand you.  I'd use "accurate" to describe
the location being correct, reserving "authentic" (or the combination
of the "data origin authentication" service and the "integrity"
service) to refer to a message which is known to have originated by
some entity and not been modified.  If I tell you I'm in Australia in
this email, the message would still be authentic not not accurate.  I
realize that what you want is for very few significantly inaccurate
locations to be delivered to PSAPs, for some values of very few and
significant.

> dereference (or at least that there is a chain of trust between the two).

That makes sense.  I still wonder why L-by-R should use a different
mechanism (TLS) rather than using a regular channel to return a signed
object such as might be used with L-by-V.  It seems that indirection
for efficiency/convenience is being combined with security properties
in a way which strikes me (as someone who admittedly has not been
playing close attention) as hard to follow.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Greg Troxel <[email-masked]>
Date: Wed, 21 Mar 2007 16:55:24 -0400

> (and I do have data that suggests such upheaval is not warranted).   

I realize this isn't doable, and I didn't mean to argue that point.
I'm really trying to say that as someone used to thinking about
security and only semi paying attention, I'm having trouble following
the discussion.

> If you do, please advise.

The use of TLS (rather than a signed object) may make storing the
response together with the authenticated object more difficult, and
I'd expect support for such audit trails to be part of the
requirements.  From 10000 ft, this seems to be about conveying objects
with signatures for integrity/DAO, rather than about protecting
communications channels.  (I realize that one can implement one with
the other.)

As I said in my previous message, using a different mechanism based on
the transport path seems inelegant.  But I may well be
misunderstanding things.

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 21 Mar 2007 16:38:36 -0500

Hi Greg,

In response to your last point, Marc's argument is that you do away with
the idea of signing the actual value at all - eliminate any support for
it in the location service. That renders moot the question of why you
wouldn't also just use it for the dereference interface.

I think that having a mechanism to sign the actual value is still
warranted and that only having location
assurance/integrity/trust/dependability/... through the dereference
mechanism will not be adequate for all scenarios.

At which point Marc insisted I trump up with some use-cases and Andy
hooted that everyone should, therefore, buy him a beer. Seems like it's
easy to earn a beer here... :)

If I consider an application that is collecting location datums for a
particular device and that set of information is going to be passed to a
third party at some later point, then that third party may still want to
independently satisfy themselves of the source of the location and the
corresponding integrity of the value.

Indeed, if we look at i2, the VPC will be in receipt of the location
information but it will have been turning into E2 signaling by the time
it hits the ALI/PSAP network. I dare say the local authorities may still
like to have the PID-LO information available for later audit. Trying to
correlate the location information with some TLS certificate exchange
log is hardly going to be as tractable.

I don't think we are just designing the emergency service application
either. There have been a number of quite valid proposals that involve
the presence server associated with a user being the actual dereferencer
while acting as the hub for other applications that the user subscribes
to. These applications are still in a position to require
source/integrity information associated with the location value
provided.

Cheers,
Martin

-----Original Message-----
From: Greg Troxel [mailto:[email-masked]] 
Sent: Thursday, 22 March 2007 7:50 AM
To: Brian Rosen
Cc: [email-masked]; 'Marc Linsner'
Subject: Re: [Geopriv] Location Integrity

Agreed.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 21 Mar 2007 23:00:23 +0100

> about an IP host is absolutely the location of such host.  

Nobody's proposing that, Marc, and I'm not sure how you got that 
impression from anything I've said.  What the IETF does do is provide 
data structures that can be used to extend trust -- ways for someone to 
verify that the signed thing is actually what the signer said.

The best you're going to get from an signature by an LG is the knowledge 
that the LG claims to have seen a given low-layer identifier at a given 
position at given time, and that nobody has modified any of those pieces 
of information.  That last property is critical, because it prevents 
information from being spoofed when (1) the low-layer identifier can be 
bound to a relevant high-layer identifier, e.g. though SIP Identity and 
(2) the LIS is trusted not to intentionally lie.

TLS is a quick fix, but it's at best a partial solution, since all it 
guarantees is the last hop the location makes.  In order to assure that 
the transmitted LO corresponds to reality in some way, you need to have 
some trust in whatever process put the LO onto the server you're 
downloading it from.  The only way you get this without additional 
crypto is if the LG itself is the one acting as an LS.

The level of security provided by doing TLS on the last hop may be 
sufficient for some applications (maybe even most), but it's not the 
whole story.

> Given acceptance that a PSAP can only really 'trust' the provider

I'd like to clarify this sentence, since there are different levels of 
trust available to the location recipient:

1. If you trust the server's CA to identify him, and you trust the 
server not to intentionally lie to you, then TLS assures you that the 
data you get on the dereference is the data that was stored on the 
server (and that the data wasn't observed en route).

2. If you trust the server's CA to identify him, and you trust the 
server not to intentionally lie to you, then an LG signature on an LO 
assures you that that was the measured position of the identified thing 
at the indicated time.

Said another way, TLS lets you get data that's as trustworthy as the 
server you got it from and the person that put it there, while an LG 
signature lets you get data that's as trustworthy as the LG that 
generated it.

--Richard

---

From: Andrew Newton <[email-masked]>
Date: Wed, 21 Mar 2007 20:26:26 -0400

> easy to earn a beer here... :)

Actually, what I was "hooting" was the notion that the requirements  
and use cases keep changing... not that you hadn't provided any.   
There is a difference. (Are you also complaining about the beer  
policy as well? :) )

Initially, we were told the requirement was location signing.   
Setting aside the difference between a function and a solution, the  
following requirements have also popped up in the last several days  
in these threads:

1) partial signing of the PIDF-LO
2) cryptographic non-repudiation for auditing
3) peer authentication
4) origination from a non-accessible LIS
5) adhoc chains of trust
6) quick time to market / minimal specification work
7) support for all types of LIS, not just L7

I don't see any of these in the L7-LCP P&S draft and they weren't  
offered when it was presented in San Diego.  And here's the list you  
sent not 7 days ago -- none of which overlap:

> * Can be attributed to a recognized source
> * Has not been tampered with since generated at that source
> * Is applicable to a specific target identity
> * Is applicable at a particular point in time

In other words, we have a serious case of feature creep.

I strongly suggest we limit the technical requirements to fixing only  
those things that VoIP breaks and avoid requirements that are not  
required of the PSTN today.  It is not that the extra requirements  
are bad ideas, but protocols on the Internet are easy to be versioned  
and extended, so we can add them later.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 21 Mar 2007 19:59:38 -0500

:-) I guess my complaint about the beer policy is that, like you, I'm
not in Prague to enjoy it.

I think there's a difference between use-cases and requirements as well.
What Marc is suggesting is satisfying a particular requirement by
enforcing a particular use-case. If you want location integrity then you
have to use LbyR and the location consumer has to be the dereferencer. I
think this is too narrow a solution for the requirement.

I'm surprised that we can only invoke use-cases driven by VoIP. I didn't
think that was the intent of the geopriv brief. I recall we actually had
a ban on discussing the emergency use case for a few days recently in
order to encourage thinking about other applications.

As far as things being extensible - I agree. I pretty much said the same
thing about Marc's proposal - perhaps time to market will dictate that
use case if the IETF doesn't offer an alternative solution for by-value
integrity in a timely fashion. At the same time, I don't understand the
impediment to discussing by-value solutions such as the Thomson draft.

Cheers,

Martin

________________________________

From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, 22 March 2007 11:26 AM
To: Dawson, Martin
Cc: Greg Troxel; GEOPRIV WG; Marc Linsner
Subject: Re: [Geopriv] Location Integrity

Actually, what I was "hooting" was the notion that the requirements and
use cases keep changing... not that you hadn't provided any.  There is a
difference. (Are you also complaining about the beer policy as well? :)
)

Initially, we were told the requirement was location signing.  Setting
aside the difference between a function and a solution, the following
requirements have also popped up in the last several days in these
threads:

3) peer authentication

5) adhoc chains of trust

I strongly suggest we limit the technical requirements to fixing only
those things that VoIP breaks and avoid requirements that are not
required of the PSTN today.  It is not that the extra requirements are
bad ideas, but protocols on the Internet are easy to be versioned and
extended, so we can add them later.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 21 Mar 2007 21:15:08 -0400

On Mar 21, 2007, at 8:59 PM, Dawson, Martin wrote:

> I'm surprised that we can only invoke use-cases driven by VoIP.

Though at times it seems like it, boiling the ocean is not within our  
charter.

-andy

---

From: Richard Barnes <[email-masked]>
Date: Thu, 22 Mar 2007 07:13:56 +0100

Boiling the ocean, maybe not.  But application-independent mechanisms 
for location privacy seem to be.  From the charter:

"
For reasons of both future interoperability and assurance of the
security and privacy goals, it is a goal of the working group to
deliver a specification that has broad applicablity and will become
mandatory to implement for IETF protocols that are location-aware.
"

I'm not saying we need to everything, just that we're not a SIP-only group.

--Richard

Andrew Newton wrote:
> ------------------------------------------------------------------------
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 22 Mar 2007 04:39:10 -0500

>I'll second that (and third, and fourth, and ....)

I bought him 2 actually

;-)

>----------