On Oct 11, 2010 at 19:01, Jiri Kuthan jiri@iptel.org wrote:
On 10/7/10 12:16 PM, Andrei Pelinescu-Onciul wrote:
On Oct 07, 2010 at 10:57, Jiri Kuthanjiri@iptel.org wrote:
There's a bit of a misunderstanding here.
...
Now consider an authenticated message that is retransmitted: the first message will pass authentication, but it's retransmission will fail =>
I admit I haven't thought it through but would it really fail? in both cases (retransmission and replay attack) it will resend initial answer (100 if forwarded, challenge if failed to authenticate) and do nothing downstream --> attacker won't gain an unfair advantage, won't it?
If you set the one-time-nonce option (which causes the auth module to keep state and remember seen nonces) or qop+nc (nonce-count), then the retr. will be challenged (because the auth module has already seen the nonce in the original request and the auth module cannot tell retransmitted requests by itself).
the retransmission will be challenged.
why if the original request passed authentication?
I see the point TM can't differentiate between retransmissions and replay attacks easily (unless we do more of nonce-based protection). But does it really matter?
It's not about any kind of attacks. The auth module if configured with one-time-nonces or nonce_count, needs tm for taking care of the possible retransmissions. Without tm, the auth module will challenge retransmissions. With tm, tm will take care of the retransmissions and send back the same reply the original request got.
Consider the following scenario: (auth configured with one-time-nonce, no tm)
0. INVITE w/o auth-> <- challenge
1. INVITE w/auth => ok passes through
2. retr. INVITE w/auth (1) <- challenge (because auth has already seen this nonce)
With tm, (2) will be identified as retr. by tm, and the auth functions will not be called on it => ok.
Andrei