[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnu-radius] gnuradius 0.96.2 SecurID and Sybase

From: Sergey Poznyakoff
Subject: Re: [Bug-gnu-radius] gnuradius 0.96.2 SecurID and Sybase
Date: Thu, 06 Jun 2002 10:27:41 +0300

Hi, Steve

> I have now almost completed the SecurID and Sybase patches.


> It appears that not all devices are intelligent enough to include a
> NAS-IP-Address, which makes client based authorisation impossible.
> I have therefore added optional code to add this field if it's missing.

OK, it is very useful.

> The second issue is more serious as it interacts very badly with
> SecurID: When a request is received the queue is checked to
> determine if this is a duplicate request.  The checks include the
> authenticator field of each request.  Now, it appears that some
> devices (the Netscreen firewall appliance for example) resend the
> request with a different authenticator (but the same ID).

On the other hand, other NASes (apparently some Ascend series) change
ID when re-sending the request. The request-comparing code, which
would be rather simple if we were to follow RFC, becomes rather
complicated in the real-world environment...

> To resolve this issue I have included (optional) code to track
> SecurID authentications in a ndbm datavase and handle any duplicates
> by replying with the previous answer. I have used the
> request-cleanup-delay value to determine how long to allow.  

Interesting approach. By the way, apart from the inconsistencies with
the authenticator, the main problem with the duplicates detection
is that the request ID range is only 0 to 255, so it wraps around quite
rapidly. It is thus possible that a new request will come with the
ID equal to that of one of the requests in the queue. Actually,
comparing request authenticators was introduced just to prevent
dropping such requests. My plans are to include (again, optionally)
a possibility to compare the request contents (i.e. attribute-value
pairs) in order to determine whether it is duplicate or not. 

> While the solution is not pretty and introduces some replay attack
> possibilities it does make SecurID usage possible!

Great. I'm very eager to take a glance at the code :^)

Thank you.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]