Doug Bellows – Inteliquent 10/4/2018 Draft Attestation and Origination Identifier Framework Technical Report Doug Bellows – Inteliquent 10/4/2018

Draft Attestation and origination ID Framework TR – Contribution IPNNI-2018-00106R000 Adapted from UNI Security Whitepaper Short security analysis of SHAKEN Introduces models for use of SHAKEN in relation to UNI and NNI interfaces Proposed guidelines for attestation population Proposed guidelines for origid population Use cases for attestation in various UNI/NNI scenarios

SHAKEN security services Identifies/Authenticates originating service provider Protect integrity of call parameters Identity header with cryptographic signature and PKI certificates provide both services UNI security is outside the SHAKEN mechanisms

UNI Security Model

UNI Security Model Three applicable security services: Customer/user identity User authentication User-to-TN authorization UNI security has components in the administrative plane and services plane – may also rely on network/transport-layer services

UNI Security Model Per SHAKEN definitions, attestation values rely on application of first two services (value “B”) or all three services (value “A”) “Customer/user” is the direct customer of the SP and not necessarily the end user (reseller/VASP call scenarios). UNI is the interface between the SP and the customer.

NNI Model

Populating Identity header for calls received at an NNI For calls originated by a customer to an SP within the trust domain (e.g. U.S. service providers), Identity header should be populated by the carrier hosting the UNI Some scenarios do not fall into this category, e.g. international gateways Identity headers should be passed as-is across the NNI to and from transit carriers and to terminating carriers. Within the trust domain, calls may arrive at an intermediate NNI without an Identity header (e.g. TDM interfaces, non-SHAKEN-capable SPs). Populating Identity by the intermediate SP may aid traceback but provides less information than population by the originating SP. Assume no direct knowledge of customer/user identity/authentication/authorization, so no attestation values that rely on these services

Origination Identifier Guidelines Origid guidelines re-factor the text in SHAKEN – origid based on UNI or NNI interface characteristics as opposed to an attestation level determined later NNI – origid should be a reference at the granularity of the peer SP or peer SBC/IBCF UNI – granularity depends on the characteristics of the interface and user: If the SP controls calling TN marking (network marking or TN filtering), origid reference may be at a granularity other than UNI or customer (e.g. access network or region) as might be useful for the SP to locate the source. If the customer controls calling TN marking, origid reference should be at the granularity of customer or UNI Privacy concerns – origid is an opaque value outside the originating SP. If tied permanently to a personal/small business UNI it could reveal information on calling patterns not immediately obvious based on calling TN alone. Possibly origid for an individual/small business UNI should not be a permanent reference (e.g. it persists for <24 hours or the length of a SIP registration to drive analytics).

UNI/NNI Use Cases - Customer/TN Identity Direct individual assignment Customer/TN ID may be interchangable Prepaid account Customer may not be strongly identified Enterprise Multiple TNs per customer, possibly multiple SPs Communication reseller TNs assigned to reseller or end user, end users are known only to reseller Value-added service provider Calls may be originated by end user or by VASP, TNs may be assigned to either

UNI/NNI Use Cases – Customer/user authentication Device Device-resident credentials/SIM, cryptographic transaction, other factors Account User-provided credentials (e.g. username/password), SIP registration, other factors Network IP address whitelist, VPN, dedicated connections

UNI/NNI Use Cases – Calling TN authorization/screening SP marking Direct assignment Contract relationship “Letter of Authorization” Independent authorization check Indirect No validation

UNI/NNI Example Use Cases End user Customer/ Inter- connecting entity TN assigned to TN assigned by Identity established by Authentication type Authorization established by Attestation result Mobile subscriber Same as end user Subscriber Originating SP Customer name/address/credit checks Device Direct assignment A Enterprise PBX Enterprise customer Other SP Customer ID/pre-shared key, IP network ACL Letter of Authorization Individual or enterprise VASP Customer name/address/credit checks, end-user traced through customer Customer ID/IP network ACL Direct assignment, terms of use (customer responsible for end use) Non-domestic entity Gateway provider Non- domestic provider/not determined Not determined (gateway provider not the originating SP) Network interconnection Not determined C Reseller Terms of use A or B based on terms enforcement …