1. Proposed Changes to STI-VS "iat" freshness check

2. Current SHAKEN procedures for verifying "iat" freshness
"iat" freshness verification procedures in ATIS 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 – "div" PASSporT spec
ATIS refers to ATIS 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

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

4. 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: T 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"

5. 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: T 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"

6. 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:T sec
orig/div/derst = a/c/d }
Compare "iat" to current time;
freshness window = 60 sec
Identity: div PASSporT{ iat:T 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}

7. Proposed action
Update ATIS 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