Subject: Re: [stir] Replay threat (was: Re: Rollout timeframe)

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 4 Aug 2013 14:37:09 -0400

I take it back - preventing true replay may be impossible, or at least highly impractical.  There're too many scenarios of legitimate call spirals, even in the real world... all of which would appear to be malicious replays but are actually legitimate and benign.  So if we have verifiers perform replay protection, then they're likely to detect legitimate spirals as malicious replays, making the mechanism unusable.

The safest thing, from a "will it work" perspective, might be to just make the timestamp validity window very short.  Like, say, a 9 minute window - i.e., the verifier only accepts +/- 4.5 minutes.  That still lets the signer and verifier not synchronize clocks, and for the message to traverse the path.  For example in the worst case the signer can be 2 minutes behind real time, and the verifier can be 2 minutes ahead of real time, and it taking 30 seconds for the message to go between.

That still won't prevent the call-forwarding cut-and-paste attack, but then neither did true replay protection.

-hadriel

On Jul 16, 2013, at 2:17 PM, Hadriel Kaplan <[email-masked]> wrote:

> 
> On Jul 16, 2013, at 10:57 AM, Dave Crocker <[email-masked]> wrote:
> 
>> Folks,
>> Question to the group:
>> There are a number of different styles of replay attack, with different likelihoods and different effects (nature/degree of damage).
>> What specific replay scenarios does the group deem it essential to prevent and why?
>> I've seen situations in which it was deemed acceptable to allow some types of potential replay attacks, because the potential for its occurrence and/or damage it would do were not a serious concern.
> 
> It depends on how you define "replay".  In my personal opinion, the threat of someone replaying the same SIP message against the same target is virtually nil.  It's not hard to prevent it I think, so I don't see a reason not to prevent it.
> 
> We've already assumed the odds of a malicious MITM are very low.  Or to be more precise, we acknowledge there already are a ton of benign MITM, and that if they wanted to be bad, caller-id authentication isn't gonna prevent much.  It's just closing a stateroom door on the Titanic.
> 
> We've acknowledged there are bad senders, but if they can get their messages signed, they hardly need to replay the message with the same signature.
> 
> We've acknowledged there are weak signers, but if they have the key to sign messages, then they don't need to replay.
> 
> We've acknowledged (I think) that there are bad receivers.  So we have to prevent them from replaying a received message against a *different* target.  I think of that as more of a cut-and-paste attack than replay, but I don't care what it's called.  The point is that I can easily get a bank to call me, and I should not be able to use their call request's STIR info to call someone else and have that someone else believe the bank is calling them.
> 
> Unfortunately, preventing that cut-and-paste attack is quite hard.  Mostly because it's hard to distinguish from a completely legitimate call-forwarding case, and we have to support legitimate call-forwarding.
> 
> -hadriel
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir