STIR and SHAKEN Framework OverviewIIT Real-Time Conference 2016

Chris Wendt

1

Introduction - Telephone Network

The telephone network is a complex set of interconnecting devices and network devices

This has been a positive part of the evolution of how we communicate and use the telephone network

But the negative impact is that bad actors have been able to take advantage of that proliferation

2

Introduction - VoIP Network

The TDM/SS7 equipment in the network is 10’s of years old, the software for these systems hasn’t been touched in years.

Cable world has mostly moved to SIP/VoIP

Mobile world is moving quickly to VoLTE or end to end SIP

There has been a consistent message to industry to sunset the PSTN network and move to all-IP

For call spoofing problem, the only practical place we can solve this problem is in SIP network

3

User Experience

Google and Apple are starting to put in the hooks for supporting call spam warnings

Caller ID on TV would be an obvious place to help alert users to potential spam

Positive verification would also be a beneficial service to offer customers including enhanced verified Caller information

4

Authentication Standards Activities

• Three industry standards body activities related to VoIP calls:

• IETF STIR - defining core protocols and technologies for SIP and certificate usage for applying digital signatures to validate the telephone identity of the calling party

• ATIS SHAKEN - defining the industry framework for using STIR technologies and how service providers will interwork on VoIP based calls

• 3GPP - definition of a ‘verstat’ parameter to carry a verification status from the verification service to a 3GPP managed UE

• These standards are forward looking in the sense that SS7/TDM traffic should be rapidly converting as wireless carriers move to VoLTE calling

5

IETF - Standards Overview

• IETF - protocol related standards

• Base digital signature specification - PASSporT (Persona Assertion Token)

• draft-ietf-stir-passport

• SIP usage of PASSporT

• draft-ietf-stir-rfc4474bis

• Certificate usage definition

• draft-ietf-stir-certificates

• SIP Call-Info Parameters for Labeling and Classifying Calls

• draft-schulzrinne-dispatch-callinfo-spam-00

• A SIP Response Code for Unwanted Calls - defines ‘666’ as unwanted call

• draft-schulzrinne-dispatch-status-unwanted

6

ATIS/3GPP - Standards Overview

• ATIS/SIPForum NNI Task Force SHAKEN (Signature-based Handling of Asserted information using toKENs)

• defines the network architecture and NNI dependencies around the usage of the PASSporT and 4474bis based framework

• SHAKEN framework - defines a service provider profile for the deployment of:

• STIR Authentication Service

• STIR Verification Service

• SHAKEN Certificate framework

• Certificate Management/Administration

• 3GPP

• TS 24.229 – signaling verification status, WID & CR in progress

• TS 29.165 for NNI & X for Verification/Authentication Service Functions

• tel URI parameter in the P-Asserted-Identity or FROM header field in a SIP requests

• Example: P-Asserted-Identity: tel:+14085264000;verstat=TN-Validation-Passed

7

PASSporT Overview

• PASSporT uses the JSON Web Token (JWT) and JSON Web Signature (JWS) formats and defines a standard set of base claims and signature

• secure cryptographic validation of the owner of the claims made

• Claims are a JSON object of key value pairs

• Passport defines a minimum set of claims/key value pairs to assert the identity of the call originator with some additional key pairs for protection against replay and man-in-the-middle attacks

• It is also extensible to cover other scenarios, like CNAM or GETS/WPS, assertion and/or authorization

8

PASSporT Signature• The PASSporT Signature is a standard JWS X.509 based digital

signature of the header and claims.

• There is text specifying the specific canonicalization of the header and claims JSON, including removing white space etc.

• JWT form of the token is <header>.<claims>.<signature>

• Example from draft-ietf-stir-passport:

9

eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IkVTMjU2IiwieDV1IjoiaHR0cHM6Ly9j ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 . eyJpYXQiOiIxNDQzMjA4MzQ1Iiwib3RuIjoiMTIxNTU1NTEyMTIiLCJkdXJpIjoi c2lwOmFsaWNlQGV4YW1wbGUuY29tIn0 . SQ3r3U9kew2e4Ej-tS4vbWQgs9kSQzHgzqK_xP4TL70al7XwWwF4R2mP9sxQey9n pZQoYTNx_WZslJJpIc_f_A

RFC4474bis Overview

• RFC4474bis defines how PASSporT is used in a SIP message

• RFC4474 is deprecated but was the first attempt at signing the entire SIP message, however as we know SBCs like to change SIP headers, so it wasn’t a practical approach.

• RFC4474bis defines three main components

• The syntax of the newly defined “identity” header and a few required parameters. This includes the PASSporT signature.

• Authentication Service - the logical component that creates the PASSporT token signature and puts it in a newly defined “identity” header

• Verification Service - the logical component that validates the PASSport token signature

10

Map between SIP message and PASSporT claims

11

INVITE sip:+12155551213@biloxi.com SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhdsMax-Forwards: 70To: Bob <sip:+12155551213@biloxi.com; user=phone>From: Alice <sip:+12155551212@atlanta.com; user=phone>;tag=1928301774Call-ID: a84b4c76e66710@pc33.atlanta.comCSeq: 314159 INVITEDate: Sat, 13 Nov 2015 23:29:00 GMTIdentity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs;info=<https://biloxi.example.org/

biloxi.cer>;alg=ES256Contact: <sip:alice@pc33.atlanta.com>Content-Type: application/sdpContent-Length: 142

{ “alg”:"ES256", "typ":"passport", “x5u”:"https://biloxi.example.org/

biloxi.cer" }

SIP INVITE Header

Claim{ "iat": “1443208345”, "dtn":"12155551212", "otn":"12155551213"}

SHAKEN Framework Overview

• SHAKEN is an industry framework document that specifies the deployment and interworking points for building a interoperable set of services for STIR

• It provides specifications for both SIP and certificate management deployment for the current VoIP based telephone network and NNI.

• The intent is to evolve the SHAKEN framework over time as participation, functionality, and policy evolves around STIR deployment for VoIP calls over service provider networks.

12

SHAKEN Reference Architecture

• Shown in the context of 3GPP IMS components, but not limited to that

• Defines the logical components needed and a high level call flow

13

CSCF

TN-CR

SIP UA IBCF/TrGW

SIP

RTP

SIP

SIP

RTP

HTTPS

SKS

STI-AS

SIP

HTTPS

IBCF/TrGW

SIPCSCF

SIP

STI-VS

SIP UA

SIP

Service Provider AOriginating/Authorization

Service Provider BTerminating/Verification

Certificate provisioning

portal

HTTPS

SHAKEN PASSporT extension- Attestation and Originating Identifier

• Attestation (attest): The service provider will classify the origination of the call into three categories:

• Full Attestation: The signing provider: 

• is responsible for the origination of the call onto the IP based service provider voice network

• has a direct authenticated relationship with the customer and can identify the customer

• has established a verified association with the telephone number used for the call. 

• Partial Attestation: The signing provider:

• is responsible for the origination of the call onto its IP based voice network

• has a direct authenticated relationship with the customer and can identify the customer

• has NOT established a verified association with the telephone number being used for the call

• Gateway Attestation: The signing provider:

• is the entry point of the call onto its IP based voice network

• has no relationship with the initiator of the call (e.g., international gateways). 

• Originating Identifier (origid):This is a unique and opaque UUID (RFC4122) that will be used for two reasons

• traceback identification of originator, either service provider, wholesale customer, enterprise

• can be used by verification and call spam classification/analytics as an opaque identity to associate reputation scores and identify bad actors to authorities for potential follow up

14

Example SHAKEN PASSporT extension

Protected Header {

“alg”:”ES256”,

“ppt”:”shaken”,

“typ”:”passport",

"x5u":"https://cert.example.org/passport.crt"

}Payload

{

“attest”:”A”

“dest”:{“tn”:”12155551213"}

“iat”:”1443208345”,

“orig”:{“tn”:"12155551212"},

“origid”:”123e4567-e89b-12d3-a456-426655440000”

}

15

SHAKEN - Telephone Authority Model

• Telephone Authority is a new model that corresponds to the Certificate Authority for web/HTTPS

• Uses similar X.509 mechanisms for certificate creation and validation

• Associated with an “authority” for assertion of the ownership of either telephone numbers or the authorization to perform telephone call routing

• Evolve to support for TN or block TN level certificates

16

TN-CR

TAMSCSR

ACMESP-KMS

SKSPrivate

Key

Public Key HTTPS

Public Interface

SHAKEN - Certificate Management

• Start with a straight forward X.509 based CSR key signing mechanism, similar to web certificate authorities today, but likely more manual process for initial deployment

• Move to automated process, adopt ACME based automatic certificate management protocols going forward.

• Forward looking, and likely policy/industry related issues more than technical

• Service provider authorization and verification process, likely number management and other policy decisions will impact this process.

• Definition of how authorities can “revoke” bad actors if necessary using OCSP and other more advanced certificate management techniques.

17

Telephone Authority Administration/Security

18

• Governance Authority - this entity would manage, likely tied with identification and potential prosecution of bad actors, the authority for service providers to originate signed calls to the telephone network

• TA Administrator - this entity would do the manual process of working with service providers to validate they are who they say they are and manage credentials of Telephone Authorities to have a secret key and the Service Providers to do CSR transactions with the Telephone Authorities. They should also have a periodic re-validation and new key issuance, as part of good practice to protect the Telephone Authority services.

• Note: Governance and Administration are two logical functions but could be supported by a common low administrative overhead organization.

• Telephone Authorities - Can process automated CSR requests via ACME protocol from Service Providers creating new certificates

• Service provider - Own and manage a SP certificate key, that they must have signed by TA.

SHAKEN - Status and Next Steps

• STIR documents just finished WGLC in IETF

• SHAKEN SIP profile document in Letter Ballot and Approval process in ATIS and SIP Forum

• SHAKEN Certificate Management Framework document targeted completion for end of year

• FCC Robocalling Strike Force will issue report on 10-26-2016

• Interoperability tests at SIPit and ATIS Testbed Focus Group

19

Vesper - open source STIR/SHAKEN implementation

20

https://github.com/Comcast/vesper