STIR and SHAKEN Framework Overview. IIT Real-Time Conference 2016 Chris Wendt

Transcription

1 STIR and SHAKEN Framework Overview IIT Real-Time Conference 2016 Chris Wendt 1

2 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

3 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

4 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

5 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

6 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

7 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 3GPP Certificate Management/Administration TS signaling verification status, WID & CR in progress TS 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: ;verstat=tn-validation-passed 7

8 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

9 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: eyj0exaioijwyxnzcg9ydcisimfszyi6ikvtmju2iiwiedv1ijoiahr0chm6ly9j ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9. eyjpyxqioiixndqzmja4mzq1iiwib3ruijoimtixntu1nteymtiilcjkdxjpijoi c2lwomfsawnlqgv4yw1wbguuy29tin0. SQ3r3U9kew2e4Ej-tS4vbWQgs9kSQzHgzqK_xP4TL70al7XwWwF4R2mP9sxQey9n pzqoytnx_wzsljjpic_f_a 9

10 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

11 Map between SIP message and PASSporT claims SIP INVITE INVITE SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bk776asdhds Max-Forwards: 70 To: Bob user=phone> From: Alice user=phone>;tag= Call-ID: CSeq: INVITE Date: Sat, 13 Nov :29:00 GMT Identity: sv5cto05kqpsmtht3dceio/1cwts ZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzoeU 7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI 3d7SyN21yNDo2ER/Ovgtw0Lu5csIppPqOg1uX ndzhbg7mr6rl9bnuhhufvrbp51mn3w0gfus; info=< biloxi.cer>;alg=es256 Contact: Content-Type: application/sdp Content-Length: 142 Header { alg :"ES256", "typ":"passport", x5u :" biloxi.cer" } Claim { "iat": , "dtn":" ", "otn":" "} 11

12 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

13 SHAKEN Reference Architecture Certificate provisioning portal HTTPS TN-CR HTTPS STI-AS HTTPS STI-VS SKS SIP SIP SIP CSCF SIP SIP CSCF SIP SIP SIP UA RTP IBCF/TrGW RTP IBCF/TrGW SIP UA Service Provider A Originating/Authorization Service Provider B Terminating/Verification 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

14 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

15 Example SHAKEN PASSporT extension Protected Header { alg : ES256, ppt : shaken, typ : passport", "x5u":" } Payload { attest : A dest :{ tn : "} iat : , orig :{ tn :" "}, origid : 123e4567-e89b-12d3-a } 15

16 SHAKEN - Telephone Authority Model Private Key SKS TAMS CSR ACME SP-KMS Public Key TN-CR HTTPS Public Interface 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

17 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

18 Telephone Authority Administration/Security 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. 18

19 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 Interoperability tests at SIPit and ATIS Testbed Focus Group 19

20 Vesper - open source STIR/SHAKEN implementation 20