Re: Hardware tokens for remote access authentication

[Vin McLellan <vin () TheWorld com>]

Marcus Ranum, ex cathreda, said:

> Vin McLellan wrote:
> >See Kevin Kadow's April '99 post to Bugtraq, "FWTK, Gauntlet 'random 
> seed' security >problem," at: 
> <http://www.securityfocus.com/archive/1/19990416203627.15201.qmail>.

Apparently the end of the URL got cut off. Sorry for the error. See:
<<http://www.securityfocus.com/archive/1/19990416203627.15201.qmail () msg net>http://www.securityfocus.com/archive/1/19990416203627.15201.qmail () msg net>. 
Note that I also copied Kevin Kadow on my earlier message.

> Kadow's attack is heavily reliant on shell-level access to the
> auth server. Anyone who gave shell-level access to their auth
> server has already voided the warranty. ;) You're not supposed
> to do that!!!  Kadow's at least intellectually honest enough to
> mention in his writeup that normal FWTK/Gauntlet configuration
> practice is to only allow connections to authsrv on the loopback
> port, which completely defeats the attack unless the attacker
> is ON the machine. That's how it was designed to be run, and
> that's how it was configured in Gauntlet. In other words, the
> attack would never work against a system that had not already
> been misconfigured to the point of stupidity.
>
> Your posting, Vin, doesn't mention these inconvenient facts as
> they are described in Kadow's own paper. That makes it sound
> a lot like you're just blowing FUD to me.

Whoa!

1. I said RSA had a patent, several patents, for time-synch in token-based 
authentication. I suggested that it was rash for Marcus to recommend that 
an institution like Johns Hopkins should ignore them.

That's a far far cry from what Gene Amdahl meant when he coined FUD -- 
fear, uncertainty, and doubt. -- as a description of IBM's use of 
competitive disinformation as a high-pressure sales tactic!

2. I also said that implementing home-brew crypto is more difficult to get 
right than it might first appear. In what I thought was a friendly wry 
aside, I cited Kevin Kadow's '99 bug report as an illustration of the 
subtle difficulties that can haunt crypto implementations.

3.  I went off and dug it out Kevin's Bugtraq post at Marcus' explicit 
request. This is a five year-old bug report about 10 year-old code -- 
almost surely a long-settled historical tidbit, I thought, with no 
competitive or commercial relevance in 2004!

4. I don't believe in FUD. I don't like FUD.  I don't do FUD.  I'll take my 
lumps if I inadvertently misrepresented Kevin's '99 Bugtraq report, but I 
do *not* believe that a caution about the difficulty of properly 
implementing home-brew crypto is anything like fear-mongering.  I think 
it's common sense, usually abundant in this forum;-)

Raining fire and brimstone, Marcus said:

> I understand your
> desire to relentlessly market SDI's products (you took a couple
> more chances to throw in a plug here and there in your response..)
> but I don't think it's proper to do it at the expense of other
> systems, by selectively choosing parts of someone else's
> paper that subtly change the message and distort its meaning
> just so you can make your point. That's not proper.

I apologize if you, or anyone else, felt that I misrepresented Kadow's 
report.  I thought I had grabbed the essence of it -- for the purposes of 
our discussion -- with Kevin's description of the apparently flawed PRN 
seeding and his comments about the potential implications of a successful 
attack on the server.

(My initial reference to Kadow's Bugtraq post was -- as Marcus should damn 
well know! -- a parenthetical suggestion that even our most capable 
developers may have difficulty getting everything right when it comes to 
crypto implementations.  I'm astonished that quoting it could be 
misinterpreted as a hostile slur against the developer.)

The brief mention I made of RSA in my reply was on-topic factual 
information -- in furtherance of my point; in an appropriate context; in a 
thread explicitly focused on issues around hardware tokens.

(I won't attempt to justify my earlier meandering romp down memory lane, 
except to note that a lot of people seem to like my dollops of industry 
history, when I try to place dated reports in an timely and appropriate 
context.  Marcus, not I,  first talked about the ACE/Server problems in the 
mid-1990s.)

In the message we are discussing, I pointed out that even RSA's classic 
64-bit SecurID hash had been found to be less that wholly resistant to all 
exotic attacks and had to be upgraded.   I also offered (accurate;-) URLs 
for the relevant 2003 and 2004 academic papers critical of RSA's crypto 
engineering in the old SecurIDs.

> The _actual_ URL (the one Vin gave is wrong) is
> http://www.securityfocus.com/archive/1/13322
> and I suggest that anyone who is interested in this topic
> give it a read - compare Vin's selective editing with what
> Kadow really has to say. SHAME ON YOU, VIN!

Balderdash! I offer another _actual_ URL at the top of this message.  I 
would have corrected myself and given the complete URL  when I realized the 
first one was truncated and didn't work. I

I'm not afraid of anyone comparing what I wrote with Kevin's original post. 
I accurately quoted those portions of the bug report that I thought were 
relevant to the -- elsewhere non-controversial -- point I was making.  I 
wasn't judging anyone's code, I was talking about the subtle technical 
challenges of implementing crypto.

To wit, as Marcus said:

> All that said, the PRNG seeding *IS* bad. The intent of
> the system was to be 'good enough' to raise the bar
> to the point where the bad guys would attack a weaker
> part of the system - most likely the endpoint(s).
>
> If you're willing to think about the problem for a few
> minutes and not be impressed by FUD from a vendor
> shill, you'll realize that moderately good authentication
> raises the bar to the point where the other weaknesses
> of the system become more significant.

No argument about that analysis from this vendor shill.

> In fact, I'd argue
> that plain-ole-passwords over SSH/SSL have probably
> raised the bar to the point where the hackers are just
> now having to re-invent transitive trust attacks (hello, kiddiez!)

Yup. No argument. (Although I note in passing that the crypto in both SSH 
and SSL has, on more than one occasion, been touched up, usually to deal 
with implementation issues.  With no apparent damage to the developers' 
reputations;-)

> The value of authentication systems like an SNK or
> S/Key or SecurID has relatively little to do with their
> cryptographic strength or complexity, and a lot to do
> with the fact that hackers don't have keystroke loggers
> for brains - yet.

I don't understand what that quip about hackers with keystroke-logging 
brains refers to, but that might just be my mental disability.

I do agree that the crypto in any OTP personal authentication system has be 
merely appropriate for its function. That is, it has to be sufficient 
resistant to attack so that a Bad Guy can't effectively mimic its 
interaction with the authentication server, in a timely manner, to gain 
illicit access to protected resources.

> I'd go so far as to say that the ONLY
> value of those systems is that they, for the time being,
> push authentication computation into a non-networked
> system.

Ok.  That, systemically, is no less and no more than what OTP tokens were 
designed to do.  They are, of course, challenged in the market by other, 
equally effective, authentication systems that rely upon their interactive 
network connection: i.e. smartcards and USB tokens.

In the contrast between them, the work habits of mobile users, and the fact 
that OTP tokens do not require local client software or a hardware reader, 
has been a key advantage for OTPs. In the face of faltering PKI, it has 
given OTP tokens legs that few, historically, expected they would have. 
Thus, we see MS in 2004 integrating OTP tokens as a native authentication 
option for Windows.

> You can accomplish that with a palm pilot or
> darned near anything, and you'll have a system that
> the hackers aren't going to compromise.

The elegant simplicity of a small single-function device on a keychain has 
its own wiz-factor, for the network architect as well as the user.  Some 
find a sealed OTP fob offers a measure of critical assurance to auditors 
that a programmable device (with an IR port?) may not.

A sealed device is also almost surely -- with or without the connivance of 
the token-holder -- more resistant to being copied or cloned.  A sealed 
device is probably designed to be both tamper-resistant and tamper-evident 
-- so most physical attacks that attempted to access the token's circuits 
or memory would damage or destroy the OTP token, or at least the token's 
external casing.

For enterprise or institutional sites, of course, there is a critical 
additional level of assurance that almost any commercial OTP vendor can 
offer in terms of  support, compatibility, interoperability, 
standardization, and the ability to accept liability, also makes a 
persuasive business case. This, as much as anything else, is probably why 
free C/R or OTP/s-key modules in Palms haven't swept aside all the 
commercial OTP vendors.

Security products not only have to work, they have to be trusted -- and 
it's all the better if an institution can mitigate any residual risk by 
transferring liability and responsibility for maintenance, etc., to an 
eternal supplier.  Managers get paid to mitigate, transfer, and avoid 
unnecessary risks.

> Unless you give them shell access to it. Duh!

Yup.  Those customers do the damndest things, don't they?

        Suerte,
                _Vin

          -----------------------------------------------------------------

I beg the indulgence of the List for the burden on the bandwidth.

                 * Vin McLellan + The Privacy Guild *
                 Chelsea, MA. USA vin () theworld com  


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards