Re: Hardware tokens for remote access authentication

[Vin McLellan <vin () theworld com>]

Marcus Ranum <mjr () ranum com> delved into the mists of memory to recall a 
world of tokens worthy of trust, vendors of virtue, mighty men, and a 
barely commercialized web, a mere ten years ago;-)

> I ran a bunch of Digital Pathways SNKs back in the day, and SecurIDs,
> too. Hopefully SecurID's management software has improved since 1994 -
> it must have because they're still in business. The old SNKs are gone,
> now, into the mists of time - I used my own server-side code (part of the
> firewall toolkit) so I can't comment on the management software.

Ah, Auld Lang Syne! CERT, early in 1994, declared that widespread 
network-sniffing attacks already made user-memorized passwords dangerous 
and publicly urged a switch to two-factor tokens. I thought that was gonna 
transform the world! <sigh> Of course, back then I was also utterly certain 
that transparent crypto would be everywhere by 2004.

Most of the token vendors of that era -- one or two of which had been in 
the market even before SecurIDs were first shipped in 1987 -- have faded 
into Marcus's Mists, or been absorbed into larger, more diffuse, 
entities.  In 1994, I had just come back to work for Security Dynamics 
(which was then negotiating to buy RSA DSI; eventually to rename itself RSA 
Security).  TACAS+ was just supplanting TACAS. Proto-Radius had just been 
proposed as an IETF standard.  SDI had sold about a million SecurIDs.

In '94, however, RSA/SDI the only token vendor offering a client/server 
architecture, having introduced it in '91. Vendors like Microsoft and TIS 
-- where Marcus was still ensconced -- had just decided to integrate 
ACE/Agents into their products.  There were hassles and dislocations 
associated with the mid-90s switch to the ACE client/server architecture, 
but they paled besides the disruptions that followed the integration of the 
Progress RDBS into the ACE/Server in '95.  What had been a rather simple 
user-installed app was suddenly a complex service that needed a savvy Unix 
administrator. Many ACE sites had a difficult time. I recall a six month 
period in '95-'96 when RSA quadrupled the size of its Customer Service 
staff, and they were still swamped.  (OTOH, two years later, a SANS survey 
of network administrators who used ACE/SecurID found that 92 percent of 
them recommended SecurIDs to others as essential to secure new networks.)

Ten years later, RSA has sold over 15 million SecurIDs to 14,000 
customers.  Were there problems along the way? Oh yes!  But a lot 
independent-minded network administrators still choose ACE/SecurID, 
although the SecurID has always sold at a significant premium over its 
competitors.  Problems with the tokens have been relatively rare -- 
although that is no consolation to any admin who got stuck with a batch of 
glitched circuits or some other oddball production flaw.  Over the decade, 
I presume such problems are a wash among the various vendors. The SecurID 
is almost the only token sold with sealed battery and a pre-programmed 
end-of-life (now 1, 2, 3, 4, or 5 years), so it was perhaps inevitable that 
it had some problems specific to its unique design. (No production problems 
in '03 or '04, since I came back from another sabbatical. Knock on wood!) 
Of course, RSA is also the only token vendor which has always offered a 
full warranty on its SecurIDs.

> Management was consistently about 5 minutes to activate a device and 10
> to beat "train" the user how to log in with it. I suspect that most systems
> will hang around there. The failure rate was about 10%/year (rough guess)
> between accidental toilet immersion, folding, and battery death. I liked the
> SNK because the battery was replaceable whereas the SecurID unit needed
> to be thrown away every year or so (50%/year replacement). Re-keying was
> periodically necessary but generally not a big deal. Another factor very
> few people take into account is the "return rate" - how many people actually
> give their token back when they leave their job or graduate or whatever.
> I've found the return rate is about 50%.

Big numbers. If you were using one-year SecurIDs back in that Paleolithic 
era, your site might replace half of them over the course of the year.  In 
fact, however, from about '96 on, most ACE/SecurID sites were using 
three-year tokens, and the roll-over was typically paced and orderly.  In 
the boom years, voluntary personnel turnover probably paced the rate of 
token assignment.  Given the cost of SecurIDs, I suspect that most 
installations made more of an effort to recover tokens from departing 
employees than Marcus did. Formal departure interviews helped tidy up such 
loose ends.

(Today, Marcus, RSA offers something called Web Express, which is said to 
cut the time involved in the training, care, and feeding of new 
SecurID-holders considerably. A security guy no longer has to process each 
token from a centralized location prior to its actual deployment.  Web 
Express distributes the authorization required for token-validation, and 
then offers a self-service web server for PIN validation and new PIN 
requests.  See: <http://www.rsasecurity.com/node.asp?id=1180>)

> Given the cost per unit and the management headache, I'd like to encourage
> you to explore a different route I've recommended to a number of people. So
> far nobody has done it - I'm not sure WHY because it seems to me to be a
> very decent concept. ;)   Go to bizrate and find someone who is selling the
> old Palm Pilot organizers CHEAP. Buy cases of them for $50 apiece. Write
> a version of the SNK code (take it from fwtk!) or S/key or SDI's algorithm.
> If you think for about 1 minute you can figure out how to make your own 
> time-based token; SDI's patents are on the skew adjustment (and aren't 
> rocket science either) instead of saving the skew like they do, you can 
> just search around the time because processors have gotten really fast. ;)

RSA's SecurID patents are broader than that.  If they weren't, we'd be 
choosing from an array of time-synch tokens from China today. (I think 
there are seven different US patents, with foreign counterparts, on aspects 
of the SecurID design.  The earliest of them runs out next year, but you'd 
want a cautious lawyer to consider the scope of all the rest of them before 
anyone followed Marcus' advice for home-brew time-synch;-)

(RSA offers a free download of SecurID token-emulation software modules for 
Palm [and Win Pocket PC, Win Mobile 2003, Blackberries, and an array of 
mobile phones] at: <http://www.rsasecurity.com/node.asp?id=1313>.  Most of 
the commercial token vendors offer a similar smorgasbord of form-factors, 
and most, like RSA, go beyond one-time-password (OTP) tokens to offer X509 
certs, CAs, smartcards, USB dongels, and even biometrics.)

There are, of course, no IP constraints on the use of OTP/s-key 
calculators, and nothing bars the use of a generic Challenge/Response 
software on Palms or any other device. So why have these authenticators 
never challenged the commercial tokens?  I presume it's because the 
business case for commercial tokens vs "homebrew" devices was, and remains, 
persuasive. (There is also the fact that, as Schneier put it, crypto is 
harder than it looks.  In 1998, even Marcus' FWTK and the TIS Gauntlet were 
found to have a flawed random-number generator, which threatened the 
integrity of those C/R authenticators which had relied upon it.)

> While you're at it, have your
> little app provide encrypted storage for user passwords, etc. ;)  AND your 
> users
> get free scheduling and you're all using a standard scheduling system. Nifty!
> Oddly, my guess is people are much less likely to loe a nice useful PDA
> than a silly dongle that only does security. Expect a near zero return rate.
> My guess is that you can own your own token architecture AND have
> PDAs with PGP, etc, for about $60/user, with better software and support
> and a higher cool factor than with the commercial products. Extra credit if
> you use SMS phones. ;)

The stand-alone simplicity of the classic OTP token has many advocates. 
(Some find it reassuring that a sealed token is doing only what it is 
supposed to do, and nothing else.  Try to get that assurance from a 
smartcard!) RSA and Secure Computing both came out with systems that send 
one-time token-codes as SMS messages to mobile phones -- a design aimed 
squarely at mobile gadget addicts like Marcus and me.  Some innovations 
take, some don't.  On the token side, after the key-fob, there's been 
little substantive change; although the crypto is being ungraded.  Much of 
the market action has come to focus on the authentication servers, SSO 
middleware, and the integration of OTP authentication into the new matrix 
of identity and web access management.

Only a rash young man is gonna debate duende with Marcus, and I am no 
longer neither rash nor young. I submit, however, that cool-factor for the 
user and cool-factor for the network architect are somewhat different 
things. ACE/SecurID sites are still finding new, creative, and simplifying 
applications for two-factor authentication in things like SecurID for 
Windows, RSA Sign-On Manager, the FIM, and the ClearTrust web suite for 
streamlined AAA.  I know RSA best, since I still consult with the company, 
but RSA's leading competitors -- Secure Computing, CryptoCard, ActivCard, 
and Vasco -- have also been pushing the envelope to expand the usefulness 
of two-factor tokens.

Don't write them off yet, Marcus! They've each got a TCO case to 
make.  With auditors preaching risk assessment, and IT perimeters so 
porous, and with rapidly expanding external demands for "compliance," TCO 
calculations have to factor in the emerging AAA opportunities as well as 
the relative cost of help-desk calls and tokens lost in the toilet.  That's 
an increasingly complex assignment.  I wish Mr. Kyle well in his 
endeavor.  I hope he'll report back to the List as John Hopkins goes 
through the process.

Suerte,
        _Vin

          -----------------------------------------------------------------
        "Trust is only dangerous when you have to rely on it."

      * 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