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

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