Danny Cox <dannyc @
gmap .
leeds .
ac .
uk> asked for comment about the
relative security of a Shiva communications server with SecurID-based user
authentication to safeguard dial-up access. A number of helpful guys
addressed aspects of SecurID on Shiva, and Ken Atkinson unloaded a crib
sheet from the Shiva manual. Mr. Cox is worried about a number of specific
concerns:
> I see no mention whatsoever of encryption between a user and the server
>here. That seems to me to allow us to be utterly dependent on the security
>at the other end therefore. If someone can crack the network/system at the
>other end and hijack the session then we're screwed .. of course I *might*
>be over reacting
Over-reacting? No such thing on this list! Your concern about the
alien net at the other end of the line is obviously warranted. Someone
*should* be concerned with the scope and security of any network that feeds
into your proposed Shiva gateway. (Your worry about session hijacking is
particularly pertinent. No one has yet gotten a grip on the "active
sniffer" threat.)
Unfortunately, I don't think you give us enough information about
your environment, or the type of Shiva device(s) being considered -- or the
architecture, scope, or security of the other network -- to allow anyone to
advise you intelligently.
The question of crypto is really an issue of cost and risk
analysis: what is the likely or potential exposure for your company? The
other net? Like Mr. Rattray, I generally trust phone dial-in links more
than IP networks (although I know phone phreaks and telco security techs
who can curl your hair with warstories; and unsecured telco or on-site
phone line cabinets abound;-( <sigh>
Shiva communication servers generally support SecurIDs in one of
two ways: with a stand-alone hardware ACM box which handles authentication
from somewhere between the modem and the Shiva device, or an ACE/Sever
which is UDP linked to ACE/Client code now imbedded in the standard Shiva
remote access server. From your comments, you are unfamiliar with SecurID
OTP tokens -- so I presume your own net doesn't use robust authentication.
You may, in that case, better off with the ACE hardware box.
If, on the other hand, your system administrators are considering
adding ACE/SecurID authentication your client/server network, there are a
number of additional options with interesting ramifications.
If you have an ACE/Server supporting your site, all transmissions
between the Shiva's ACE/Client and the ACE/Server are encrypted.
Unfortunately, that covers only the authentication exchange. It protects
the PIN and the SecurID's 60-second token-code (and it both allows and
requires the ACE/Client and the ACE/Server to mutually authenticate, with
every SecurID authentication call) but it does nothing to encrypt or
protect the session.
C/S architecture also raises the possibility of placing an
ACE/Client-loaded Shiva device at the far end of the (ISDN?) line, on the
other network. In that case, the mutual client/server node authentication
you get with SecurIDs could be quite useful.
An ACE/Server can also restrict the use of any specific SecurIDs,
so that they will only be accepted if they are used to enter the protected
net via a specific ACE/Client, or only on certain days, or only during
certain hours, or only when the moon is full.
In general, Dan, if a dial-up link is the occasion for your
managment to introduce robust two-factor OTP authentication (SecurID or any
other) into your environment, I'd say -- if you are concerned about
security -- that's "good clear reason" to feel happy about it.
Suerte,
_Vin
Vin McLellan +The Privacy Guild+ <vin @
shore .
net>
53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548
<*><*><*><*><*><*><*><*><*>
|
|
