Tony Harminc wrote: > Sigh... I really don't want to turn this nice quiet list (that I've been a member > of for many years) into a bunch of vendor arguments. It's rude, and in this > case it's almost 100% off-topic.
OT? (With respect, Sir, the subject of this thread is "RSA SecurID product.") My last post was written as a direct response to Mr. Harminc's comments about RSA's SecurID, a one-time password (OTP) token that is sold in direct competition to the Vasco OTP tokens that Mr. H's employer bundles with his SSO products. Citing facts not otherwise available to the List is generally considered to be a constructive contribution to a discussion about competitive products. Mr. Harminc's initial post was, IMNSHO, fundamentally misleading because it fostered the false impression that all hardware OTP tokens are the same -- that all offer comparable degrees of security, integrity, and process assurance -- just because they all manage to cough up an OTP... one way or another. I offered additional information about RSA's SecurID -- and about the Digipass token Mr. Harminc's employer resells for Vasco -- because that seemed to be the proper way to counter Mr. H's little list of Issues of Concern for potential OTP buyers, which I believe was biased against RSA's product. The fact that, according to the CEO of Vasco, many European financial institutions have recently decided that they will have to replace their Vasco DigiPass tokens every 12 months -- when millions of those tokens were originally purchased and distributed with the expectation that they could be used for many (3-7?) years -- seems to me relevant to any discussion of the various 2FA/OTP options. (I do apologize for my error in describing Mr. Harminc as a developer of software applications for Vasco. Mea maxima culpa, I inadvertently cut a line. Mr. Harminc is a developer of SSO applications, which are sold bundled with Vasco Digipass OTP tokens, for Proginet <www.proginet.com>. Proginet apps, said Mr. H, allow Vasco tokens, or any Radius-compatible 2FA solution, "to be authenticated against mainframe security systems (RACF, ACF/2, and Top Secret.") Mr. Harminc reviewed the comments of Vasco CEO T. Kendall Hunt last summer at <http://tinyurl.com/cospv> and wryly flicked his FUD-O-Meter: > I had never heard of Mr. Hunt, but I went and read the article. In it, Mr. Hunt > says that "most banking organizations using Digipass tokens refresh the > products about every 12 months for improved security". This seems > unremarkable, despite Mr. McLellan's attempt to make it sound like some > dark secret. Organizations that deal with Real Money will have a threat > model quite different from those using tokens to protect other kinds of > assets, particularly when the user base in question is essentially untrained > in security awareness. Unremarkable, huh? I'd love to hear the ruminations of some savvy Proginet customer, who bought your bundled Vasco token package, as he mulls the implications of the fact that the top European banks have decided, for reasons unknown, that they must now spend maybe 5-7 times what they originally budgeted for tokens to cover the unexpected costs, over the tokens' projected lifespan, of annually purchasing and redistributing new Digipass tokens to their staff and customers. ;-) Is there anyone who thinks these banks are spending money for the sheer joy of expenditure? Is Ebenezer Scrooge a miser? Is there anyone who can be utterly certain that their local environment is exempt from whatever new threat the Euro banks are reacting to? (And aren't *all* users "essentially untrained in security awareness?") "Dark secret?" <Sigh.> Gimmme a break! What Mr. Hunt publicly reported was an unexpected, unexplained -- and very expensive -- change in the security policies and the provisioning practices of many heavily-regulated European banks. Yes. it plays hell with the Total Cost of Ownership for Vasco and Proginet products -- but there may be bigger issues here too. Institutions that "deal with Real Money," and online banks in particular, do indeed have a different threat model than the rest of us -- but those differences may not be what's at issue here. If it is the OTP tokens, per se, that are the focus of the banks' operational risk concerns, whatever new information those banks have pugged into their Basell II models may be of interest to us all -- not just Vasco customers. To judge by anecdotal evidence, tokens -- some labelled valid until 2008 -- are being exchanged one for one, with identical replacements, by some big European banks. Security officials at these banks are being unusually reticent in explaining their new policies, which has led some European observers to speculate that they are operating under unannounced regulatory mandates or EC guidance. (If that is FUD, I apologize. I expect more details will be made public, sooner rather than later, but that's all I know.) I don't want to be Cassandra here. There are a lot of exciting things happening as the big 2FA vendors, RSA and Vasco in the front ranks, get pulled into the global drive to supply a billion dollar mass market for 2FA in retail financial services. (At least for RSA, btw, that may be a largely mainframe-focused marketing initiative.) New vendors, some with exciting new technologies, are popping up all over. RSA's recent purchase of Cyota, a developer of layered anti-fraud technologies; OATH's RFC on mutual authentication, and Vasco's new strategic tie with Tri-Cipher, are all artifacts of a broad competitive realignment of AAA vendors and 2FA products, which is likely to redefine identity & access controls, provide much more secure transaction on the Web. Six months from now, the service offerings in this industry niche are going to be amazing. ;-) Vasco's report of a new caution, a new skepticism, about their OTP tokens among top European financial institutions is a bit of the fly in the ointment -- and while I'll freely use Mr. Hunt's comments to ward off Vasco enthusiasts, I also admit that I am very curious about what is happening there. Earlier, I suggested -- admittedly on scant evidence -- that the most likely stimulus for a drastic European reevaluation of the risks associated with some OTP tokens is probably the European Commission's major research project on Side Channel Analysis (SCA) and various SCA-based attacks on embedded cryptosystems. Two years ago, the EC funded nine separate research teams, based across Europe, to explore the threat of SCA attacks on microchip-based crypto implementations -- and to seek defenses, in microchip design, against specific attacks, like Differential Power Analysis (DPA). The SCA R&D project <http://tinyurl.com/7zfaa> is due to produce a final report at year end, but it has spun off numerous research papers, and more than a few rumors, over the past two years. This is not OT. This is relevant to this discussion -- whether I'm right or wrong to make a link between the SCA threat and the European banks' 12 month turnover policy on tokens -- because the SCA threat is real, and because RSA's AES-based SecurIDs, introduced four years ago, were specifically designed to be resistant to SCA attacks. Most other OTP hardware tokens, including Vasco's, are apparently still vulnerable to this type of direct attack on the token's OTP processing circuit. Guarantees that a personal authentication token is "tamper-resistant" are often sought by CIOs, ISSOs, and network managers who are considering 2FA options. It is, and should be, a relevant issue in any discussion of 2FA options and hand-held personal authenticators like RSA's SecurID. I readily concede, however, that this is a high-assurance issue. Tamper-resistance is too often assumed for all hardware OTP tokens, when it should not be -- but it is also perhaps not a critical issue for many institutions considering 2FA. For many installations, cell phones or PDAs, running token-emulation software, provide a level of secure 2FA wholly appropriate to their threat and risk environment. (At worst, hardware OTP token vulnerable to DPA attacks would fall roughly in this category -- with the 2nd factor, the user-memorized PIN or password, still providing a protective barrier to illicit access even if the "token" is stolen or compromised.) Other institutions -- probably including the federal agency whose interest in RSA's SecurID sparked Mr. Harminc's avuncular guidance -- arguably have more demanding security requirements. It makes no sense to spend more on security than the value of the resources at risk, but there are obviously institutions -- including many which do not deal in either Real Money or Dark Secrets -- which have data and other networked resources of such value that they routinely demand, and require, a high degree of assurance for all elements in their security infrastructure. Not all 2FA solutions are equally secure; just as not all tokens are created equal -- but most 2FA vendors provide an array of software and hardware options to meet these different requirements. Sites with different needs require different levels of integrity assurance for their critical infrastructure. Given the ease with which malware continues to spread and corrupt local workstations, there is likely to be renewed interest in the integrity of authorization models, intrusion detection devices, and the forensic audit trails. In this, the mainframe world is far ahead of the general market -- but even the regulars on this List are likely to see intriguing new techniques for adaptive, upgrade-on-the-fly, authentication services emerge from financial services, where the losses (cash and confidence) now associated with phishing and identity theft are simply unacceptable. Ok, back to our gentlemanly dispute. Despite the fact that Mr. Harminc concluded his original post with an apology for a "sales pitch," Mr. H continues to insist that my suggestion that his advice for OTP newbies was biased is "simply absurd." For the entertainment of the Listocracy, here's Mr. Harminc's original worry list: >> Do they make their money on the actual tokens, or on proprietary server >> software, or on some other basis? Can you buy additional tokens from >> another source or are you locked in? Conversely, can you use their tokens >> with another server? Is the server priced by user in addition to the cost of >> the tokens, or by number of connected endpoints, or some other model? >> How long do tokens last, i.e. do they expire by design before their natural >> battery life? etc. ect. In his latest post, Mr. H added: > May I gently suggest that re-reading my actual post, rather than some > phantom one, is in order... I said nothing at all about SecuriD's "unique > capabilities", let alone cast them in negative terms. I have no idea what > magic patented functionality only RSA can provide... What, pray tell, other than the SecurID's "magic patented functionality," could be the basis for the fearful "lock in" Mr. Harminc cautioned prospective OTP buyers to avoid? ;-) Given RSA's relative success, if the SecurID could have been cloned by its competitors, it would have happened long ago. The List's readers can judge for themselves the validity and "objectivity" of Mr. Harminc's concerns about the risks associated with an institution's decision to commit itself to a portfolio of patented 2FA technologies that, admittedly, can only be purchased from one vendor (RSA, the patent holder); and which, admittedly, can only be supported by the authentication servers sold by one vendor (RSA, the patent holder.) Proginet, Mr. H's employer, and Vasco, both offer products that rely upon the basic Radius protocol and a Radius AAA server to manage their authentication calls. RSA's SecurID, admittedly, offers a proprietary udp protocol -- which encrypts the authentication exchange between an app-integrated RSA Agent and the RSA server -- to support a proprietary authentication engine, the RSA Authentication Manager, on a variety of hosts. Of course, the RSA AM also includes a Funk commercial Radius server. Mr. Harminc contrasts the two architectures in economic terms, highlighting the fact that several Radius servers are open source. It's a worthy point. I thought it useful and appropriate, however, to also point out that over 300 networked devices and applications, most with integrated RSA Agents, ship "SecurID-Ready" -- with certified out-of-the-box compatibility with SecurID 2FA. Those partnerships have been a major factor in RSA's 15-year domination of this market. In the same economic context, Mr. H's expressed concern about the respective business models used by RSA and other 2FA vendors, Vasco among them: the balance of revenue they draw from tokens, agents, and servers; and whether the OTP infrastructure is priced by user (as RSA's is) or on some other basis. All vendors need revenue and profit; but revenue is like digital data. it can be channeled and poured from many different vessels. Mr. H and I could debate the particulars of various business models -- but those seem to me details more properly left to competitive salesmen discussing a specific network. For any given purchase decision, it's obviously necessary to compare prices, but any discussion of how various pricing models effect the cost of a 2FA implementation really should be site-specific. And ultimately, the acceptability of any given pricing scheme is decided in the competitive marketplace, isn't it? Mr. Harminc, above, cautioned prospective 2FA buyers to study: >> How long do tokens last, i.e. do they expire by design before their >> natural battery life? etc. etc. Much of my original reply to Mr. H was simply an exploration of that "etc. etc." ;-) It is true, of course, that RSA's SecurIDs -- which are always on; continuously displaying their 60-second OTP token-codes -- have a sealed capsule, and are sold with a pre-programmed lifespan, to a date certain, of 1, 2, 3, 4, or 5 years. (The SCA threat, as it gets more widely acknowledged, may underscore the value of a sealed token.) It is also true that most competitive OTP vendors, like Vasco, sell "event-synch" (click for an OTP) tokens with either (a) a replaceable battery for eternal life, or (b) a sealed capsule which, with a click, will produce OTPs on demand until the token's internal battery gives out, nominally somewhere between three and seven years. These have been basic Facts of Competition in the 2FA token market for well over a decade -- but I have yet to understand the implied moral superiority in Mr. Harminc's suggestion, echoed in bales of competitive literature, that RSA is somehow cheating, or doing a disservice to its customers, when it sells SecurIDs that "expire by design before the end of their natural battery life." The SecurID tokens are only one element in RSA's authentication service, which is packaged and priced, per year, to meet the needs and expectations of its customers. Historically, cost is only one of many factors involved in a decision to purchase critical infrastructure -- and seldom is it a determining factor. RSA is rarely if ever the lowest-priced option, but RSA's choice of design, functionality, pricing, and packaging -- buttressed by its partnerships, and its extensions on its basic 2FA services for everything from SSO, to Federation, to Windows XP logons -- for its SecurID infrastructure has generally found favor in the marketplace. With over 19,000 SecurID installations world-wide, as I noted, RSA is estimated to supply some 70 percent of the enterprise demand for OTP tokens But what's the OTP product and what's the authentication service? And is the distinction critical, or even useful, as the global market evolves toward a networked service model? While a number of other OTP vendors are trying to standardize around OATH's SHA-1 design for a single token, RSA is arguing for cipher agility, fostering discussion of high-assurance certs among CAs; and publishing a series of standardized templates which offer developers guidance for securely integrating OTPs and 2FA validation into a wide variety of emerging products. See the One-Time Passwords Specifications at: <http://tinyurl.com/3w7c7> To meet the needs of financial institutions worried about consumers being forced to carry multiple SecurIDs, RSA and eTrade Financial, the online brokerage, are now beta testing a new Internet-based authentication service through which RSA will only validate a SecurID "token-code" for financial institutions which are willing to accept and co-validate, with a separate password, 2FA from a consumer holding a SecurID originally issued by another institution. (RSA will validate the OTP, for a user previously registered, by SecurID serial number and a PRN pseudonym, by an authenticating institution -- but only that financial service firm or bank will have access to the account information associated with the authentication call. In this limited service role, RSA's can't even identify the individual; it simply blindly validates the OTP factor for the inquiring financial service firm.) Given the range of RSA's initiatives in products and services, it's hard to go "off topic" -- but it's been a quiet afternoon, and I probably pushed the envelope. I beg the indulgence of the Listocracy for the length of these comments, and some admittedly OT ruminations. Withall, I submit the facts that I reported about the relative integrity of the various OTP tokens -- in particular, their respective resistance to direct but perhaps non-destructive physical attacks, using side-channel (SCA) attacks -- are at least as relevant as Mr. H's niggling concerns about pricing models. Those who have the responsibility to secure high-value mainframe environments will decide just how important. I have been a consultant to RSA Security for many years, and my bias is obvious and acknowledged. Suerte, _Vin ------------------------------------------------------------ Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]> 22 Beacon St., Chelsea, MA 02150-2672 USA
