Hi!
I really wonder if the nonce_reuse protection feature is useful and if anybody uses it without problems.
One problem I have is with retransmission: e.g:
----INV1 ---> <---407------ ----ACK----->
----INV2------> here happens a delay to the INVITE (e.g. jam in the access uplink, SIP proxy slow, ... whatever) which causes a retransmission of the INVITE
----INV3------> (retransmission of INV2)
the proxy processes INV2, authenticates the user successful and forwards the requests
then the proxy processes INV3, finds out that the nonce is reused and sends back 407 --> client gives up, but the request was also forwarded by the proxy :-(
How do you handle such a scenario? Do you always create the transaction before authentication?
One other thing I just found out is that reuse-check is done after successful authentication - shouldn't it be done the other way round?
regards Klaus
2009/7/16 Klaus Darilion klaus.mailinglists@pernau.at:
Hi!
I really wonder if the nonce_reuse protection feature is useful and if anybody uses it without problems.
One problem I have is with retransmission: e.g:
----INV1 ---> <---407------ ----ACK----->
----INV2------> here happens a delay to the INVITE (e.g. jam in the access uplink, SIP proxy slow, ... whatever) which causes a retransmission of the INVITE
----INV3------> (retransmission of INV2)
the proxy processes INV2, authenticates the user successful and forwards the requests
then the proxy processes INV3, finds out that the nonce is reused and sends back 407 --> client gives up, but the request was also forwarded by the proxy :-(
Yes, that occurs if no transaction was already created.
How do you handle such a scenario? Do you always create the transaction before authentication?
Creating the transaction before authentication could be dangerous (DOS attacks). I suggest to create the transaction manually *just* after authentication (before t_relay and previous routing logic accessing to DB and so).
One other thing I just found out is that reuse-check is done after successful authentication - shouldn't it be done the other way round?
True. However, to anounce "stale=true" in 401/407 response the credentials must be verified. Imagine that a phone sends a request with an already used nonce (very common behaviour) and the proxy replies 401/401 without "stale" parameter. Then the phone could understand that the user/password are wrong and wouldn't try to authenticate again. "stale" parameter in 401/407 means that the credentials are valid (user, password and nonce are valid) but the nonce already expired in the server so the client must create a new credentials with the new nonce received in the 401/407.
Iñaki Baz Castillo schrieb:
2009/7/16 Klaus Darilion klaus.mailinglists@pernau.at:
Hi!
I really wonder if the nonce_reuse protection feature is useful and if anybody uses it without problems.
One problem I have is with retransmission: e.g:
----INV1 ---> <---407------ ----ACK----->
----INV2------> here happens a delay to the INVITE (e.g. jam in the access uplink, SIP proxy slow, ... whatever) which causes a retransmission of the INVITE
----INV3------> (retransmission of INV2)
the proxy processes INV2, authenticates the user successful and forwards the requests
then the proxy processes INV3, finds out that the nonce is reused and sends back 407 --> client gives up, but the request was also forwarded by the proxy :-(
Yes, that occurs if no transaction was already created.
How do you handle such a scenario? Do you always create the transaction before authentication?
Creating the transaction before authentication could be dangerous (DOS attacks). I suggest to create the transaction manually *just* after authentication (before t_relay and previous routing logic accessing to DB and so).
Yes. Because that would require to handle also registrations transaction-stateful.
One other thing I just found out is that reuse-check is done after successful authentication - shouldn't it be done the other way round?
True. However, to anounce "stale=true" in 401/407 response the credentials must be verified.
It would be sufficient to check if the nonce is reused, response calculation could be done afterwards
Imagine that a phone sends a request with an already used nonce (very common behaviour) and the proxy replies 401/401 without "stale" parameter. Then the phone could understand that the user/password are wrong and wouldn't try to authenticate again. "stale" parameter in 401/407 means that the credentials are valid (user, password and nonce are valid) but the nonce already expired in the server so the client must create a new credentials with the new nonce received in the 401/407.
yes.
IMO disabling nonce-reuse does not get you much security benefits, just increased SIP traffic. Thus nonce-reuse should be enabled by default.
regards klaus
2009/7/16 Klaus Darilion klaus.mailinglists@pernau.at:
Iñaki Baz Castillo schrieb:
However, to anounce "stale=true" in 401/407 response the credentials must be verified.
It would be sufficient to check if the nonce is reused, response calculation could be done afterwards
What I mean is that, response calculation should be done even if nonce is reused. If not, there is no way to send "stolen=true" in 401/407.
Iñaki Baz Castillo wrote:
2009/7/16 Klaus Darilion klaus.mailinglists@pernau.at:
Iñaki Baz Castillo schrieb:
However, to anounce "stale=true" in 401/407 response the credentials must be verified.
It would be sufficient to check if the nonce is reused, response calculation could be done afterwards
What I mean is that, response calculation should be done even if nonce is reused. If not, there is no way to send "stolen=true" in 401/407.
I do not understand this. If the nonce was already use, the proxy could respond immediately with 407 and "stale=true" without checking the password
regards klaus
El Jueves, 16 de Julio de 2009, Klaus Darilion escribió:
Iñaki Baz Castillo wrote:
2009/7/16 Klaus Darilion klaus.mailinglists@pernau.at:
Iñaki Baz Castillo schrieb:
However, to anounce "stale=true" in 401/407 response the credentials must be verified.
It would be sufficient to check if the nonce is reused, response calculation could be done afterwards
What I mean is that, response calculation should be done even if nonce is reused. If not, there is no way to send "stolen=true" in 401/407.
I do not understand this. If the nonce was already use, the proxy could respond immediately with 407 and "stale=true" without checking the password
Hummm, yes it could... good point :)
On 16.07.2009 17:32 Uhr, Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
2009/7/16 Klaus Darilion klaus.mailinglists@pernau.at:
Hi!
I really wonder if the nonce_reuse protection feature is useful and if anybody uses it without problems.
One problem I have is with retransmission: e.g:
----INV1 ---> <---407------ ----ACK----->
----INV2------> here happens a delay to the INVITE (e.g. jam in the access uplink, SIP proxy slow, ... whatever) which causes a retransmission of the INVITE
----INV3------> (retransmission of INV2)
the proxy processes INV2, authenticates the user successful and forwards the requests
then the proxy processes INV3, finds out that the nonce is reused and sends back 407 --> client gives up, but the request was also forwarded by the proxy :-(
Yes, that occurs if no transaction was already created.
How do you handle such a scenario? Do you always create the transaction before authentication?
Creating the transaction before authentication could be dangerous (DOS attacks). I suggest to create the transaction manually *just* after authentication (before t_relay and previous routing logic accessing to DB and so).
Yes. Because that would require to handle also registrations transaction-stateful.
in 1.5, registrar module sends reply in stateful mode if transaction was created for REGISTER -- it uses send_reply() from sl which binds to tm if available.
One other thing I just found out is that reuse-check is done after successful authentication - shouldn't it be done the other way round?
True. However, to anounce "stale=true" in 401/407 response the credentials must be verified.
It would be sufficient to check if the nonce is reused, response calculation could be done afterwards
Imagine that a phone sends a request with an already used nonce (very common behaviour) and the proxy replies 401/401 without "stale" parameter. Then the phone could understand that the user/password are wrong and wouldn't try to authenticate again. "stale" parameter in 401/407 means that the credentials are valid (user, password and nonce are valid) but the nonce already expired in the server so the client must create a new credentials with the new nonce received in the 401/407.
yes.
IMO disabling nonce-reuse does not get you much security benefits, just increased SIP traffic. Thus nonce-reuse should be enabled by default.
I have disabled it is most of the configs I have. If there are retransmission, things may get nuts.
In SR, modules_s/auth has it disabled by default. We should move and discuss on devel to see the impact/benefits and decide the default value.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion