RE: Token based OTP: SafeWord or SecurID?

[Ben Nagy <ben.nagy () marconi com au>]

> -----Original Message-----
> From: John Adams [mailto:jna () retina net]
> Sent: Saturday, 25 November 2000 8:53
> To: Ben Nagy
> Cc: 'Tommy Ward'; ark () eltex ru; firewall-wizards () nfr net
> Subject: RE: [fw-wiz] Token based OTP: SafeWord or SecurID?
>
>
> There was a fair amount of papers and discussions surrounding SecurId
> around 1995/1996. Adam Shostack whote 'Apparent weaknesses in 
> the Security
> Dynamics Client/Server Protocol', available at:
> http://www.homeport.org/~adam/dimacs.html
>
> It's pretty good, although without any knowledge of the 
> protocol itself
> (as it's still private), most of the attempts in the paper 
> are useless.

Depends what you mean by pretty good. Yes - it's very clueful and
interesting. It does not, however, appear to "work" in any real way.

One thing that I do note, however, is that the use of DES as a transport
encryptor between the ACE client and server is very ugly. These DES keys
are, however, ephemeral. If anyone knows much about how they're generated
and the degreee of forward secrecy provided I'd like to hear about it. 

Interestingly, though, and I'd love a cryptographer to correct me, now that
the server response includes "a value dependant on the client's secret key"
(from Brainard) I don't see why we need to encrypt the transport at all. I
would, however, then assume that we need a client / server shared secret of
more than 56 bits.

In fact, if we're doing shared secret authentication between client and
server, signed Diffie-Hellman would probably Work Just Fine, but I guess
that would have required a complete rewrite of the protocol whereas adding a
few bits of hash to the server response is a couple of hours of patching.

> Also, a serious bug (copied here from the 1996 paper) was 
> patched in the
> hash algorithm:
[from Shostack]
>  Security Dynamics was first notified of this bug in July 
> 1996[...but it was already fixed...]
> Details about when this happened were not provided.[...]

If you believe the chronology in the email from Vin McLellan you quote
below, then it was actually fixed in 1994, so the bare quote you provide is
actually a bit misleading. 

In addition, that was NOT a bug in the hash algorithm. As I read it, it was
a bit of lazy protocol analysis that would allow a malicious user who had a
large amount of control over the channel between the ACE client and server
to spoof authorization messages to invalid login attempts. And even then it
required access to the shared DES key.

That doesn't frighten me a great deal. If an attacker has that much control
over the trusted LAN they don't need to break in via dialup.

> There's a ton of links on this at: 
> http://www.securityportal.com/list-archive/firewalls/1999/May/
0027.html

> --john

Two more things that interested me, reading through the Shostack paper:

In the Shostack paper, Adam says:
> It needs to be collision resistant because the server claims to not accept

> previously used tokencodes (FAQ 4.12). 

To which John Brainard (perplexingly) responds:
> Since the F2 function is used only to disguise the pseudorandom PASSCODE 
> value, it is not clear what the impact of such a collision would be.

I think that the guys might have been talking about different parts of the
protocol. Adam is talking (I think) about the impact of collision in the
token hashing algorithm, while John is rebutting about collisions in the F2
hash between the ACE client and server.

The token hash collision possibility is interesting, but a collision is
fairly unlikely (one in 10^passcode digits or so) and in the event of such a
collision the user simply reauthenticates.

Secondly, Steve Bellovin recently said:
> And you're not going to brute-force the algorithm.  
> Apart from the key being too long, it doesn't show all of the output.

Check me on this, Steve - just because the token doesn't show all the has
output does not mean that you can't brute force it in O(2^secret bits)
(which I believe is 64) at worst. You just have to check your guess with a
different timestamp or two every time you think you've got the correct seed.

Cheers,

--
Ben Nagy
Marconi Services
Network Integration Specialist
Mb: +61 414 411 520  PGP Key ID: 0x1A86E304


_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards