Subject: [Ecrit] Location hiding: VSP verification by UAS

From: Richard Barnes <[email-masked]>
Date: Wed, 27 Jun 2007 21:39:25 -0400

So, the "location hiding" problem is really two problems: When the 
access network provisions location in a way that the endpoint can't get 
the location,
(1) How does the endpoint or VSP route and emergency call? and
(2) How can a VSP verify that a call is an emergency call?

To date, solutions to the second problem have focused on performing this 
verification based on information in the INVITE.  In a location hiding 
context, this approach runs into the problem that in order to use LoST 
to verify the To: URI, either the UAC, the VSP, or a LoST server has to 
dereference the location, and none of these is necessarily authorized to 
do so.

On the other hand, I think the second problem is pretty easy to solve if 
the VSP is willing to transmit the INVITE and allow the UAS to provide 
evidence that the call is an emergency call.  The PSAP, after all, is in 
a much better position to authenticate itself than the UAC is to 
authenticate it.  This authentication could take several forms:

1. If VSPs are willing to trust the LoST infrastructure, the PSAP could 
include its service area in its 200 response; the VSP would verify by 
performing a LoST query with the location and service URN in the SIP 
traffic, and compare the <uri> element in the resulting mapping to the 
To: address in the INVITE transaction.

2. If PSAPs have credentials, then the PSAP could use connected-identity 
to assert its identity (or just use S/MIME to sign a 200 response with 
it's key).

Both of these can be done with protocols that are already released or in 
process: Option 1 by including a GML or PIDF-LO document in the 200 
response (possibly indicated by a Geolocation: header), and Option 2 
with S/MIME or connected-identity.

Humbly submitted,
--Richard

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Jun 2007 22:57:01 -0500

I need to see each proposed message flow.  SIP is an e2e protocol, 
and a 200Ok to an INVITE means the INVITE was accepted as is - and is 
intended to travel all the way back to the original UAC. SIP doesn't 
error responses, which is what I feel you are proposing if the 
authentication fails (within a VSP proxy).

At 08:39 PM 6/27/2007, Richard Barnes wrote:
>access network provisions location in a way that the endpoint can't 
>get the location,
>To date, solutions to the second problem have focused on performing 
>this verification based on information in the INVITE.  In a location 
>hiding context, this approach runs into the problem that in order to 
>use LoST to verify the To: URI, either the UAC, the VSP, or a LoST 
>server has to dereference the location, and none of these is 
>necessarily authorized to do so.
>
>On the other hand, I think the second problem is pretty easy to 
>solve if the VSP is willing to transmit the INVITE and allow the UAS 
>to provide evidence that the call is an emergency call.  The PSAP, 
>after all, is in a much better position to authenticate itself than 
>the UAC is to authenticate it.  This authentication could take several forms:
>
>1. If VSPs are willing to trust the LoST infrastructure, the PSAP 
>could include its service area in its 200 response; the VSP would 
>verify by performing a LoST query with the location and service URN 
>in the SIP traffic, and compare the <uri> element in the resulting 
>mapping to the To: address in the INVITE transaction.
>
>2. If PSAPs have credentials, then the PSAP could use 
>connected-identity to assert its identity (or just use S/MIME to 
>sign a 200 response with it's key).
>
>Both of these can be done with protocols that are already released 
>or in process: Option 1 by including a GML or PIDF-LO document in 
>the 200 response (possibly indicated by a Geolocation: header), and 
>Option 2 with S/MIME or connected-identity.
>
>Humbly submitted,
>--Richard
>
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 28 Jun 2007 00:29:33 -0400

Hi James,

> I need to see each proposed message flow. 

I was proposing more the conceptual flow of the UAS providing the 
authentication information than a specific message flow.  There are many 
models that could be used: Authenticators could be conveyed in a 200, or 
in a separate UPDATE transaction (as in connected-identity).

> SIP is an e2e protocol, and a 
> 200Ok to an INVITE means the INVITE was accepted as is - and is intended 
> to travel all the way back to the original UAC. SIP doesn't error 
> responses, which is what I feel you are proposing if the authentication 
> fails (within a VSP proxy).

I don't think that it's necessarily within the purview of ECRIT to 
specify the behavior that results from a failed authentication.  In 
fact, I expect that this behavior will vary widely from VSP to VSP: One 
VSP might allow the call to proceed normally, but start billing for it 
after the authentication fails.  Another might use a B2BUA that it 
inserted in the path to kill the call.  Et cetera.

The essential thing is that allowing the UAS to provide authenticators 
allows the PSAP to vouch for the fact that a call is an emergency call, 
regardless of how location is provisioned.  What the VSP chooses to do 
with that information is a local decision (though maybe we could make 
some non-normative recommendations).

--Richard

>> On the other hand, I think the second problem is pretty easy to solve 
>> if the VSP is willing to transmit the INVITE and allow the UAS to 
>> provide evidence that the call is an emergency call.  The PSAP, after 
>> all, is in a much better position to authenticate itself than the UAC 
>> is to authenticate it.  This authentication could take several forms:
>>
>> verify by performing a LoST query with the location and service URN in 
>> the SIP traffic, and compare the <uri> element in the resulting 
>> connected-identity to assert its identity (or just use S/MIME to sign 
>> a 200 response with it's key).
>>
>> Both of these can be done with protocols that are already released or 
>> in process: Option 1 by including a GML or PIDF-LO document in the 200

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 28 Jun 2007 00:58:55 -0500

Hey Richard,

A lot of large call-servers from what I understand operate as B2BUA
anyway. So that may be something that you can leverage.

Cheers
James

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Thursday, 28 June 2007 2:30 PM
> To: James M. Polk
> Cc: ECRIT
> Subject: Re: [Ecrit] Location hiding: VSP verification by UAS
> 
> Hi James,
> 
solve
> >> verify by performing a LoST query with the location and service URN
in
> >> connected-identity to assert its identity (or just use S/MIME to
sign
> >> Both of these can be done with protocols that are already released
or
> >> with S/MIME or connected-identity.

------------------------------------------------------------------------------------------------
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: "Brian Rosen" <[email-masked]>
Date: Thu, 28 Jun 2007 07:55:18 -0400

We would have to do it with an Update.

I am uncomfortable with this idea, as it complicates the message flow on
every emergency call.

The basic idea has merit, but the details don't work for me.

Brian

> Sent: Thursday, June 28, 2007 12:30 AM
> To: James M. Polk
> Cc: ECRIT

---

From: Andrew Newton <[email-masked]>
Date: Thu, 28 Jun 2007 09:19:10 -0400

I don't see how an UPDATE helps.  And the endpoint can simply not  
issue the UPDATE to get around the verification.

I think Richard's proposal has legs.

-andy

---

From: Richard Barnes <[email-masked]>
Date: Thu, 28 Jun 2007 09:36:16 -0400

Right.  In either cases, the VSP would be free to consider a call 
unverified if no authenticator were presented after a certain period 
(this period would be good to specify in a BCP).

--Richard

Andrew Newton wrote:
> I don't see how an UPDATE helps.  And the endpoint can simply not issue 
> the UPDATE to get around the verification.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 28 Jun 2007 12:14:57 -0400

To get the location of the PSAP, you need an UPDATE, with the PSAP doing the
update and becoming the UAC because it's reliable.  Conveyance is defined
from UAC to UAS only, for this, among other reasons.

Brian
> Sent: Thursday, June 28, 2007 9:36 AM
> To: Andrew Newton
> Cc: Brian Rosen; 'James M. Polk'; 'ECRIT'

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 28 Jun 2007 12:48:21 -0500

>anyway. So that may be something that you can leverage.

James - the SIP WG has violently agreed B2BUAs cannot be relied upon 
in a message flow, so I'm not sure how this will work (where's that 
message flow to show that it will?).

Thus, relying on a B2BUA in every message flow means 100% of the 
time, one will be in the message flow, otherwise this leverage is 
zero.  That's not a good position (no pun intended) to be in.

Someone working up a message flow will go a long ways towards showing 
if this can work, else we're talking in abstracts about something 
that seriously needs to work all the time.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 28 Jun 2007 12:43:31 -0500

what he said!

James

(I need to see a planned message flow to be swayed from this pov)

---

From: Richard Barnes <[email-masked]>
Date: Thu, 28 Jun 2007 14:21:32 -0400

I apologize for bringing B2BUAs into this.  I didn't mean that they 
should be part of the recommendation, just that that would be one way 
for the VSP to terminate the call if it so desired.  Obviously, the 
solution should not depend on them.

--RB

James M. Polk wrote:
> James - the SIP WG has violently agreed B2BUAs cannot be relied upon in 
> a message flow, so I'm not sure how this will work (where's that message 
> flow to show that it will?).
> 
> Thus, relying on a B2BUA in every message flow means 100% of the time, 
> one will be in the message flow, otherwise this leverage is zero.  
> That's not a good position (no pun intended) to be in.
> 
> Someone working up a message flow will go a long ways towards showing if 
> this can work, else we're talking in abstracts about something that 
> seriously needs to work all the time.
> 
> 
>> Cheers
>> James
>>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 28 Jun 2007 14:30:16 -0400

I don't think that reliability is necessarily a discriminator in this 
case: If you send the PSAP's location/service area in a 200 and the 200 
doesn't get there, you've got other problems above and beyond VSP 
verification.

--Richard

---

From: Andrew Newton <[email-masked]>
Date: Thu, 28 Jun 2007 14:54:25 -0400

> from UAC to UAS only, for this, among other reasons.

Well, this really wouldn't be location conveyance but service  
boundary conveyance.  But I understand your point.

Still, the idea that the PSAP should be able to prove that it is a  
PSAP is worthwhile.  This could happen with an identity instead of a  
service boundary.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 28 Jun 2007 14:00:22 -0500

At 01:30 PM 6/28/2007, Richard Barnes wrote:
>I don't think that reliability is necessarily a discriminator in 
>this case: If you send the PSAP's location/service area in a 200 and 
>the 200 doesn't get there,

Where's "there" in this context?

A caller sends an INVITE to a PSAP (regardless of how many servers it 
goes through, it's destination is towards the PSAP - even if the 
R-URI is changed).  In other words, it's e2e.

A 200OK to the INVITE is destined for the caller's UAC, not anywhere 
else - though servers can view unencrypted message bodies if location is LbyV.

I think also that if you build a PIDF-LO for the coverage area of a 
PSAP, you aren't going to use civic, as I don't think PSAP boundaries 
are absolutely limited to a defined city or county perimeter. I 
remember being railed on because PSAP boundaries often are the middle 
line of a street, where one side of the street is PSAP-A and the 
other side of the street is PSAP-B.  This means that this street 
cannot be a boundary delineation between PSAP coverage areas.  This 
gets you into coordinate or geo formats (basically, the linear ring 
concept within GML). This can be HUGE in xml with all the points you 
have to include, if you want to be precise, and since SIP cannot 
error response messages, this 200OK message will likely be 
substantially larger than the request (which will likely be in civic) 
- therefore the packet might get too large and require an error message to it.

This is part of the reason (but not specifically about PSAP 
boundaries) that location is not to be in SIP responses.  This is 
part of section 5.2 UAS Behavior of Conveyance.

>you've got other problems above and beyond VSP verification.
>
>--Richard
>
>
>
>Brian Rosen wrote:

---

From: Matt Lepinski <[email-masked]>
Date: Thu, 28 Jun 2007 16:35:53 -0400

James,

James M. Polk wrote:

> line of a street, where one side of the street is PSAP-A and the other 
> side of the street is PSAP-B.  This means that this street cannot be a 
> boundary delineation between PSAP coverage areas.  This gets you into 
> coordinate or geo formats (basically, the linear ring concept within 
> GML). This can be HUGE in xml with all the points you have to include, 
> if you want to be precise, and since SIP cannot error response 
> messages, this 200OK message will likely be substantially larger than 
> the request (which will likely be in civic) - therefore the packet 
> might get too large and require an error message to it.

If the point is verifying that the end-point is a PSAP, then it's not 
necessary for the PSAP to convey the entire boundry of the service 
region to the VSP. All that's needed is for the PSAP to hand the VSP an 
arbitrary point in the service region. The VSP can then query LoST with 
this point and see that the result matches the URI to which the call was 
routed.

That is, the VSP doesn't care what the service region is for the PSAP. 
All the VSP cares about is that there exists at least point for which 
the callee is a valid PSAP.

- Matt Lepinski :->

>>>>> issue
>>>>>> I am uncomfortable with this idea, as it complicates the message 
>>>>>> flow
>>>>>
>>>> on
>>>>
>>>>>> every emergency call.
>>>>>>
>>>>>>> authentication information than a specific message flow.  There are
>>>>>>
>>>> many
>>>>
>>>>>>> models that could be used: Authenticators could be conveyed in a 
>>>>>>> 200,
>>>>>>
>>>> or
>>>>
>>>>>>>> responses, which is what I feel you are proposing if the
>>>>>>>
>>>> authentication
>>>>
>>>>>>> fact, I expect that this behavior will vary widely from VSP to VSP:
>>>>>>
>>>> One
>>>>
>>>>>>> allows the PSAP to vouch for the fact that a call is an emergency
>>>>>>
>>>> call,
>>>>
>>>>>>>>> provide evidence that the call is an emergency call.  The PSAP,
>>>>>>>>
>>>> after
>>>>
>>>>>>>>> all, is in a much better position to authenticate itself than the
>>>>>>>>
>>>> UAC
>>>>
>>>>>>>>> is to authenticate it.  This authentication could take several
>>>>>>>>
>>>> forms:
>>>>
>>>>>>>>> in process: Option 1 by including a GML or PIDF-LO document in 
>>>>>>>>> the
>>>>>>>>
>>>> 200
>>>>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 29 Jun 2007 00:10:33 -0400

To be a little more concrete, if the authenticator (location/sb or 
Identity header) is going to be carried in the 200/OK, then there is no 
change required to the standard INVITE message flow.  The proxy simply 
observes the 200 as it passes by, and any action it takes based on the 
authenticator is external to that transaction.

> goes through, it's destination is towards the PSAP - even if the R-URI 
> is changed).  In other words, it's e2e.

Sure.  But the response will still go back through the proxies in the 
Record-Route chain, so if a proxy wants to verify, it just has to add 
itself into the Record-Route.  The 200 will travel e2e, but the proxy 
will get to see it and get the authenticator from it.

> else - though servers can view unencrypted message bodies if location is 

This is just an argument to put the authenticator in a header so that 
proxies can see it.  Makes sense to me.

> are absolutely limited to a defined city or county perimeter. ...

This is a good point, but I think there are ways around it.  Using 
connected-identity instead of LoST as an authenticator is one.  Even if 
you do use LoST to authenticate the call, then all the PSAP really needs 
to provide is a single location in its service area; presumably the 
location of the PSAP will suffice in a lot of cases.  Alternatively, the 
message could contain no location at all, and carry an service boundary 
reference that could be used to get the location to do the verification.

> This is part of the reason (but not specifically about PSAP boundaries) 
> that location is not to be in SIP responses.  This is part of section 
> 5.2 UAS Behavior of Conveyance.

I don't really see the harm here.  I guess the risk is that the PSAP 
puts in a location that the VSP can't understand, but it seems like you 
could write the phonebcp in such a way as to constrain this, e.g., "the 
value in the Geolocation header MUST be a cid URI" or "MUST be an HTTP 
URI".  Even if there is an error with the Geolocation value, the risk is 
mostly that the call won't authenticate and the call gets handled as a 
non-emergency call.  This seems like a small risk, and one that could be 
addressed in the phonebcp (e.g., "VSPs MUST NOT terminate unverifable 
emergency calls, but MAY choose to handle them as they would 
non-emergency calls").

(As a general point, I don't see anything in section 5.2 that forbids 
putting Geolocation into a response, and Table 1 explicitly indicates 
that Geolocation can be carried in responses.  We should move any 
further debate on this to another forum, though.)

--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 29 Jun 2007 13:12:14 -0500

At 01:54 PM 6/28/2007, Andrew Newton wrote:

>boundary conveyance.

err, this is a location (which can be either small or large) being 
"pushed" (vs. pulled or retrieved) towards a destination device. How 
exactly isn't this location conveyance?

;-)

>But I understand your point.
>
>PSAP is worthwhile.

there was a draft on replied identification about a year ago in 
SIP/PING written by Feng Cao and Cullen, but it died.

>This could happen with an identity instead of a
>service boundary.
>
>-andy

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 29 Jun 2007 13:13:42 -0500

At 03:35 PM 6/28/2007, Matt Lepinski wrote:
>>PSAP, you aren't going to use civic, as I don't think PSAP 
>>boundaries are absolutely limited to a defined city or county 
>>perimeter. I remember being railed on because PSAP boundaries often 
>>are the middle line of a street, where one side of the street is 
>>PSAP-A and the other side of the street is PSAP-B.  This means that 
>>this street cannot be a boundary delineation between PSAP coverage 
>>areas.  This gets you into coordinate or geo formats (basically, 
>>the linear ring concept within GML). This can be HUGE in xml with 
>>all the points you have to include, if you want to be precise, and 
>>since SIP cannot error response messages, this 200OK message will 
>>likely be substantially larger than the request (which will likely 
>>be in civic) - therefore the packet might get too large and require 
>>an error message to it.
>
>If the point is verifying that the end-point is a PSAP, then it's 
>not necessary for the PSAP to convey the entire boundry of the 
>service region to the VSP. All that's needed is for the PSAP to hand 
>the VSP an arbitrary point in the service region. The VSP can then 
>query LoST with this point and see that the result matches the URI 
>to which the call was routed.

fair (i.e., point taken)

I sit corrected

>That is, the VSP doesn't care what the service region is for the 
>PSAP. All the VSP cares about is that there exists at least point 
>for which the callee is a valid PSAP.
>
>- Matt Lepinski :->
>
>>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 29 Jun 2007 13:27:01 -0500

At 11:10 PM 6/28/2007, Richard Barnes wrote:
>Identity header) is going to be carried in the 200/OK, then there is 
>no change required to the standard INVITE message flow.  The proxy 
>simply observes the 200 as it passes by, and any action it takes 
>based on the authenticator is external to that transaction.
>
>>A caller sends an INVITE to a PSAP (regardless of how many servers 
>>it goes through, it's destination is towards the PSAP - even if the 
>Sure.  But the response will still go back through the proxies in 
>the Record-Route chain, so if a proxy wants to verify, it just has 
>to add itself into the Record-Route.  The 200 will travel e2e, but 
>the proxy will get to see it and get the authenticator from it.
>
>>A 200OK to the INVITE is destined for the caller's UAC, not 
>>anywhere else - though servers can view unencrypted message bodies 
>>if location is LbyV.
>
>This is just an argument to put the authenticator in a header so 
>that proxies can see it.  Makes sense to me.
>
>>boundaries are absolutely limited to a defined city or county perimeter. ...
>
>connected-identity instead of LoST as an authenticator is one.  Even 
>if you do use LoST to authenticate the call, then all the PSAP 
>really needs to provide is a single location in its service area; 
>presumably the location of the PSAP will suffice in a lot of 
>cases.  Alternatively, the message could contain no location at all, 
>and carry an service boundary reference that could be used to get 
>the location to do the verification.
>
>I don't really see the harm here.

Conveyance is written (now) as a general purpose mechanism for 
conveying location, as such, there are no exceptions made because the 
UAS is a PSAP, even for responses.  As stated, location cannot be in 
responses from any UAS according to the text in Conveyance -08.

>I guess the risk is that the PSAP puts in a location that the VSP 
>can't understand,

the risk is that any other UAS can do what the PSAP UAS can do, if 
Conveyance says location can be in responses.

>but it seems like you could write the phonebcp in such a way as to 
>constrain this, e.g., "the value in the Geolocation header MUST be a 
>cid URI" or "MUST be an HTTP URI".  Even if there is an error with 
>the Geolocation value, the risk is mostly that the call won't 
>authenticate and the call gets handled as a non-emergency call.

The larger concern is that there is an error with the SIP response, 
which cannot be reacted to, so the UAS sender will never know it is 
causing the problem by including location in the response.

>This seems like a small risk, and one that could be addressed in the 
>phonebcp (e.g., "VSPs MUST NOT terminate unverifable emergency 
>calls, but MAY choose to handle them as they would non-emergency calls").
>
>(As a general point, I don't see anything in section 5.2 that 
>forbids putting Geolocation into a response, and Table 1 explicitly 
>indicates that Geolocation can be carried in responses.

Table 1 has an 'R' in the 'where' column, which means "not to be in 
responses", according to the rules of RFC 3261.  Section 5.2 of 
Conveyance says "A UAS MUST NOT send location in a response message..."

both are pretty clear

>We should move any further debate on this to another forum, though.)

indeed, as this is a SIP protocol issue, not an ECRIT issue

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 29 Jun 2007 16:31:24 -0400

Generally, I continue to agree that this is a worthwhile thought, but we
haven't gotten to a believable (to me) mechanism.  Identity is great, but
outside of a global emergency PKI, how do we do that?

Brian

> From: James M. Polk [mailto:[email-masked]]
> Sent: Friday, June 29, 2007 2:27 PM
> To: Richard Barnes
> Cc: Brian Rosen; 'Andrew Newton'; 'ECRIT'