1. Proxy Authentication of the Emergency Status of SIP Calls draft-barnes-ecrit-auth-00 Richard Barnes IETF 69, Chicago, IL, USA

2. Problem: Two questions Location Hiding: How can a proxy tell that a call it’s processing is an emergency call, even if that call doesn’t have a location that the proxy can see? Emergency call marking: More generally, how can a proxy reliably distinguish emergency calls from non- emergency calls?

3. Authenticating to Proxies Goal: Enable a proxy in the signaling path that reliably distinguish between emergency and non-emergency calls –I.e., prevent fraudulent emergency calls Proxy will make a decision based on information taken from SIP messages Need to define: –An authenticator – the marking –An embedding into SIP messages

4. Concept prior to location hiding UAC embeds location and service URN in its INVITE message Proxy uses location and URN in a LoST lookup, verifies that returned URI is in the To: header Authenticator: location + service URN Embedding: INVITE message

5. Authenticators Authenticator: A data structure that a SIP proxy can use to verify that a call is an emergency call –MUST be bound to a particular call –MUST be non-forgeable –Each authenticator has a different model of what it means for a call to be an emergency call Three examples in this document –Location + service URN –Identity authenticators –Explicit emergency call indicators

6. Location + service URN Construction –Asserter is UAS / UAC / proxy –Insert a location object and a service URN into a SIP message Verification –Extract location object and URN –Perform LoST query –Compare mapped URI to To: header Trust model –Reliability of LoST infrastructure –LoST mapping = To:PSAP = emergency call

7. Location + service URN (cont’d) When the asserter is the UAC/Proxy, SIP message is INVITE, this is the current way Pros: –Simple to use in many use cases –Requires no additional authentication infrastructure (beyond LoST) Cons: –Fails when Asserter has no location –Fails if LoST information changes –Relies on trusted LoST infrastructure –Endpoint-centric definition of emergency call

8. Identity Authenticators Construction –Asserter is a PSAP (UAS / UAC) –Use SIP Identity or Connected-Identity to prove its identity as a PSAP Verification –Same Verifier behavior as SIP Identity Trust model –One or more PSAP credentialing authorities –Caller/callee = authenticated PSAP = emergency call

9. Identity Authenticators (cont’d) Pros –Uses existing SIP authentication mechanisms –Doesn’t rely on location in messages Cons –Requires credentialing PSAPs –For citizen-to-authority, requires postponing authentication until after INVITE –Still uses endpoint-centric definition of an emergency call

10. Explicit Indicators Construction –Asserter is authorized to assert emergency status of calls (UAC / UAS / proxy) E.g., PSAP, first responder, EMS gateway –Create a signed object that attests to the emergency status of the call Verification –Verify the signed object –Make comparisons to header fields Trust model –Trust in authorization credentialing authority –Call bearing signed object = emergency call

11. Explicit Indicators (cont’d) Pros –Most flexible definition of emergency calls –Doesn’t rely on location in messages –Allows delegation of authentication function, e.g. to gateway or authentication service Cons –Requires credentialing of emergency call marking authorities

12. SIP Embedding No specific solution here, just some requirements / desiderata –Explicit assertion / verification procedures –Minimal increase in complexity of message flows –Should allow for persisting authenticator across messages within a dialog –Should allow for all entities in the signaling path to receive authenticator

13. Embedding Examples Location + URN in INVITE message –Doesn’t work without client location Location + URN in INVITE OR 200 –Allows PSAP to assert based on location INVITE transaction or subsequent UPDATE (within a time period) –The Identity / Connected-Identity model Any message containing a given SIP header field –The RPH / explicit indicator model

14. Questions What approach do we want to take here? Can we agree on one of these authenticators, or do we need more options? –Signed LoST mappings? Do we have other requirements for a SIP embedding?