Re: gnuradius 0.96.2 SecurID and Sybase
Sergey Poznyakoff <[email protected]> Thu, 06 Jun 2002 10:27:41 +0300
| Newsgroups | gmane.comp.gnu.radius.bugs |
|---|---|
| Organization | Farlep-Internet |
| Message-ID | <[email protected]> |
Hi, Steve > I have now almost completed the SecurID and Sybase patches. Great! > 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. -Sergey