On Tue, 12 Sep 2000, Frank Knobbe wrote:
> You also need to consider the management aspect. How many users will
> be using it/them? What access (servers, vpns, applications) do you
I'm not sure that number of users plays too heavily into the equation
since both devices have such different failure modes. It certainly
changes the cost, but I've never used that as a primary design criteria.
I'm also not sure how you distinguish the server vs. application vs.
(yeach!) VPN scenerio, I've used both techniques for servers and
applications (I still think VPN failure modes are too high for anyone with
any reasonable paranoia.) While the mechanics are slightly different,
again the nonrepudiation factor would be a major determining issue for me
in most circumstances (if I don't need nonrepudiation, then certs are
easier, if I need nonrepudiation then certs are wrong.)
> want to authenticate? Can you use whichever mechanism you choose for
> other authentication, now or later down the road? What life span do
Both solutions can provide wide-ranging authentication, you can do the
LDAP-based thing with certificates and use RADIUS to an ACE Server, but
it's a different thing for some legacy protocols that don't bode well for
certificates (telnet and FTP for example- but ssh and scp are better
alternatives anyway.) Smart card access will solve the local login issue
(though I've heard of people doing that with floppies and certificates.)
> you anticipate? Who will provide support for it? These are factors
> that you need to include in your selection process.
Both paths have company support available, so again, I don't think it's
much of a differentiator. The only siginificant difference is
single-source implementation versus multiple source implemenetation. Once
you pick a two factor token system, you're tied to a vendor for the life
of the product.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
