From vin@shore.net Thu Aug 29 03:39:24 1996 Received: from relay1.shore.net (root@relay1.shore.net [192.233.85.129]) by suburbia.net (8.7.4/Proff-950810) with ESMTP id DAA03478 for ; Thu, 29 Aug 1996 03:38:43 +1000 Received: from [204.167.109.53] (pm3-53.lynnma.shore.net [204.167.109.53]) by relay1.shore.net (8.7.5/8.7.3) with SMTP id NAA12015; Wed, 28 Aug 1996 13:37:34 -0400 (EDT) X-Sender: vin@shell1.shore.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Aug 1996 13:35:23 -0400 To: sdadmin@jabberwocky.bbnplanet.com From: vin@shore.net (Vin McLellan) Subject: RE: SecurID Cc: woods@ucar.edu, best-of-security@suburbia.net First things first. In the interest of fair debate (and the harmony of my home) let me declare forthwith that I have nothing but the highest regard for professional contract negotiators -- at NCAR, SDTI, or elsewhere. (Perhaps I didn't mention that my mate is an upstanding member of that honored profession;-) I also spent several years as Asst to the Prez of a $600 million research institution, however -- and while in that harness I learned the dangers of pitting two capable gladiators (contract negotiators, lawyers, etc.) against one another... with no instructions beyond getting the best possible deal for their respective institutions. That said, I may escape poison in my soup. Greg Woods wrote: >It was not my intention to compare Microsoft and SDTI and I am sorry if >I gave that impression. All I wanted to do was refute the argument that >the largest market share implies the best product. It's interesting how different people look at the same thing and see different facts. Mr. Woods, to the extent that he recognizes market share, sees only that an SDTI factory somewhere that ships out so many truckloads and says: "That's irrelevant as to whether this product is good or bad for my site." He is, of course, correct. But I look at the very competitive market for OTP authentication systems, and the fact that the ACE/SecurID system is widely regarded as the dominant market leader, and I think: "Ok! What this means is that every year hundreds of guys like Greg Woods, or his boss, evaluate seven or eight alternative OTP products and decide, on balance, that the ACE/SecurID system is the best for _their_ particular sites!" Mr. Woods gets upset when I suggest that all those Purchase Orders mean something. I believe they indicate that a lot of smart people have evaluated the multiple competitors and decided that ACE/SecurID -- despite the imperfections, flaws, and foibles of SDTI's products and services -- is the best of the alternatives. (At least, to use somewhat dated figures, in 80+ percent of the sites with 1,000-plus authentication tokens.) No one -- certainly not I -- can contradict Greg Woods when he reports that, in his judgement, the ACE/SecurID system is poorly engineered for his 10-token environment and that Digital Pathway's SNK tokens would be a better and more cost-effective buy for his site. But when he published this in a Internet forum like BoS, I suggested that SDTI dominance of the token market implies that many other professionals disagree... and that his ten-token site might differ significantly (not least, in size) with most current or potential ACE/SecurID installations. It is doubtless true that many of the ACE/SecurID strengths as a system -- scalability, pre-programmed tokens, RDBS, ESQL and 4GL capability, etc. -- seem to provide benefits of greater value to large (or at least larger) installations... but really, the Defender server and SecureNet Keys??? On religious grounds, I've never liked SNK tokens because each holds within itself all of the user's secrets (PIN, secret seed, and algorithm.) I also think the Defender -- which supports authentication only on dial-up lines (not for local site access,) and only on NT and Netware links -- is strangely limited. (The two people I know who carry SNK calculators carry them in little plastic audio-cassette cartridge boxes so they won't accidentially deprogram the tokens... and neither of them has been able to replace one of the two SNK batteries without blanking the card;-) (Did anyone read the shakedown on the DPI Defender server in "Network Computing" a couple months back? There was a notable quote: "Buried deep within layers of irrelevant software, there may be good security technology here. We just couldn't find it......It has attempted to adapt the security components to a general perimeter protection mechanism, but the transition is not complete.") Mr. Woods wrote further: >I did not say or >mean to imply that there was any other similarity between the positions >of MS and SDTI. My only comparison is that in neither case does largest >market share imply that the two companies therefore have the best >product, which Vin did try to imply several times with regard to SDTI. Un huh. With Msoft's effective monopoly, market share doesn't tell us squat about the "relative" quality of WinDos. But again, SDTI doesn't have anything like a monopoly... and the fact that a significant majority of site and security managers purchasing HHAs today compare ACE/SecurID against 7-10 competitors and choose SecurIDs _does_ tell us which product _they_ consider "best" for _their_ sites. Mr. Woods seems to believe SecurID became the most popular hand-held authenticator by luck or chance. He was led to that conclusion, in part, by his assumption that the SecurID was the first OTP token on the market. Dave Goldberg corrected him with a brief summary of the early market: Racal, Sytek, Enigma, and Gordian. I would add Digital Pathways, which I recall as the first (?) to market. The SecurID went on sale maybe two years later. Amy Chused also pointed out that Mr. Woods had misread his license when he complained that SDTI would charge him a higher license fee if he stored additional, unassigned, SecurIDs on-site for emergencies. Ms. Chusack thought that the SDTI license allows a customer site to hold 2 unassigned tokens for every 10 licensed SecurIDs. Actually, the license allows the ACE sysadmin to hold a spare token for _every_ licensed user. With a ten-token license, NCAR can have 20 SecurIDs on-hand and registered in the database... but only ten can be enabled at one time. Mr. Woods complained that I has "mischaracterized" his comments and set up "a straw man." I don't think so. (I do think for him to declare now that he "never claimed SecurID should bend to our wishes" is disingenious.) I certainly never meant to be disrespectful, nor dismissive. (Without going into details, let me report that I know there has been e-mail between SDTI and NCAR which I hope will allow Mr. Woods to implement ACE/Clients on the multi-homed machines he specified.) Personally, I have always believed that the most important customer is the "unhappy" customer... just because he or she informs a vendor about what must be reviewed or improved. Mr. Woods also asserted: > ... ... I happen to feel that the server breaking >because the client is multi-homed is a bug, not that having multi-homed >clients work correctly is a feature. Ditto for the server; I can think >of no reason why the server should break because it runs on a multi-homed >host. None of the other software I work with has this limitation. >And believe me, I am *happy* to hear that multi-homed clients now work >under the latest version. I do in fact have an upgrade in progress. When network components with multiple network interfaces (notably double-homed firewalls) became a significant factor in the market, the ACE system was changed. It had to be modified because the IP addresses of the ACE/Client and the ACE/Server are used -- together with a client-specific node secret -- in the encryption and authentication protocol which secures communications between the client and the server. (What's a bug and what's a feature?) The mutual authentication and encryption of traffic between the client and the server -- which Mr. Woods dismisses as worthless -- was, and is, considered a feature by many buyers and sysadmins. Adapting that feature to multi-homed firewalls, and getting the release into the field, took a few months;-) Adapting installation procedures so as to use a 2.X ACE/Client on other multi-homed platforms seems to require, in most cases, just some additional fieldwork and testing. >... ... I can think of no reason why the server should break >because it runs on a multi-homed host. Well, let's consider this. One issue might be service quality. ACE uses UDP for communications between the client and the server, so the ACE/Client would poll for a server interface (five-second wait; default) three times before it moved on to another server interface, polled three times, and so on. Only after polling all server interfaces would an incoming authentication query from a Client be switched over to the backup slave ACE/Server. With a multi-homed Server -- say, with four network interfaces -- that could mean a delay of one minute before the client realized the ACE/Server was down and switched to the slave. There are probably workarounds (and, of course, there is always the option of rewriting the code to use TCP -- but that may be no improvement, since UDP time-out is specified in the app, but tcp time-out is specified in the OS, where it affects many other apps.) I suggest, however, that there are valid concerns about using a multi-homed server with a SecurID which produces a token-code valid for only 30 or 60 seconds. (You could use a special-order SecurID with, say, a two minute token-code?) I'd be interested in hearing how competitive products, which Mr. Woods says can already handle multi-homed servers, actually manage the time-out and switch over to a backup server. Only SecurIDs time-out (a bug or feature?;-) but both Enigma and DPI use UDP polling too. I'd also worry about maintaining a connection through some dialup servers, or comm servers on a remote net, while the client leasurely polls multiple interfaces on the authentication server. With regard to his intention to run an ACE/Server on a multiple-homed platform which also supports various other applications, Mr. Woods offered an eloquent defense of a site manager's perogative to use more or less secure configurations, depending on what assets he is protecting, the threat environment, and his budget. I suggest, nevertheless, that a vendor of security products may choose to design a product so as to _preclude_ its use in some high-risk configurations... or, at least, refuse to redesign that product so that it (and the assets it protects) can be easily placed at risk. I don't know what SDTI will do, but -- until or unless a notable portion of your user base wants to use some relatively threat-laided configuration -- why push a good product into a high-risk nitche it was not designed to effectively and safely support? Suerte, _Vin Vin McLellan +The Privacy Guild+ 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*>