RE: gnuradius 0.96.2 SecurID and Sybase

Sergey

I've sent the patches under seperate cover from my home email (which is where I was making the changes!) as it avoids any legal problems.

The de-duplication stuff is looking more and more like a case for a combination of selectable header fields and a mechanism to select specific attrib-vals, remove specific attrib-vals or compare only specified attrib-vals.  Complex, but the flexability will make it more reliable in the long term.

Steve

-----Original Message-----
From: Sergey Poznyakoff [mailto:[email protected]]
Sent: 06 June 2002 08:28
To: Bleazard, Steve
Cc: [email protected]
Subject: Re: [Bug-gnu-radius] gnuradius 0.96.2 SecurID and Sybase 



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



Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.