1. IPNNI SHAKEN Enterprise Models: LEMON TWIST
March 18, 2019
Mary Barnes, iconectiv Industry Solutions
CONFIDENTIAL - RESTRICTED ACCESS This document and the confidential information it contains shall be distributed, routed or made available solely to authorized persons having a need to know within iconectiv, except with written permission of iconectiv.
Telcordia Technologies, Inc. dba iconectiv.

2. Terms, Principles and Problem statement
TN Provider is the SP who has been assigned the TNs that the Enterprise (aka TN Customer) is using to make outgoing calls
Originating SP is the service provider that handles the outgoing calls (aka Connected SP) at the point at which they are entering the PLMN
Need to decide requirements for content and semantics of Identity header field and PASSporT (including RCD) generated by the Enterprise at call origination.
Need to determine requirements for Originating SP for content and semantics of Identity header field/PASSPorT added to the incoming SIP INVITE.
CONFIDENTIAL - RESTRICTED Access See confidentiality restricstions on title page

3. Requirements
The Originating SP should always authenticate and add an Identity header field:
Depending upon level of trust in the TN provider, the Originating SP sets the Attestation to A or B.
The calling party identity of the TN customer must be authenticated and authorized by the Originating SP through some means – direct or indirect
CONFIDENTIAL - RESTRICTED Access See confidentiality restricstions on title page

4. Scenarios and related requirements (1)
Originating SP is the TN Provider.
Originating SP should sign with an attestation of “A” if it has a trust relationship with the TN Customer.
Originating SP may allow a TN Customer provide an Identity header field with an RCD PASSport.
Originating SP is not the TN Provider
The calling party identity must be authenticated and authorized by the Originating SP through some means – direct or indirect
If the originating SP has a trust relationship with the TN customer, it may not require an Identity header field in the INVITE from the TN customer
If the originating SP does not have a trust relationship, it should expect an incoming INVITE to contain a SIP Identity header field.
If not authenticated then the originating SP should set the attestation to ‘B’
CONFIDENTIAL - RESTRICTED Access See confidentiality restricstions on title page

5. Scenarios and related requirements (2)
3. Originating SP is not the TN Provider & Originating SP has no relationship with the TN Customer. SIP INVITE may have passed through one or more intermediaries prior to reaching the Originating SP.
The calling party identity must be authenticated and authorized by the Originating SP
Should the originating SP expect an incoming INVITE to contain a SIP Identity header field added by the TN customer?
If not, then attestation should be set to ‘B’.
If there is an Identity header field, the originating SP can authenticate the TN customer’s identity
4. Others?
CONFIDENTIAL - RESTRICTED Access See confidentiality restricstions on title page

6. Solution Options TN-PoP 2.0
Lemon-Twist (LEveraging MOdels for Enterprise dialiNg - TNauthlist With an enterprise Identity Secured Token)
CONFIDENTIAL - RESTRICTED Access See confidentiality restricstions on title page

7. TN PoP 2.0 Model Focus remains scenario 2?
Utilizes delegated certificates as described in RFC 8226 and draft-peterson-:
Adds cross certificates to the model based on RFC 5280:
SP hosts a CA delegated by one of the STI-CAs:
Enterprise requests certificate from SP CA
Key advantages:
Removes the ACME proxy from TN-PoP solution
Uses standard PKI functions for delegation
Disadvantages:
Increases complexity:
Additional fields in certificates
Additional criteria to be considered and established by the CP/CPS (currently states no cross certificates)
More complex certificate path validation at the STI-VS
Increases # certificate chains to manage
More complex traceback and debugging
SP now manages a PKI instance
CONFIDENTIAL - RESTRICTED Access See confidentiality restricstions on title page

8. LEveraging MOdels for Enterprise dialiNg (Lemon) - TNs With an enterprise Identity Secured Token (TWIST) (1)
Based on Trust Authority model developed for STI-PA:
Introduces a Trust Anchor (TA) logical function for supporting SPs Enterprise customers
Trust Anchor provides a subset of functionality provided by the STI-PA
TA supports API for Authority Token Acquisition
A unique identifier is assigned by the SP for the TN Customer:
Concatenation of SPC with an additional identifier assigned by the SP
SP configures account with the TA with the identifiers
SP provides the Enterprise with credentials to obtain an SPC token from the TA, removing SP/TN Provider from any subsequent interactions
Input to token generation includes SPC+id and TNs
The Trust Anchor may be supported in the STI-PA or by another entity with which the SP has an equivalent trust relationship
for managing SP specific accounts and numbering
CONFIDENTIAL - RESTRICTED Access See confidentiality restricstions on title page

9. LEveraging MOdels for Enterprise dialiNg (Lemon) – TNs With an enterprise Identity Secured Token (TWIST) (2)
Defines a new type of attestation:
A’: Implies Full attestation – originating SP has verified the identity that has been authenticated and authorized by another SP in the SHAKEN ecosystem
Provides the terminating provider with more comprehensive information about the call, possibly including a unique ‘verstat’ value
Originating SP does not need to verify the SIP Identity header field added by the enterprise:
Passes the SIP Identity header field as received from the enterprise
Originating SP can add an additional SIP Identity header field with attestation ‘A’ depending upon relationship with Enterprise
CONFIDENTIAL - RESTRICTED Access See confidentiality restricstions on title page

10. SHAKEN LEMoN TWIST Interfaces
Trust Anchor/STI-PA
STI
Certification
Authority
Protocol/API
Human I/F
DataBase I/F
SPC Token Cert
CRL
Authority Token
Authority
Token
Enterprise
CRL URL
List of CAs
Credentials for Authority Token API &
URLs for List of STI-CAs
Enterprise Account with TNs for each SPC+id
Service Provider
CONFIDENTIAL - RESTRICTED Access See confidentiality restrictions on title page

11. Summary – LEMoN TWIST Model is consistent with core SHAKEN:
Trust is based on secure token provided by the entity that has been given authority over the TNs
Gives enterprises flexibility in choosing an STI-CA
Reduces burden on SP’s role in certificate acquisition
Doesn’t require more complex certificate delegation model
Reduces processing burden on originating SP
TN Customer directly interfaces with an STI-CA
More transparent – terminating SP recognizes call as being from an authorized user of SP-x’s TNs – consistent with the “What do we know and how do we know it model”
Enterprise isn’t relegated behind the SP in the SHAKEN ecosystem
No new PKI requirements (no new IETF dependency)
Hosting in the STI-PA simplifies SP account management
CONFIDENTIAL - RESTRICTED Access See confidentiality restricstions on title page

12. Overall Comparison: TN-PoP 2.0 and Lemon Twist
SHAKEN
Who issues
Certificate
Delegated CA in SP’s domain
Any trusted STI-CA
(selected by Enterprise)
Any trusted STI-CA (selected by SP)
Input for Authority Token acquistion
TBD
SPC+id, TNs
SPC
Challenge-response mechanism
TN Customer’s Authority token issued by TA (or STI-PA)
SP’s Authority token issued by the STI-PA
CONFIDENTIAL - RESTRICTED Access See confidentiality restricstions on title page

13. Functional Impacts: TN-PoP’ and Lemon Twist
New SP functionality (KMS)
Delegated CA in SP’s domain
Input to trust authority for authority token = SPC+id, TNs
Certificate generation (KMS and STI-CA)
Requires more complete standardization for delegated certificates for STIR*
Same as SHAKEN
Challenge-response mechanism (KMS and STI-CA)
TBD (see certificate generation)
Certificate path validation (STI-VS)
More complex due to delegated (cross) certificates**
Authentication (STI-AS)
None
Sets Attestation to A’ * **
“This can be a bit messy when delegating from SPC to TN ranges, but that messiness probably isn’t avoidable.”
CONFIDENTIAL - RESTRICTED Access See confidentiality restricstions on title page

14. Questions ???