(January 1998)
|
|
Firewalls (January 1998) |
Kathleen Gordon <kathleen @ montana . msfc . nasa . gov> suggested a challenge to SDTI: > If both your primary and secondary ACE Servers > fail, and your primary server is down for the count > (IOW won't come back up), but your secondary > server does come back up, will logins be serviced > alright from the secondary server? A. Yes, they will! Ms. Gordon said she ran into a problem with this in an evaluation of ACE/Servers for NASA, but I couldn't find a report of the problem or a fix -- so her review must have been 3 or more years back, at least. Zounds! That's two, three, generations in server technology! Just to make sure, I had someone crash a 3.01 ACE/Server and its slave, and bring just the slave back up. He said it served incoming authentication calls fine. In a number of posts, reps from other OTP vendors made impressive, sometimes awesome, claims. I don't want to rain on anyone's parade, but surely a healthy skepticism is warranted. (As always, the best test of such multi-server, million-user, claims is real-world experience. Demand a reference for any vendor's two biggest customer sites and seek wisdom & truth from the harried veterans in the trenches. The Listocracy here -- privately if not publicly -- could probably help you identify the big ones;-) Bruno Coelho <akbal @ visualnet . com . br> wrote: >I think that the great advantage in Security Dynamics SecurID >products is the ability to use it anywhere. I mean, you don't need a >special hardware reader, you simply look at the display for the >information you need to put together with your PIN to complete >your password. Yup! Ease-of-use and portability of credentials. Virtues not to be taken for granted. (To reclaim another, check out Farrell McKay's freeware Fortify at: <http://www.fortify.net/>) >This way, I can carry my token anywhere being sure that I can >authenticate myself to my company's webserver wherever I go, >without having to carry with me a smart card reader or a thumb >reader. :) For want of a reader, I like the "soft smartcard." Used in conjunction with an hand-held authentication token like the SecurID, it can be stored encrypted on the PC (to be unlocked with a key downloaded from a remote server,) or the whole PKI-credentials package can be downloaded from a network server to wherever a SecurID user logs in from. With a optional cache that allows restricted access on the local workstations (password protected) prior to a network login, this is the transition path SDTI has chosen. Soft smartcards will be the bridge between SecurIDs as classic OTPs and smartcards, keyed and certified. RSA's public-key crypto has the magic, and SDTI is betting that its experience supporting large user communities will make it a productive partner within any corporate PKI. SecurID smartcards are already being shipped. With a SecurID seed and hash, the SecurID smartcard is backward compatable with existing ACE/Server installations, but it's also loaded with RSA PKI keys and certs which can support SSL and S/MIME in _either_ the Microsoft or the Netscape browser/mailers. (Bigger deal than it sounds, given the two wholly incompatable formats;-) The same X509 certs will also support SDTI's own array of BoKS network security features. And since time-synch will lose most of its ease-of-use advantage with a direct connection between the token and the net, SDTI's smartcard also has RSA challenge/response -- a forward-compatable link to an "all-smartcard" future. Storing your PKC keys and certs off-line, in a personal smartcard for pocket or purse, obviously offers greater security (and doing your encryption in the smartcard offers still more) -- but soft "smartcards" implementations are surely more secure than the all-software "soft tokens" so popular on corporate networks today. Moving to PKI also offers vastly more scalability, greater security, and valuable new desktop functionality to the user. It also opens up range of powerful security tools for the network manager, from single sign-on up to a "wrapper"-based asset-by-asset access controls of the sort previously available only with Kerberos and rewritten apps and clients.. SDTI calls this modular plug-n'-play <blush> architecture "SecurSight." Not to duck the question of the perfect token, but the question, Bruno, is when (not if) the value of cryptographic confidentiality and the utility of digital signatures -- and the additional confidence you gain by holding your PKC private keys more securely, perhaps outside the PC -- will lure you and/or your organization into PKI. Users will want PKI for one array of functions; network managers, infosec pros, and auditors will prize it for another. There should be no need for you to sacrifice mobility, and hopefully little in the way of added complexity (at least for the user!) -- but the upside could be enormous. In your situation, SSL and ACE/WebID now give you confidentiality and strong personal authentication when you use SecurID to connect to your website, but soon -- with a PKI digital signature (using keys and certs you trust are secure) -- you could also sign invoices, approve contracts, issue RFPs, bid on contracts, transfer funds, fire your broker, file for divorce, etc. All the basics of modern corporate life. There is a whiff of vapor here (v.1 SecurSight Desktop is due Q2; with more rollout thru Q4) but the base functionality of the new SDTI product mix is in the installed BoKS products today -- with an impressive list of major customers running robust security services from multiple servers in well-documented bet-the-company environments. SDTI's net security architecture also picked up a powerful endorsement when Sun licensed the SecurSight (BoKS) Manager from SDTI and announced it as their "Sun Security Manager." Michael H. Warfield <mhw @ WittsEnd . com> wrote to offer a bitter war-story of "technical people" being quashed by his MIS director and cold-shouldered by what I presume to be a saleman for one of SDTI's VARs. No one can do much about the office tensions Mr. Warfield described, but info on SDTI technology (or competitors) doesn't seem hard to come by -- for customers, prospects, or anyone. No matter how mute the salesman, this and numerous other lists are full of veterans. No reputable vendor should deny your request for reference sites with scale and distribution problems similar to your own. If you've got 50 users, demand to talk with a similar site. If you've got 20,000 users, demand a big-site contact! SDTI usually sells through a Demo install, so a prospect's tech team gets an ACE/Server to play with before he buys -- and free access to both SDTI Customer Support and SDTI's Sales Support Engineers (SSEs) while they run the Server through its paces. In my experience, CS and the SSEs are today well-informed and capable. It is true that, over the past two years, the depth of SDTI's technical base has grown by an order of magnitude. They've got their ESS development (re-engineering the ACE/Server as a key and cert manager;) RSA's crypto initiatives; and the integration of RSA and the BoKS' SSO, PKI, and multi-server technology into their SecurSight architecture. That's no excuse for evasive salesmen or imperfect support. (Also, MIS managers who don't cater to their juniors should be forced to recall their youth, when they too knew everything.) Oh, I agree! Off with their heads! But am I surprised if some VAR's road warrior finds himself out of his depth? Not likely. The whole of SDTI is on a study-jag! It's exhilarating just trying to keep up. I beg the pardon of the List for the length of this reply. I've been off-line and e-mail & CCed messages from this thread had stacked up. Suerte, _Vin Vin McLellan + The Privacy Guild + <vin @ shore . net> 53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548 -- <@><@> -- References:
|