Proposed Changes to STI-VS "iat" freshness check

Current SHAKEN procedures for verifying "iat" freshness "iat" freshness verification procedures in ATIS-1000074 and RFC 8224 Compare "iat" value with current time If difference > than freshness window, then verification fails RFC 8224 recommends a freshness window of 60 seconds Procedures are not modified by ATIS-1000085 – "div" PASSporT spec ATIS-1000085 refers to ATIS-1000074 and ietf-draft-stir-passport-divert ietf-draft-stir-passport-divert refers to procedures in RFC 8224 End-result Initial "shaken" PASSporT and all "div" PASSporTs must all be fresh (60 sec window) for verification to pass

Legitimate call features can cause SHAKEN PASSporT to become stale Call-forwarding-no-answer (CFNA) No-answer timeout may be almost 60 seconds Any call setup delay in addition to CFNA could result in "iat" freshness failure Call is queued for some reason, and then retargeted Terminating network queues INVITE waiting for attendant/idle hunt-group member/etc. When INVITE is dequeued, some other feature interaction (like call-forwarding) causes INVITE to be retargeted to a remote user Stale shaken PASSporT fails verification Blind call transfer A calls B (INVITE contains fresh shaken PASSPorT) A and B talk for an extended period (shaken PASSporT becomes stale) B blind-transfers A to C – user C sees incoming call from user A If transfer is done using 3PCC procedures (typical) then transfer-to INVITE to C contains original (and now stale) shaken PASSporT from A

Call Queuing Call Flow SP-a SP-b SP-c [1] INVITE TN-b PAID:TN-a; To:TN-b; Date: T1 Identity: shaken PASSporT { iat=T1, orig/dest=a/b} STI-VS result: Verification passed INVITE queued for 2 minutes INVITE retargeted to remote TN-c STI-AS performs "div" authentication and adds 2nd Identity header [2] INVITE TN-c PAID:TN-a; To:TN-b; Date: T1+ 120 sec; Identity: shaken PASSporT {iat=T1, orig/dest=a/b}; Identity: div PASSporT {iat=T1+120 sec, orig/div/dest=a/b/c} Diversion: TN-b STI-VS result: Verification failed due to stale shaken "iat"

Blind Transfer Call Flow SP-a SP-b User B [1] INVITE TN-b STI-VS result: Verification passed PAID:TN-a; To:TN-b; Date: T1 Identity: shaken PASSporT { iat=T1, orig/dest=a/b} [2] INVITE TN-b PAID:TN-a, Verstat=TN-Validation-Passed; To:TN-b; Date: T1 2-way talk for 2 minutes After 2 minutes, initiate blind xfer to C [3] REFER TN-a Refer-To; TN-c Orchestrate blind xfer via 3rd-party-call-control STI-AS performs "div" authentication and adds 2nd Identity header SP-c [4] INVITE TN-c PAID:TN-a; To:TN-b; Date: T1+ 120 sec; Identity: shaken PASSporT {iat=T1, orig/dest=a/b}; Identity: div PASSporT {iat=T1+120 sec, orig/div/dest=a/b/c} Diversion: TN-b STI-VS result: Verification failed due to stale shaken "iat"

Proposed Solution Relax STI-VS freshness check when “div” PASSport(s) received Most recently added PASSporT must meet 60 second freshness window Freshness window for earlier PASSporTs is extended (10 minutes recommended) Example: One additional rule If most recently added PASSporT is stale (based on 60 sec freshness window), then STI-VS shall remove all received PASSporTs Avoids making a stale replayed PASSporT look fresh to downstream verifiers if INVITE is retargeted INVITE TN-d; PAID: Tn-a; To: TN-b; Date: TN1+150 sec; Identity: div PASSporT{ iat:T1 + 150 sec orig/div/derst = a/c/d } Compare "iat" to current time; freshness window = 60 sec Identity: div PASSporT{ iat:T1 + 120 sec orig/div/dest = a/b/c} Compare "iat" to "iat" of next later PASSporT up the chain; freshness window = 10 minutes Identity: shaken PASSporT{ iat:T1 orig/dest = a/b}

Proposed action Update ATIS-1000085 STI-VS procedures to mandate support for proposed modifications to "iat" freshness checks New procedures apply only to networks that support "div" PASSporT New requirement to remove of all PASSporTs when most recent PASSporT is stale applies whether INVITE contains a single shaken PASSporT, or shaken PASSporT plus one or more div PASSporTs