[SR-Users] Stateful vs. stateless replies from script

Andrei Pelinescu-Onciul andrei at iptel.org
Tue Oct 12 15:57:00 CEST 2010


On Oct 11, 2010 at 19:01, Jiri Kuthan <jiri at iptel.org> wrote:
> On 10/7/10 12:16 PM, Andrei Pelinescu-Onciul wrote:
> >On Oct 07, 2010 at 10:57, Jiri Kuthan<jiri at 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



More information about the sr-users mailing list