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

2. 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

3. 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

4. UNI Security Model

5. 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

6. 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.

7. NNI Model

8. 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

9. 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).

10. 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

11. 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

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

13. 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 …