Adam Shostack <adam @
bwh .
harvard .
edu> offered a useful warning:
> Encryption does not provide authentication. It provides
>privacy.
Two factor authentication remains the ID standard: something held,
something known, or a biometric. Adam also listed a few savvy cautions
about secure crypto management. Painless and transparent crypto remains
elusive, but it is surely coming. When it comes, however, it will offer
strong authentication only if it is tied with a two-factor personal ID --
that's an individual, a "person," being authenticated. Not a CPU; not an
office; not a phone line. It's a detail too often overlooked.
Frank Willoughby stirred another hornets' nest with his (somewhat
dated?) thumbnail analysis of which firewall products offer embedded
encryption as a safeguard against session stealing. Several people,
however, seemed to overlook the original context of Frank's remarks: a
discussion of dial-in security where remote _users_ on Windows PCs, not
remote firewalls, were seeking to communicate with Danny Cox's soon-to-be
protected network, perhaps through a Shiva NetRover.
Brain 21 offered a neat and accurate summary of the "active
sniffing" threat that Mike Neuman <mcn @
EnGarde .
com> has been drawing fire
for discussing publicly over the past few years. Mr. Neuman's description
of IP Watcher, a net manager's on-line combat tool he developed -- and
which uses the same active sniffing/spoofer tech to box, trap, trace, and
hijack or even reverse-hijack a session from a bad guy -- is at:
<http://www.engarde.com/software/ipwatcher/risks.html>
I had thought it possible to set up an alarm to sense the ACK storm
that typically follows a session hijack -- so the victim CPU would know it
had been attacked -- but Mike and Steve Bellovin clipped my wings by
pointing out that a clever and sophisticated attack could drop in and out
of the packet stream, leaving little evidence of what could nonetheless be
a devastating attack. The ACK storm is typical of the untutored raider,
common today -- but a pro could be deft and fast.
Mike has taken a lot of lumps for discussing this threat, I think
because the market was not (is not?) ready to adopt full encryption --
which Mike sees as the only defense against this threat. Many security
folk shy from mention of a problem with no effective or available solution.
(Part of the problem, too, may have been the fact that the document cited
above is both an IP Watcher marketing pitch _and_ a warning of the generic
threat from similar tools.)
I'd like to see Mike Neuman or others do a FAQ on this threat --
with, perhaps, more definition of the environments at risk, and a more open
mind on solutions. The essential defense against session stealing is not
secrecy, after all, but rather a guarrantee of message integrity or the
integrity of a telnet data-flow from user to host. IMHO, there may be
solutions that do not force users to commit to full crypto. Perhaps a good
and judicious thing, given the ambiguous attitude of the US and other
govts toward crypto?
A couple corrections on earlier posts of mine. SDI's director of
engineering called me up yesterday to tell me that SecurIDs with a
distress-codes are available -- and have always been available. My error,
sorry. (They are not popular in the private sector. Most of the sites
which use them seem to be .gov or .mil, in the US or abroad.)
I also erroniously empowered the new v.2 ACE/Server code with a
grandularity of control it does not have: Sysadmins can not, through the
ACE/Server, limit specific SecurID users to access only on some days, or
only some hours, or only when the moon is full -- although they can
restrict them to access only through one or several ACE/Clients (say, those
embedded in specific firewalls.) Lunatics are apparently a negligible
market....
Lastly, a very brief retort: Bob Bosen of Enigma Logic and our own
inestimable Padgett both suggested that a SecurID was something less than a
one-time password device when it was registered on multiple servers.
<sigh>
For six or seven years (nearly as long as I've consulted for
Security Dynamics,) SDI has recommended and sold a multi-seed SecurID --
with a pressure button in the corner, and an indicator on the LCD, to flick
from one token-code series to another -- for multi-realm networks. For the
past four or five years, SDI has also sold client/server systems which
support OTP tokens in many large and hertogenous IS environments (which
Enigma would support with multiple ACMs) with the a single ACE/Server, and
a slave backup.
In this client/server market -- with the SecurID's standard
client/server link fully encrypted -- users often choose to use a standard
SecurID with different (and now-encrypted) PINs to painlessly differentiate
their logon at any one authentication server, among several. Still and
all, I'll will be glad when SDI gets their communicating ACE/Servers into
the market -- it's obviously needed, if not a necessity, for a world-wide
Enterprise net.
Suerte,
_Vin
Vin McLellan +The Privacy Guild+ <vin @
shore .
net>
53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548
<*><*><*><*><*><*><*><*><*>
Follow-Ups:
|
|
