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

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?

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

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

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

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

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

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

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

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

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

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

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

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?