Doug Bellows – Inteliquent 3/18/2019

1. Customer/End User Identity and Authentication and Process to Determine TN Authorization for SHAKEN Attestation – Potential Methods Doug Bellows – Inteliquent 3/18/2019

2. Originating SP Terminating SP Security services for customer UNI - defined outside of SHAKEN Indirect end-user interface - proxy, b2bua, protocol adaptor, etc. To analytics, display, terminating UNI call control, etc. User Identification User Authentication User-to-TN Authorization UA of direct user/originating SP customer (customer is end-user) UA of Indirect end users STI-AS STI-VS Identity header population/attestation/signing Verify signature, Originating SP Identity, Parameter integrity UA UAi Defined by SHAKEN UAi UA UAi UA of Reseller or VASP customer of Originating SP (customer may not be end user) CSCF CSCF UAi Network-to-Network Interface User-to-Network Interface Source: Inteliquent, Inc.

3. UNI Security Services for SHAKEN Attestation • Customer Identity • Determine “real-world identity,” establish identifiers for UNI authentication • Customer authentication • Exchange credentials for UNI authentication (shared secrets, keys/certificates, IP ACLs/protected network paths, etc.), establish authenticated UNI • Authorization to use TNs (determine customer’s “association” to TN) • Positive controls (e.g. screening database) or control by customer agreements and policy, if positive controls are used they are consulted per call Source: Inteliquent, Inc.

4. Possible Method for Exchanging Customer TN Authorizations between Assigning and Originating SPs • Originating SP AND assigning SP establish customer identity • Customer “real-world identity” determined e.g. by EV methodology, SPs authenticate customer’s right to the identity, e.g. by a PKI signature tied to an EV certificate. Customer identity must use a globally recognizable and verifiable identifier (e.g. X.509 DN or other unique and verifiable attribute). • Customer authentication • Originating SP bilaterally establishes and uses customer UNI credentials as usual • Authorization to use TNs (determine customer’s “association” to TN) • Assigning SP provides a “letter of authorization” to originating SP declaring TN assignment to customer (signed digital document containing customer ID and list of assigned TNs). Originating SP populates TNs in “authorized TN” database Source: Inteliquent, Inc.

5. Assigning SP Admin Plane Originating SP Admin and Service Planes And/Or Identity proofing/credentials exchange TN Assignment Identity proofing/credentials exchange TN Assignment CustID:TNAuth Universally verifiable ID (e.g. EV certificate methods) Customer Entity Cust ID Credentials UA User Identification User Authentication User-to-TN Authorization Standard UNI authentication and session setup STI-AS CSCF To IP-NNI User-to-Network Interface Source: Inteliquent, Inc.

6. Assigning SP Admin Plane Originating SP Admin and Service Planes And/Or Identity proofing/credentials exchange TN Assignment Identity proofing/credentials exchange TN Assignment LoA (CustID:TNAuth) CustID:TNAuth Universally verifiable ID (e.g. EV certificate methods) Customer Entity CustID Credentials UA User Identification User Authentication User-to-TN Authorization Standard UNI authentication and session setup STI-AS CSCF To IP-NNI User-to-Network Interface Source: Inteliquent, Inc.

7. Assigning SP Admin Plane Originating SP Admin and Service Planes And/Or Identity proofing/credentials exchange TN Assignment Identity proofing/credentials exchange TN Assignment LoA (CustID:TNAuth) CustID:TNAuth Multiple Indirect end users Customer Entity (Reseller/VASP) CustID Credentials UA User Identification User Authentication User-to-TN Authorization UAi UAi UAi STI-AS UAi Indirect interface CSCF To IP-NNI TN traces to customer – customer responsible for traceability to subtending end user entities User-to-Network Interface Source: Inteliquent, Inc.

8. Extending TN authorization exchange to indirect end users – administrative plane • Assigning SP Identifies and assigns TNs to end user entity • Same type of identity proofing as for customer TN authorization • Customer identifies end user and provides end user identity to originating SP • Assigning SP sends LoA tied to end user identity (EuID) to originating SP. Originating SP populates an end-user authorization database and authorized TN database. Source: Inteliquent, Inc.

9. Assigning SP Admin Plane Originating SP Admin and Service Planes Identity proofing/credentials exchange TN Assignment LoA (EuID: TN Auth) CustID:EuIDAuth EuID:TNAuth Indirect End User Entity Customer Entity (Reseller/VASP) CustID Credentials UA User Identification User Authentication User-to-TN Authorization EuID Credentials UAi EU Auth Request (CustID:EuIDAuth) STI-AS CSCF To IP-NNI TN traces to end user entity, end user authorized by customer User-to-Network Interface Source: Inteliquent, Inc.

10. Extending TN authorization exchange to indirect end users – service plane • Customer authenticates end user • Choices at customer UNI to originating SP: • Proxy authentication (only customer authenticates EU and passes EuID with call) – problematic from a “spoof-ability” standpoint • Customer passes through authentication transaction between EU and originating SP using shared credentials, or passes through signature with call (like TNPoP but certs tied to EuID not TN) • Originating SP checks EuID:TN authorization database for a match. Source: Inteliquent, Inc.

11. Originating SP Admin and Service Planes CustID:EuIDAuth EuID:TNAuth Indirect End User Entity Customer Entity (Reseller/VASP) CustID Credentials UA User Identification User Authentication User-to-TN Authorization EuID Credentials UAi Pass-through authentication of EU more secure than proxy authentication STI-AS Indirect interface CSCF To IP-NNI TN traces to end user entity, end user authorized by customer User-to-Network Interface Source: Inteliquent, Inc.

12. Other considerations • Customer TN authorization via LoA requires only administrative plane changes, no change in service plane • End-user authorization requires an additional authorization step (EuID to CustID) and an additional authentication relationship (EU to originating SP) • Limits credentials that need to be exchanged in real time • In exchange for TN authorization, end-user identity is exposed to additional parties (customer’s originating SPs) to assure traceability Source: Inteliquent, Inc.

13. Delegation • TN Assignee: • Customer • Customer’s customer (C2) • Third-party assignee • End-user (entity originating the call): • Customer • Customer’s customer (Indirect end-user) • Additional indirection levels (C3-n) Source: Inteliquent, Inc.

14. Delegation • Delegation (assignee delegates TN use to EU): • C2to Customer • Customer to C2 • Third-party to Customer • Third-party to C2 • Etc. • Assigning SP would need to track delegation relationships and provide an additional LoA indicating both the assignee and the EU authorized by the assignee • There may be two (or more) LoAs for the same TN, one for the assignee directly and one for each delegate, tied to different EU identities Source: Inteliquent, Inc.

15. Assigning SP Admin Plane Originating SP Admin and Service Planes TN Assignment Identity proofing/credentials exchange LoA (3P->EuID: TN Auth) EuID:TNAuth CustID:EuIDAuth 3rd party assignee 3P->EuID:TNAuth Indirect End User Entity User Identification User Authentication User-to-TN Authorization Customer Entity (Reseller/VASP) CustID Credentials UA EuID Credentials UAi STI-AS CSCF To IP-NNI EU Auth Request (CustID:EuIDAuth) Source: Inteliquent, Inc.

16. Takeaways • Authenticating customers and end users removes some of the ambiguity of relying on the TN identifier by itself and requires fewer credentials • Requires a consistent identity scheme for TN assignees and service users • Moves the complexity of authorization management to the administrative plane – fewer changes to the service plane Source: Inteliquent, Inc.