[OpenSIPS-Devel] [OpenSER-Devel] SF.net SVN: openser: [4294] trunk/modules/auth

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed Dec 17 19:03:38 CET 2008


Hi Dan,

I agree with you. As said to Alex, there are two approached:
1) we give up to this security upgrade and make it configurable
2) imagine a mechanism to share nonce indexes  across multiple servers 
(form the whole set of nonces, each server from the cluster will get a 
partition, so all servers will be able to recognize all the nonces from 
all the servers - but we will need to add a auth id for each server, 
like in the node ids in the mysql cluster).

Regards,
Bogdan

Dan Pascu wrote:
> On Tuesday 16 December 2008, Alex Hermann wrote:
>   
>> On Monday 02 June 2008, Anca Vamanu wrote:
>>     
>>> Revision: 4294
>>>          
>>> http://openser.svn.sourceforge.net/openser/?rev=4294&view=rev Author:
>>>   anca_vamanu
>>> Date:     2008-06-02 08:18:46 -0700 (Mon, 02 Jun 2008)
>>>
>>> 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.
>>>       
>> Although I like the added security, I think this solution is
>> fundamentally wrong. The nonce does not necessarily have been created
>> by the same proxy. In a SRV-loadbalanced cluster, the UAC may choose to
>> send the authenticated request to another server as from which it
>> obtained the nonce
>> (Unfortunately, this nasty behaviour is present in the wild).
>>
>> The proxy should also accept (once!) a nonce it doesn't yet know about.
>> When one assumes the nonce has been created with a Kamailio server, it
>> may be possible to encode the lifetime into the nonce and extract it on
>> first usage.
>>
>> I know this means every nonce can be used once at every proxy, but
>> that's hard to prevent unless all proxies communicate with each other.
>>     
>
> I have to agree with this and ask that we add a modparam to control if 
> nonce reuse is allowed or not.
>
> I have this case that is broken by the new behavior:
>
> I have a farm of proxies that are advertised in DNS. A UAC will do a DNS 
> lookup and send a request to one of the IP addresses that were returned. 
> However the internal structure of the network dictates that a certain AOR 
> is handled by a certain proxy that is always the same for a given 
> collection of proxies, but may change if the proxy collection changes.
>
> This means that if if I send a request to proxy P1, it will detect that 
> the proxy that handles my account is Ph, and it will forward the request 
> there. Ph will generate an auth reply and a nonce with it.
>
> Now assume that the proxy collection changes while it sends me back the 
> 401 auth challenge. I will resend the request with an auth response this 
> time, and even assuming that I still send it to P1 where I sent the 
> original request, P1 will this time see that Px is the new proxy that 
> handles my account and will forward the request there. This proxy will 
> not recognize the nonce and will issue a new auth challenge with a new 
> nonce and send back the 401. This time my UAC will simply give up, 
> because most of them when they receive 2 auth challenges in a row 
> consider that they have the wrong password and stop trying.
>
> I have seen this in real life and the solution (with openser 1.3 at least) 
> was to set the same shared secret on all proxies to allow them to share 
> the nonces. But with the new algorithm, even with the secret sharing is 
> still unable to work as nonces cannot be shared anymore.
>
> In my case the effect is that every network transition that adds/removes a 
> proxy to my proxy collection will leave me with phones that will not 
> register anymore until manually reset.
>
>   




More information about the Devel mailing list