From woods@ncar.UCAR.EDU Sat Aug 24 03:36:53 1996 Received: from ncar.UCAR.EDU (ncar.ucar.edu [192.52.106.6]) by suburbia.net (8.7.4/Proff-950810) with ESMTP id DAA18409 for ; Sat, 24 Aug 1996 03:36:17 +1000 Message-Id: <199608231736.LAA12988@ncar.ucar.EDU> Received: by ncar.ucar.EDU (NCAR Local/ NCAR Central Post Office 03/11/93) id LAA12988; Fri, 23 Aug 1996 11:36:00 -0600 (MDT) Subject: Re: SecurID To: vin@shore.net (Vin McLellan) Date: Fri, 23 Aug 96 11:35:59 MDT Cc: woods@ucar.edu, best-of-security@suburbia.net, sdadmin@jabberwocky.bbnplanet.com In-Reply-To: ; from "Vin McLellan" at Aug 23, 96 4:29 am From: woods@ucar.edu (Greg Woods) X-Mailer: ELM [version 2.3 PL11] > Comparisons between Lordly Microsoft, perched alone on its throne, > and SDTI 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. 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. > SecurID first came into this market playing catch-up against > established competitors, and I've never seen a paid SecurID ad. I would like to know who these "established competitors" were. I always thought that SecurID was the first OTP token. If I'm wrong, I am prepared to be corrected. > Market share counts Only to the degree that it implies some stability to the company. When I evaluate a product for us, I look at how the product fills our needs and I couldn't care less whether we buy from the company with the biggest market share or not as long as it's not a fly-by-night operation. > some 50 third-party vendors of network components -- including > Microsoft, as of Wednesday -- to integrate ACE/Client code into their > products. This is, in fact, a valid point and definitely one of the things I put into the plus side for SecurID. Their partnership with cisco is the reason why we have them here. > Seriously now: Greg Woods is obviously a very capable technical > manager. For the record, I am not a manager, I am a technical peon :-) > Every vendor has customers who insist that they deserve > more features for less money Vin is unfairly mischaracterizing my comments here. I've never said anything about what I think we "deserve". All I've said is that there are certain aspects of competitors' products that I like better than SecurID. I never claimed SecurID should bend to our wishes. This is a straw man. > demands some features before > almost anyone else (e.g., "multi-homed" ACE/Servers,) but he keeps > beating on the vendor to deliver others (e.g., multi-homed clients) long > after they've been widely-installed as upgrades in the field In fact, all I have done is to point out that in the version of the product that was delivered to us, multi-homed clients didn't work. And I've asked for workarounds and pointed out why the workarounds suggested do not work in our environment. And 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. > > 2) Multihomed servers don't work (is that true?); > > Yes, it is true. ACE/Servers need a declared IP address. > Multi-homed platforms have more than one. Of course, it is also true that > an ACE/Server only needs that one network interface! I believe *we* should be the ones to determine whether or not we need more than one network interface on our security server, and the fact that the ACE server doesn't allow this is a limitation that some of the competitors' products do not have. We happen to feel that some redundancy to insulate against failure of network routing devices is desireable. We think the ACE/Server does in fact need multiple interfaces! > > This issue arises only if a site insists on sharing a machine > between an ACE/Server and other network services or applications -- This is also our judgment to make. > something recommended by nobody, since it inevitably introduces an > array of additional threats to the authentication server. Not everybody that cares about security has ultimate security as the number one overriding all else priority. Security, as I am sure Vin is well aware, is a process of evaluating risk and solutions that can mitigate that risk. Every environment is different in terms of how much risk you are willing to accept and how much user inconvenience and cost you are willing to endure to mitigate that risk. I believe that if the machine is properly secured in the first place, that the additional risk of running other security-related services on that system is minimal. Anyone who has gotten into a position where they can launch attacks on the ACE server machine has already broken our security, so the fact that they might now have a slightly better chance to compromise the ACE server because that system is running other services is inconsequential. On the other hand, the hassle and cost of having to maintain a separate system just for the ACE server, which we will probably now have to do given that the ACE server doesn't work on multi-homed systems, is considerable. It makes other vendors who do not have this limitation look more attractive. That's my evaluation based on *our* environment. I do not claim that this evaluation applies to everybody else's situations. > > 3) There is no batch interface to the administration, so I must > > use cumbersome menus; > > I know many ACE sysadmins believe this has been a historic > weakness in ACE administration, but most large ACE 1.X installations > seemed to use send/expect scripts for batch processing of token/user > records with great effectiveness. That's a kludge, and I have to develop the scripts. It's not undoable, it just adds an extra hassle that I don't have using a TIS server. And guess what? The version of the ACE server delivered to us had a bug where the sdadmin program didn't work when it was reading from a pipe, so even this kludge couldn't be implemented. Again, I am glad to hear that, perhaps, some of these problems have been addressed in newer versions of the server. When I have 2.2, I will certainly let everyone know how it works for us if there is interest to hear. I do want to be fair. > > 4) The tokens are disabled far too easily by naive users (we've > > got a bunch of them here) who do things like try to open three > > windows at once; > > It is true that someone has to explain a few rules and procedures > -- some site-specific, some ACE-mandated -- to SecurID users. All I'm saying is, there are some things that are a problem with SecurID in some situations that *our* users seem to encounter that are not a problem with the competitor's products. > Token failures are rare, but putting a few dollars into > pre-purchasing additional SecurIDs for emergencies is good budgeting. You haven't looked at our situation or our budget, so I don't see how you can make this judgment for us. We have a 10 user license. We have 10 users who need SecurIDs. To allow for one more user, we'd have to double the license fee and go to a 20 user license because the licensing policy of ACE is relatively inflexible. With some of the other vendors, we just buy another token and we don't have this problem. > Typically, a site will need them for new users, anyway. In that case, we're not typical. We have a small and stable set of people who need access to the ciscos. The user set hasn't changed in two years, except for one staff position that turned over. > OTOH, this is a serious complaint. A customer should be able to > get replacement tokens rapidly. We *should* just be able to hand our user a new token from our own stock, without having to pay license fees for tokens that are just sitting around as spares and not in active use. > This limitation applies to TACACS only. Upgrade! With TACACS+, > you can do New PIN Mode with Cisco We're already investigating TACACS+, and this is great news! I was not aware of this. > ACE administrators can use a telephone to get a current token-code > from a user ...a hassle that is not required with tokens from other vendors where the user can program his own PIN directly into the token.. >manually enter it from "sdadmin" Not with the version I've got. And again, I'm happy to hear that the new version will allow this. But it doesn't solve my real problem which is that I want toe *user* to be able to set the PIN *without* requiring any of my time to do it. The above solution with TACACS+ on the cisco is much more to my liking. > > 7) Just to even test the SecurID product here required the > > signing of lengthy legal documents containing many provisions that > > our Contracts department found unacceptable > It's hard to take this complaint seriously. Fine, then don't take it seriously. But there were other vendors who shipped us demo products without requiring all the legalese. With one vendor, all we had to do was agree return or purchase the product by the end of the trial period. I didn't even have to send that through Contracts. I had the product in my hand within days, instead of the weeks it required for SDTI. > SDTI puts restriction on even > demo installations because it doesn't want ACE code circulating to > every Tom, Dick, and Hacker. Some of the competitors use publically available code. I'm using Digital Pathways SNK tokens with the TIS toolkit; didn't have to use any proprietary code, so this wasn't a problem. And the TIS server works just fine with multi-homed clients and servers. No arbitrary and unnecessary limitations. > Shipping fees and taxes I don't know about, but -- like spare > tokens -- this seems to be a complaint about Small Change. In which case you didn't really understand the nature of my complaint. I won't try to defend our Contracts people (despite Vin's ad hominem attack on "the pride of NCAR", a really cheap shot), because I don't understand their jobs. I'll just say that the problem wasn't the money, it was the time it took to get it done. Time I didn't have to take with Digital Pathways. > And it is a _free_ demo. As it was with the competitors. --Greg