Call Server

1. ESGW SR Emergency Call Routing using an LO VPC LO=Wall St LIS Route=Manhattan PSAP CallServer LO=Wall St ManhattanPSAP • The Location Object (LO) is provided in the call setup information to the Call Server. • The Call Server requests the VPC to instruct it as to which is the correct serving PSAP to route the call to for the location described in the LO. • The VPC provides that routing information and the call is established

2. ESGW SR Casual location spoofing VPC LO=Wall St LIS Route=Manhattan PSAP CallServer LO=Wall St ManhattanPSAP LO=Wall St • PROBLEM: • This means any user could send an LO to appear it is calling from a specific location (spoof that location). • This means it will cause the call to be sent to the PSAP regardless of the actual location of the caller

3. Data signing by private/public key encryption – Overview tutorial ORIGIN DESTINATION Transmission DATA DATA XMT Hash Function Hash Function Hash Value Xmt Hash Value Original Compare Hash Val Decrypted Private KeyEncrypt Public* KeyDecrypt SIGNATURE SIGNATURE * Mechanism by which the public key is known to the destination is implementation dependent. There are a number of options.

4. ESGW SR Preventing casual location spoofingwith a signed LO VPC X LOLIS=Wall St LIS Route=Manhattan PSAP LOLIS=Wall St CallServer LOLIS=Wall St ManhattanPSAP LO=Wall St • A way to prevent users from sending arbitrary locations is to have the location information signed by the actual access network. • The LIS provides the location but it also provides a signature object which can be checked at the VPC to determine whether this location was genuinely determined at that point in the network. • A casually spoofed location can then be detected at the VPC.

5. ESGW SR One time theft/copy of a signed LO VPC LOLIS=Wall St LIS Route=Manhattan PSAP LOLIS=Wall St CallServer One time copy of LOLIS ManhattanPSAP LOLIS=Wall St • PROBLEM: • If the signed LO is static (always the same), then it only needs to be obtained once, and may be used any number of times even without an ongoing presence at the access. • A non-casual spoofer can obtain a copy of the signed LO using any one-time-capture of the signed LO at the access. • While casual spoofers and nuisance callers may have been deterred, it will not stop a more determined person. Signed LO information could be readily distributed around the internet if it was never subject to change.

6. ESGW SR Preventing one time copy spoofingwith an expirable signed LO VPC X LOLIS-CurrentTime=Wall St LIS Route=Manhattan PSAP LOLIS-CurrentTime=Wall St CallServer LOLIS-CurrentTime=Wall St ManhattanPSAP LOLIS-OldTime=Wall St • In addition to signing the LO, the LIS may provide a timestamp associated with the signature. That is, the signature would be on the expiry time in addition to the LO. • The VPC needs to be synchronized to some degree with the LIS (e.g. expiry based on UTC clock) but it can make a determination if an excessively old copy of the LO is being used. • If the expiry time is brief enough, then it limits the usefulness of a one-time copy of a signed LO.

7. ESGW SR Amplification using a real time feed of unexpired signed LO key VPC LOLIS-CurrentTime=Wall St LIS Route=Manhattan PSAP LOLIS-CurrentTime=Wall St CallServer Real time copy of LOLIS-CurrentTime ManhattanPSAP LOLIS-CurrentTime=Wall St • HOWEVER: • A determined attacker, or group of attackers, could establish a single device in a target area to provide a real time feed of the unexpired signed LO credentials. • This may be a device owned by the attackers or be done by compromising a single user’s device in that area. • Since the same unexpired signed LO would be valid for all users, an attack through “amplification” could be raised, where multiple calls are generated using the same location object.

8. ESGW SR VPC can detect that one call already exists for this ClientID Preventing amplification using a unique client ID VPC X LOLIS-CurrentTime-ClientID=Wall St LIS Route=Manhattan PSAP LOLIS-CurrentTime-ClientID=Wall St CallServer Real time copy of LOLIS-CurrentTime-ClientID ManhattanPSAP LOLIS-CurrentTime-ClientID=Wall St • The LIS can generate a unique identifier for each device it provides an LO to. This unique identifier can also be signed by the LIS and be included in the key. • The VPC is then able to identify whether two call routing requests have arrived for the same device – or whether a very large number of requests are coming for the same device. • A more constrained form of amplification is still possible if the attacker utilizes different VSP Call Server operators where they know that those VSPs use different VPC operators. This still significantly limits the number of distinct calls and is more difficult to engineer.

9. Location Credentials Construction – created by the LIS Location Credentials (LC) Certificate Expiry Time Client-ID Signature Location Object (LO) Private KeyEncrypt Hash Value The Certificate included with the credentials is unique to the LIS, issued by a recognized certificate authority so the LIS can be properly identified. It contains the public key information for that LIS that permits the key to be decrypted. The LC may be delivered as a separate VoIP signaling parameter or it could be a defined parameter within the LO itself. Hash Function

10. ESGW SR Call Origin point identifier for B does not match what is provided in the call signaling. Alternative possibility: Preventing spoofing by call origin point signing VPC X CallOriginID=B + LOLIS-CallOrigin=A=Wall St LIS LOLIS-CallORigin=A=Wall St CallServer OriginPoint=A(common knowledge) Real time copy of LOLIS-CallOrigin=A ManhattanPSAP OriginPoint=B CallOriginID=B + LOLIS-CallOrigin=A=Wall St • An alternative anti-spoofing measure is to rely on comparing a piece of information that is transferred in the call setup and is unique to the Call Server client and is also known to the LIS. • An example of this may be the IP address of the device. If this is unique and known to both the LIS and the VSP and is transported as part of the signaling to the VPC. Then the VPC can compare the signed end point ID with that delivered in the call signaling. • The effectiveness of this depends on the ability of the LIS to identify some common information reliably and regardless of VoIP protocol. NATs may be problematic. • More investigation and discussion needed to determine the viability of such an approach since it may require a linkage between the VoIP Call Server and the LIS.

11. Alternative (optional additional) architecture utilizing V3 interface • An alternative to sending cryptographic information (LIS signed data) in the call signaling is for the VPC to obtain the LO directly from the LIS. • The LIS-ID can be sent transparently in a Location Key (LK) without needing to send the actual certificate. This is because the LIS credentials can be established directly over the V3 interface. • It is not necessary to use an expiry time because the LIS can provide instantaneous feedback as to the validity of the LK.ClientID within its access network.. • The users location information does not need to be sent through the call signaling path so privacy is protected. The V3 interface communications are fully encrypted by two way certificate exchange between the VPC and LIS, further enhancing privacy cf and unencrypted VoIP channel. CallServer LK V2 VPC LK LO V3 LIS

12. Location Key (LK) Construction Location Key (LK) LIS-ID Client-ID • Location Key does not contain any cryptographic information. • Since the LIS provides real time confirmation of the presence of a matching client ID, there is no requirement to transport an expiry value. • The LIS credentials are exchanged via the V3 interface and do not require transporting within the LK. • Since the LO information is obtained directly from the LIS, there is no imperative to sign the LK information. • If the LK is stolen, it still has to be represented by a genuine client presence in the access. Either a “drone” device has to be physically placed in the access to obtain the LK or the LK of an innocent user has to be stolen by compromising the device in real time.