Re: [Ecrit] Comments to draft-barnes-ecrit-auth-00.txt

Hannes,

Thanks for your comments.  A few responses:

> The UAC does not need to have access to precise location information. 
> The considerations for "location hiding" apply here.

It doesn't need to have precise location, but it needs to have some 
location that's good enough for LoST.  This may not be the case, e.g., 
if it just got the PSAP URIs through HELD.

> I am not sure what you mean with the sentences in the later part of the 
> paragraph

draft-ietf-sip-location-conveyance puts a few relevant restrictions on 
the use of the Geolocation header, including the specification of which 
request and response types can carry it.  It also says that the value in 
the Geolocation header is always the location of the UAC.  I was 
thinking that the UAS (the PSAP) might include ITS location in a 
Geolocation header, which would be a problem.

> Section 2.2: Asserter Identity
> 
> This model assumes that the PSAP operators network asserts that it has 
> received an emergency call. It furthermore assumes that the VSP is able 
> to verify which identities are indeed PSAP operators. Hence, some white 
> lists of PSAP operators need to made available.

That's correct.  I was imagining that you would have a dedicated 
authentication infrastructure for emergency services entities, so that 
if an entity were authenticated under this infrastructure, then you 
would know it's an emergency services entity.

> You want to use the Connected Identity for this purpose.

Yes, that's how a PSAP (as a UAS) could assert its identity.  If you 
were thinking about authority-to-citizen, you use SIP Identity for the 
originating authority to authenticate its identity.

> From the description I got the impression that this is the plain SIP 
> Identity. I cannot quite see how this prevents the attack. How does a 
> VSP verify whether this is indeed an emergency call?

The idea behind 2.3 is something SAML-like: An asserter that has a 
credential that shows that it's authorized to assert emergency calls, 
like an emergency services gateway.  The asserter inserts a marking 
(think SAML assertion) that asserts that the call is an emergency call.

> Another solution would be to sign a LoST mapping response (with a 
> service boundary). The SIP UA would then add the signed LoST mapping  
> into the SIP message together with the location information it used for 
> retrieving the mapping. The VSP would verify that
> a) the signature of the mapping is correct.
> b) compare the identity of the mapping server with a a whitelist of 
> valid mapping servers
> c) verify whether the location information is contained in the service 
> boundary.
> 
> The problem is that this is again complex, i.e., by no means better than 
> the current solution we use as a working assumption.
Using signed LoST responses could be a good option, one I'd like to 
discuss more.  I'll split this off into a separate thread.

--Richard

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit