Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter)

[Hadriel Kaplan <[e-mail]>]

On Jul 16, 2013, at 10:45 AM, Brian Rosen <[e-mail]> wrote:

> If INSIPID's session ID won't survive end to end, what do you suggest we use here to avoid replay?

We just need to put something into the new header we create for the signature and other stuff.  That's what both draft-kaplan-sip-asserter-identity and draft-kaplan-stir-ikes-out-00 do.  RFC4474 used the Call-ID and Cseq number to prevent replay because they were conveniently available, and because at a SIP layer getting the same values would reject the message even due to normal SIP processing rules.  But we won't have the latter benefit even with Session-ID, and we basically have to rely on only the verifier being the one to detect/prevent replays.

BTW, it doesn't have to be a random value, either - it could be a sequential number.  It just has to provide enough uniqueness within one second of time, for the same source-dest E.164 pair, so that the signer can successfully generate another message for the same source-dest pair within the same second without the signer itself being detected as a replay.  As long as the verifier remembers there was a message from the source-dest pair and its timestamp and its sequence number, for the ~15 minutes a timestamp is valid for, then the verifier can prevent replays.  So I do that in the IKES mechanism, by requiring the verifier to remember the IKES-IF string value for 20 minutes, and comparing future request IKES-IF strings against it.  (it doesn't need to be for a full 20 minutes though - the draft needs to be tightened up some)

-hadriel