[OpenSER-Users] NEW FUNCTIONALITY: secure nonce in auth module

[Bogdan-Andrei Iancu]

Hi,

Thanks to Anca Vamanu < anca at voice-system dot ro> , the auth module 
has a new mechanism for protecting the nonce against third party attacks.

So far, the auth module provided only nonce lifetime limitation to 
prevent re-usage of the nonce. The new mechanism offers protection 
against sniffing intrusion. The module generates and verifies the nonces 
so that they can be used only once (in an auth response). This is done 
by having a lifetime value and an index associated with every nonce. 
Using only an expiration value is not good enough because,as this value 
has to be of few tens of seconds, it is possible for someone to sniff on 
the network, get the credentials and then reuse them in another packet 
with which to register a different contact or make calls using the 
other's account. The index ensures that this will never be possible 
since it is generated as unique through the lifetime of the nonce.



What problem is solved:
========================

Typical intrusion scenario is:

1) UAC sends INVITE with no credentials
2) openser sends challenge to UAC
3) UAC sends INVITE with credentials (lifetime 1 minute)
4) the credentials (auth response) are exposed on the net, so anybody 
can grab them (lets assume by person X)
5) openser accepts the credentials and call is establish
6) person X injects (by sending to openser) an re-INVITE (to change the 
media destination, for example) by re-using the credentials that he 
grabbed from the net.
7) credentials are accepted by openser if the lifetime is not expired.


So, third parties can modify (or even initiate) dialogs by re-using the 
credentials they captures from a previous authentication. The only 
limitation is the nonce lifetime which is about 30 - 60 seconds, long 
enough for allowing such an atack.


The new mechanism, by blocking the re-usage of the same nonce (even if 
the lifetime is still valid), will block step 7) as the same nonce was 
used in step 5) (by UAC).



Technical details:
==================

The auth module keeps state for each nonce - to validate it only on the 
first usage. A binary array (which can by default accomodate 100K 
nonces) is used to keep the state. An index in this array is allocated 
when the challenge is generated; this index in kept for the whole life 
duration of the nonce. After the first auth result (for the nonce), the 
following auth results for that nonce are discarded and re-challenged.

As nonce can be generated and later checked from different processes, 
the nonce state (binary array) is kept in shm memory and the access to 
it is synchronized via locking.

The see what is the overhead added by the computation time (keeping the 
nonce state) and locking (sharing between processes), Anca run several 
of tests :
    - openser single process
    - openser multiple processes, single processor machine
    - openser multiple processes, multi processor machine
For tests we were using authentication via PV (for password and 
username) to avoid using any slow data backend (radius or DB) that might 
eclipse the overhead.

The measured overhead is 4% - 7% (from the original version).


Regards,
Bogdan