SHAKEN for 9-1-1 Presented to: Ericsson Contact: 2019-08-07 SHAKEN for 9-1-1 Presented to: Ericsson Contact: PTSC/IP-NNI Terry Reese August 7-8, 2019 +1 908 581 5690 theresa.reese@ericsson.com

2019-08-07 Overview Discuss potential impacts on ATIS activities and documentation related to applying SHAKEN architecture and procedures to 9-1-1 calls and callback calls Which groups are potentially impacted? Which documents may need to be updated? What issues must be addressed when considering the application of SHAKEN to 9-1-1 calls and callback calls? What contributions are needed to support SHAKEN for 9-1-1 calls/callback calls?

Impacted ATIS Groups PTSC/IP-NNI Task Force 2019-08-07 PTSC/IP-NNI Task Force IP-NNI Task Force has responsibility for SHAKEN-related standards: ATIS-1000074, Signature-based Handling of Asserted information using toKENs (SHAKEN) ATIS-1000080, Signature-based Handling of Asserted information using toKENs (SHAKEN): Governance Model and Certificate Management ATIS-1000081, ATIS Technical Report on a Framework for Display of Verified Caller ID ATIS-1000082, Technical Report on SHAKEN APIs for a Centralized Signing and Signature Validation Server ATIS-1000084, Technical Report on Operational and Management Considerations for SHAKEN STI Certification Authorities and Policy Administrators ATIS-10000XX, Session Initiation Protocol Resource Priority Header (SIP RPH) Signing using PASSPorT Tokens (DRAFT)?

Impacted ATIS Groups ESIF NGES/IMS911 WTSC IMSESINET 2019-08-07 ESIF NGES/IMS911 ATIS-0500032, ATIS Standard for Implementation of an IMS-based NG9-1-1 Service Architecture ATIS-0500036, ATIS Standard for IMS-based Next Generation Emergency Services Network Interconnection WTSC IMSESINET ATIS-0700015, ATIS Standard for Implementation of 3GPP Common IMS Emergency Procedures for IMS Origination and ESInet/Legacy Selective Router Termination

ATIS-1000074 2019-08-07 Terminology Authentication Service (STI-AS) – The SIP application server that performs the function of the authentication service defined in RFC 8224 Verification Service (STI-VS) – The SIP application server that performs the function of the verification service defined in RFC 8224 It has a Hypertext Transfer Protocol Secure (HTTPS) interface to the Secure Telephone Identity Certificate Repository that is referenced in the Identity header field to retrieve the provider public key certificate Secure Key Store (SKS) – a logical highly secure element that stores secret private key(s) for the authentication service (STI-AS) to access Call Validation Treatment (CVT) –a logical function (i.e., an application server function or a third party application) for applying anti-spoofing mitigation techniques once the signature is positively or negatively verified. The CVT can also provide information in its response that indicates how the results of the verification should be displayed to the called user Certificate Repository (STI-CR) - Publicly accessible store for public key certificates

ATIS-1000074 SHAKEN Reference Architecture 2017-0303 ATIS-1000074 SHAKEN Reference Architecture CVT – Call Validation Treatment SKS – Secure Key Store STI-AS – Secure Telephone Identity Authentication Service STI-CR – Secure Telephone Identity Certificate Repository STI-VS – Secure Telephone Identity Verification Service

ATIS-1000074 2019-08-07 The SHAKEN Authentication process specified in ATIS-1000074 relies on the use of standard PASSporT claims (as specified in RFC 8224 and RFC 8225) with the following restrictions: The “orig” claim and “dest” claim shall be of type “tn”. The “orig”’ claim “tn”’ value shall be derived using the following rules: The P-Asserted-Identity header field value shall be used as the telephone identity, if present, otherwise the From header field value shall be used If there are two P-Asserted-Identity header field values, the authentication service shall have logic to choose the most appropriate one based on local service provider policy The action taken under the following conditions is outside the scope of this document: There are P-Asserted-Identity header(s) present, but not one that contains a tel URI identity with a valid telephone number, or There are no P-Asserted-Identity header(s) present, and the From header does not contain a tel URI identity with a valid telephone number

2017-0303 ATIS-1000074 The "dest" claim "tn" value shall be derived using the following rules: The canonicalized value of the TN in the To header field value shall be used as the telephone identity The action taken when the To header field does not contain a tel URI identity with a valid telephone number is outside the scope of the SHAKEN framework There may be circumstances where the To header TN does not match the Request-URI TN This can occur in the case of toll-free routing, where the To header field contains the 8YY number, while Request-URI contains the routing number for that 8YY number Performing SHAKEN authentication in these circumstances can cause terminating verification services to ignore legitimately authenticated calls If allowed by local policy, the originating network can avoid these false verification results by updating the To header TN to match the Request-URI TN before performing SHAKEN authentication.

2017-0303 ATIS-1000074 The SHAKEN Verification Service utilizes procedures defined in RFC 8224, including the methods used to verify the signature contained in the Identity header field The STI-VS shall determine the validity of the certificate referenced in the “x5u” field in the PASSporT The verifier validates that the PASSporT token provided in the Identity header of the INVITE; this includes all of the baseline claims and the SHAKEN extension claims, as well as checking the date, originating identity (i.e., the originating telephone number) and destination identities (i.e., the terminating telephone numbers) The terminating network conveys the verification result to the called user by including a “verstat” parameter in the From and/or P-Asserted-Identity header fields of the INVITE request sent to the called endpoint device, as defined in 3GPP TS 24.229

2017-0303 ATIS-1000074 The SHAKEN Verification Service includes the following restrictions: The “orig” claim and “dest” claim shall be of type “tn”. The “orig” claim “tn” value validation shall be performed as follows: The P-Asserted-Identity header field value shall be checked as the telephone identity to be validated if present, otherwise the From header field value shall also be checked. If there are two P-Asserted-Identity values, the verification service shall check each of them until it finds one that is valid. The “dest” claim "tn" value shall be validated using the canonicalized value of the To header field TN, subject to the following considerations: If the value of the Request-URI TN does not match the value of the TN in the To header field, then the verifier shall skip verification, and treat the verification event as if no Identity header was received As an optional enhancement to the above exception, if the verifier is able to determine that the mismatching TNs in the Request-URI and To header field identify the same destination, then it may perform normal SHAKEN verification

2017-0303 ATIS-1000074 The SHAKEN Verification Service includes the following restrictions: (cont.) For calls that contain a SIP Resource Priority Header (RPH) field, post STI-VS information must not be passed for Call Validation Treatment (CVT). This is to ensure the highest probability of call completion for these types of calls.

2017-0303 SHAKEN for 9-1-1 Emergency Services Signaling Characteristics of 9-1-1 calls A SIP INVITE associated with an emergency origination will include a Request-URI that contains a service URN in the ‘sos’ family (e.g., urn:service:sos) Based on 3GPP TS 24.229 and ATIS-0700015, the To header in a SIP INVITE associated with an emergency origination will also contain the ‘sos’ service URN (although the NENA i3 standard also allows the To header to contain the digits “911” expressed as a URI) ATIS-1000074 does not currently support “dest” claims that are not of type “tn”; RFC 8224 does support a “dest” claim of type “uri” If the To header contains “911” expressed as a URI, then the To and Request-URI will not match From and P-Asserted-Identity headers associated with an emergency origination will contain the callback URI associated with the emergency caller

2017-0303 SHAKEN for 9-1-1 Emergency Services Signaling Characteristics of 9-1-1 calls (cont.) Within an NG9-1-1 Emergency Services Network, a SIP INVITE associated with an emergency origination will contain a Resource-Priority Header (RPH) set to esnet.1 If the SIP INVITE does not contain an RPH set to esnet.1 when it reaches the BCF at the ingress edge of the NG9-1-1 Emergency Services Network, the BCF will insert it 3GPP TS 24.229, Section 4.11 allows an RPH in the “esnet” namespace to be inserted by an entity identifying an emergency call, i.e., a P-CSCF or IBCF; SIP INVITE in originating IMS network may or may not contain an RPH in the “esnet” namespace ATIS-1000074 specifies that calls that contain an RPH must not be passed for Call Validation Treatment; CVT could provide useful information in the context of 9-1-1 calling, e.g., to support the identification and mitigation of TDOS attacks Discussion at AMOC about making access to CVT dependent on the specific RPH namespace/value

2017-0303 SHAKEN for 9-1-1 Emergency Services Signaling Characteristics of Callback calls A SIP INVITE associated with an emergency callback will include a Request-URI and a To header that contain the callback URI (from the PAI or From header in the emergency request) The From and PAI headers in a SIP INVITE associated with an emergency callback will contain a TN that is associated with the PSAP that is originating the callback A SIP INVITE associated with an emergency callback may include a SIP Privacy header, depending on the nature of the emergency The SIP INVITE associated with an emergency callback will include a SIP Priority header field with the value “psap-callback” (per RFC 7090) A SIP INVITE associated with an emergency callback will contain a Resource-Priority Header (RPH) set to esnet.0 Geolocation and Geolocation-Routing headers will not be present in a SIP INVITE associated with an emergency callback

SHAKEN for 9-1-1 Emergency Services Network Considerations 2017-0303 SHAKEN for 9-1-1 Emergency Services Network Considerations An NG9-1-1 Emergency Services Network must be capable of verifying SIP INVITE messages associated with emergency originations that contain RFC 8224 Identity headers A “verstat” parameter will be sent to the PSAP in the PAI and/or From headers of SIP INVITE associated with emergency origination Should Emergency Services Network support access to CVT? Discussion about allowing it for emergency calls even though ATIS-1000074 does not allow it where a Resource-Priority header is present Can use RPH value/namespace to determine whether CVT should be invoked; within an ESInet, ALL emergency calls will have an RPH value in the “esnet” namespace Operator policy should also be considered How should the “dest” claim be derived if the To header contains an sos service URN?

SHAKEN for 9-1-1 Emergency Services Network Considerations (cont.) 2017-0303 SHAKEN for 9-1-1 Emergency Services Network Considerations (cont.) Need to ensure that SHAKEN verification can be performed if: Both the To header and the Request-URI contain an sos service URN Requires support for dest claims of type “uri” (or possibly new type “urn”) The To header contains the digits “911” expressed as a URI and the Request-URI contains an sos service URN Need to recognize that both the To and Request-URI are associated with the same destination and perform SHAKEN verification Need ability to assert PSAP TN for callback calls and address scenarios where privacy/presentation restriction is required

SHAKEN for 9-1-1 Potential Originating Network Considerations 2017-0303 SHAKEN for 9-1-1 Potential Originating Network Considerations What are the potential impacts on ATIS-1000074? Section 5.2.1, PASSporT & Identity Header Construction Need to allow the “dest” claim to be of a “type” that is appropriate for a service URN RFC 8224 defines a “type” with a value of “uri”, however RFC 8224 talks about the process of “normalizing” the uri and transforming SIP and SIPS URIs into a canonical form before they can be provisioned in PASSporT claims as type "uri“ Since an sos service URN is not in the form of “sip:” , it doesn’t seem that the normalization procedures described in Section 8.5 of RFC 8224 apply Do we need to define a new “type” with a value of “urn” to support “dest” claims that consist of sos service URNs? e.g., "dest" : {"urn":["urn:service:sos”]}

SHAKEN for 9-1-1 What are the potential impacts on ATIS-1000074? 2017-0303 SHAKEN for 9-1-1 What are the potential impacts on ATIS-1000074? Section 5.2.1, PASSporT & Identity Header Construction (cont.) If the To header value and the Request-URI value don’t match, current text allows (based on local policy) the originating network to update “the To header TN to match the Request-URI TN before performing SHAKEN authentication” If the To header contains “911” and the service URN contains an sos service URN, it is not necessary for the originating network to update the To header to match the Request-URI More complicated since the values of the To header and Request-URI are of different types Consider leaving the To header and Request-URI unchanged, and apply similar logic in the terminating network as for the optional enhancement described in Section 5.3.1 to support toll-free calls (i.e., if the verifier is able to determine that the mismatching values in the Request-URI and To header field identify the same destination, then perform normal SHAKEN verification)

SHAKEN for 9-1-1 What are the potential impacts on ATIS-1000074? 2017-0303 SHAKEN for 9-1-1 What are the potential impacts on ATIS-1000074? Section 5.3.1, PASSporT & Identity Header Verification Allow “dest” claim to either be of type “tn” or type “uri” (or “urn”) “dest” claim values of type “tn” will follow the validation procedures described in Section 5.3.1 What validation procedures should be performed if the “dest” claim is of type “uri” (or “urn”)? Include text in Section 5.3.1 that states the following: “If the To header contains a TN that is an emergency service number and the Request URI contains an emergency service URN, the verifier shall perform normal SHAKEN verification.”

SHAKEN for 9-1-1 What are the potential impacts on ATIS-1000074? 2017-0303 SHAKEN for 9-1-1 What are the potential impacts on ATIS-1000074? Section 5.3.4, Handing of Calls with Signed SIP Resource Priority Header Field Current text states that for calls that contain a SIP Resource Priority Header (RPH) field, post STI-VS information MUST not be passed for Call Validation Treatment (CVT) Based on discussions during joint session at AMOC, it may be desirable to allow 9-1-1 originations (and possibly callback calls) to access CVT, based on local policy This would require a change to Section 5.3.4 of ATIS-1000074 to allow access to CVT to be based on the RPH namespace/value (as well as local policy) More general question about the use (and authentication and validation) of a signed RPH in the context of 9-1-1 calls and callback calls

SHAKEN for 9-1-1 RPH Signing 2017-0303 SHAKEN for 9-1-1 RPH Signing RFC 8443, Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization, extends RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the SIP RPH There is text in RFC 8443 which states: “This PASSporT object is used to provide attestation of a calling-user authorization for priority communications. This is necessary in addition to the PASSporT object that is used for calling-user telephone-number attestation.” This concept seems to make more sense in the context of an NS/EP call than a 9-1-1 call Not all callers are allowed to originate NS/EP calls For NS/EP you want to protect against attack scenarios where a threat agent is populating the RPH of ordinary calls for the purpose of security attacks

SHAKEN for 9-1-1 RPH Signing (cont.) 2017-0303 SHAKEN for 9-1-1 RPH Signing (cont.) In the case of NS/EP you need only sign the RPH if the call is internetwork If the RPH in a call is not signed, or if a signed NS/EP call fails validation, then the receiving carrier can make a local decision to treat the call as an ordinary call as opposed to providing priority treatment For 9-1-1 calls, by regulation, anyone must be able to make a 9-1-1 call – even callers using non-initialized mobile devices In the context of 9-1-1, what does a signed RPH mean? That the originating service provider asserts that they recognized the call as an emergency origination and populated the RPH That the Emergency Services Network provider can trust that the RPH was populated by the originating service provider, as opposed to being inserted by a threat agent As for caller ID authentication/verification, an unverified RPH should not result in an emergency call being blocked; could impact information displayed at the PSAP

SHAKEN for 9-1-1 RPH Signing (cont.) 2017-0303 RPH Signing (cont.) Are there any performance impacts associated with RPH signing and verification? The current view seems to be that RPH signing will be done as an integrated process with the TN signing so there should be no significant incremental delay by adding the RPH signing to the TN signing process Of course, the application of SHAKEN procedures to 9-1-1 calls MUST NOT result in any significant call setup delay Is there a benefit to signing the RPH associated with callback calls? A signed RPH could indicate that: The Emergency Services Network provider asserts that they recognize the call is a callback call and as such that an RPH value in the ‘esnet’ namespace is appropriate The emergency caller’s serving network provider can trust that the RPH was populated by the Emergency Services Network provider, as opposed to being inserted by a threat agent Note that callback calls are already flagged by carrying a Priority header set to “psap-callback”

SHAKEN for 9-1-1 Potential Originating Network Considerations 2017-0303 Potential Originating Network Considerations What are the Implications for ATIS-0700015? ATIS-1000074 shows the interaction with the STI-AS at an originating network CSCF; should this functionality be incorporated into the E-CSCF? 3GPP TS 24.229 allows the P-CSCF to add a Resource-Priority header in the ‘esnet’ namespace; ATIS-0700015 does not currently address population of RPH in SIP INVITE associated with an emergency origination Should procedures for allowing a P-CSCF to add an RPH associated with emergency originations be documented in ATIS-0700015? Should RPH signing be addressed in ATIS-0700015? 3GPP TS 24.229 and ATIS-0700015 state that Request URI and To are always the same and contain an ‘sos’ service URN SHAKEN procedures need to allow “dest” to be other than type “tn” Update material related to callback, including SHAKEN verification procedures related to callback calls To what extent can ATIS-0700015 just reference ATIS-1000074 for SHAKEN details?

SHAKEN for 9-1-1 Potential Originating Network Considerations (cont.) 2017-0303 SHAKEN for 9-1-1 Potential Originating Network Considerations (cont.) Support for Non-Service Initialized (NSI) handsets Wireless carriers are required to accept 9-1-1 calls from NSI handsets, so PTSC/IP-NNI will need to address this Since non-dialable callback numbers (as defined in J-STD-036) are created/populated by the E-CSCF (per 24.229 and clarified in ATIS-0700015), there will be a callback number included in the SIP INVITE, so the question is whether or how a non-dialable callback number gets authenticated Is this a circumstance in which RPH signing could be useful? Support for roamers Not currently addressed in ATIS-1000074 When mobile callers roam to another network and make a 9-1-1 call, those calls are handled by the visited network and not the home network; different model than non-emergency calls What are the implications of roaming on SHAKEN procedures?

Potential Topics for Contributions 2019-08-07 Potential Topics for Contributions Expansion of “types” associated with “dest” claims to address emergency (‘sos’) service URNs Should a new “type” be defined? If so, does that require interactions with IETF? If so, does that need to happen before a contribution is submitted to IP-NNI? Contribution to IP-NNI to allow To and Request-URI to contain different values, and to apply logic that says that verification should be performed if content of “To” and “Request-URI” are associated with the same destination Contribution to IP-NNI to allow access to CVT after verification for calls with an RPH value in the ‘esnet’ namespace, based on local policy RPH signing and verification for 9-1-1 and callback calls Need to clarify what this means for 9-1-1 and callback calls, and potential interactions with caller ID authentication/verification procedures

Potential Topics for Contributions 2019-08-07 Potential Topics for Contributions Contributions to IMSESINET to address potential impacts on ATIS-0700015 Address impact on E-CSCF to allow it to interact with STI-AS and to include an Identity header in outgoing signaling to an NG Emergency Services Network Address ability of P-CSCF to add RPH in SIP INVITE associated with an emergency origination (and other impacts elsewhere in the architecture, if any, related to RPH signing) Expand section related to callback calls to address possible unique signaling characteristics (e.g., Priority header = “psap-callback”, RPH = “esnet.0”, Identity header), as well as the application of SHAKEN verification processing (most likely by reference to ATIS-1000074) for callbacks to non-roaming emergency callers

Potential Topics for Contributions 2019-08-07 Potential Topics for Contributions Contributions to IMS911 Impacts on ATIS-0500032 proposed in ESIF-IMS911-2019-00029R000 may need to be adjusted based on agreements reached in IP-NNI Impacts on callback information in ATIS-0500032 based on ESIF-IMS911-2019-00030R000, if agreement reached on proposed callback architecture/flow Potential impacts on ATIS-0500032 related to RPH signing (i.e., verification of signed RPH on emergency origination, delivery of signed RPH on callback) Impacts on ATIS-0500036 to address the exchange of SHAKEN- related information between NG Emergency Services Networks on internetwork emergency originations and transfers

2019-08-07