Re: SecurID White Paper - A Comment

[vin () shore net (Vin McLellan)]

         Michael Alexander <malex () kersur net> dropped me a  pithy note,
which I quote in full:

> [oration given while standing on a soap box 10 feet high]
>
> So, does this mean you agree or disagree with Neuman and the rest?

        Ouch! <sigh>

        Mike Neuman <mcn () EnGarde com> was right three/four years ago when
he said then that TCP-splicing is a real threat.  Mike was wrong, then,
when he predicted that such attacks would soon be the universal experience
of the Internet-connected user community.  So maybe he's wrong now (but
doubtless less so;-)

         Ok. I obviously agree with Mr. Neuman that SecurID-plus-encryption
makes the strongest combination for authentication, confidentiality, and
message integrity.  I also think we need all three. I even agree that
session hijacking is a huge and serious problem, and might rapidly become a
critical one.  I disagree when he claims that SecurID (or other two-factor
OTPs) are worthless where they are currently installed... or that sensible
managers might not -- even now, within sight of Armageddon, so to speak
(News at 11! w/ GIFs) -- find valid reasons to purchase and install
one-time password systems, without encryption, in various environments.

        Eventually, I agree, economics, prudence, and the state of the art
-- and/or the IETF or Microsoft -- will lead us all to encrypt, all of the
time.  (I presume this has something to do with why SDTI bought RSA.)  The
question is whether someone is today a fool to install SecurID or some
other two-factor OTP system.  Mr. Neuman has argued, for some time, that he
is. I disagree.

        My point is: the decision to encrypt should be (must be!) a local
decision by someone who considers the value of what's at risk, the cost of
crypto, and the problems and economics involved in using, maintaining, and
scaling network crypto, internally and externally.  The very same logic
applies, in rerum natura, to the purchase of OTP tokens today.   Local
environments are too complex and varied; and Universal Truth a scarce
commodity.  Pundits like Mike, Frank, and I can have our say; but I don't
really believe we can place ourselves in the shoes of the guy who has to
make the annual budget decisions and live with the results.

        TCP-splicing, aka "session hijacking," is one factor he should
consider. But the prudent administrator will make a balanced judgment that
takes into account what he has at risk from this sort of attack; the
professional consensus as to the likelihood of such an attack; the cost of
network crypto; and the cost of various alternatives which might more
effectively limit his exposure. This discussion, and others like it, can
influence only one factor in that equation... probably the least important
one.

        As the threat of session hijacking grows -- and with the
publication of attack code in 2600 and Phrack, and the distribution of
powerful freeware packet-manipulation tools like Netcat, it might be about
to explode -- more of us will doubtless choose to buy link or
application-level crypto. But it is, and should always be, a cost/benefit
calculation. Not a bribe to keep the boogieman away.

        Despite anecdotal evidence and the acknowledged vulnerability of
the TCP/IP network, but blunt fact is that session-stealing on TCP network
links has apparently not yet led to attacks numerous enough, or serious
enough, to draw the attention of CERT or CIAC, for instance, or the various
FIRST organizations.  At the US CERT, on the other hand, there are often
multiple daily reports of successful attacks which used password grabbers
(both sniffers and trojan horses) to exploit traditional "reusable"
passwords.

        OTPs serve purposes other than safeguarding network TCP links from
session stealing. In many organizations, these are seen as valuable
functions.  OTP tokens offer greater credibility to both audit and
accountability.  OTPs (as opposed to reusable passwords) protect against
replay attacks, but also against attacks on multiple other resources that a
user may be accredited to (and would often use the same password on, if he
had only reusable passwords.)  Even if a given TCP session is potentially
vulnerable to hijacking -- even if it _is_ hijacked -- the attacker gets in
but once, then and there... rather than (as in the case of a snatched
reusable password) getting unlimited future access: a key to the vault.

        Mike Neuman -- more terse than I; and probably better-looking as
well -- responded with his customary confidence:

>  Here's the reason you're wrong, and the reason one time passwords without
> encryption should be completely avoided:
>
>  What is the primary value of One Time Passwords? To eliminate the possibility
> that a sniffer can steal a password and reuse it. All other benefits are
> tertiary (i.e. To prevent password guessing? Most systems have limits on
> the number of guesses before an account is disabled. To prevent password
> file stealing and cracking? If your passwords are that bad, get npasswd,
> or any of the other products for VMS, IBM, NT, etc which enforce good
> passwords. For dialup? reusable passwords (which aren't transferred over the
> network in plaintext) work just fine when taken with account disabling and
> good password enforcement, AND they're a LOT cheaper than the $50/pop every
> 3 years for SecurID.)

          I think Mr. Neuman overstates how easy it is to maintain good
password management with reusable passwords in large networks... and,
again, underestimates the complexity of the varied application
environments. As far as the economics, that's really for the market to
judge; a balance of tangible and intangible coin.

        What those managers who buy ACE/SecurID get is an easy to use,
two-factor, OTP that times-out quickly; blocks replay attacks; blocks the
passive sniffers and trojans known to be in widespread use; and validates
-- to a high degree of certainty -- that the person who was issued that
token did initiate a particular online session.   Despite what it doesn't
do (i.e., secure the network,) what it _does_ do is valued by many CIOs,
auditors, etc.

        Mr. Neuman asserts that SecurIDs provide "no additional  benefit"
over reusable passwords when used on a cleartext Internet connection. I
suggest this overstates his case considerably, in light of the current
prevalence of stolen passwords and replay attacks.  [I'm also a little
confused at the wording he uses to dismiss or devalue OTPs in dial-up
environments: "reusable passwords (which aren't transferred over the
network in plaintext) work just fine when taken with account disabling and
good password enforcement...."  Without encryption or OTPs, reusable
passwords _are_ transmitted in plaintext, aren't they??]

>  So, if the primary purpose in using SecurID is to eliminate the
> effectiveness of sniffers, then guess what--a hijacking attack is a VERY
> simple modification of a sniffer. So, your "elimination of the effectiveness
> of sniffers" is now anything but.

        What I think Mr. Neuman overlooks is the fact that the OTP token is
only one part of the security infrastructure, part of the toolkit every CIO
relies upon.  Where an attack like TCP-splicing threatens to subvert an
OTP-authenticated session, other tools can pick up the slack.  Crypto is
one way to enhance OTPs, granted; but in many sites there are already
additional defense barriers  -- choices in network design, routing,
internal firewalls, multiple levels of authentication, restricted
applications, etc. -- that a net security manager can use to minimize his
vulnerability to an known attack along a given route.

        Not all data links are TCP; and not all TCP links are equally
vulnerable.  I noted earlier that the overwhelming majority of OTP
two-factor tokens are today used to safeguard dial-in phone links,
typically through a comm server of some type.  Many sites -- quite
reasonably, it seems to me -- believe that these installations are
considerably less vulnerable to TCP-splicing than open network links, since
a bad guy can access an ongoing connection only through a wiretap.  In that
milieu, I argued, OTPs like SecurID provide significant protection.
PeiterZ <Peiterz () silence secnet com> responded:

> >        Please come into the 90's Vin. If your security is in having an
> > unmonitored connection why not stop selling telnet clients for the SecurID
> > card or at least market it to dial-in type customers. Why not? Because
> > there's more money selling into the 'net', whether or not the application
> > is particularly suited for it or not.

        Uh, not yet there isn't.  At least not among those selling
authentication tokens. Neither Unix nor TCP has changed much (part of the
problem, right?) but everything else -- including ACE/SecurID and its
competitors -- is changing very rapidly. The market a year from now -- and
the new ACE 3.0 protocol, due out this fall -- may be much more geared to
IP networks, maybe even encrypted TCP/IP networks... but the installed base
of OTP tokens, and current buys, are still largely supporting dial-in
links.

        (Another market artifact: the OTP salesmen I talk to tell me the
growing interest in encryption on network links is largely pushed by the
users' demand for confidentiality... not any concern from the CIO or
corporate security mavens about session hijacking.  CIOs are all bred in
Missouri.)

        Internal networks are also often seen as less vulnerable than
Internet links. Although both may be, technically, equally vulnerable to
both sniffing and session hijacking, insiders are feared less than
outsiders (often irrationally;-) There are also -- even within networks
connected to the "outside" -- those internal defense barriers. Many
client/server environments, e.g., already require multiple OTP
authentications, which can lessen the depth of a TCP-splice attack (since a
hijacker, after all, can only ride the coat-tail, and steal the coat, of a
legitimate user.)

        When a traveling executive accesses his e-mail server with SecurID
over the Internet, he might possibly be hijacked.  That might be
embarrassing... but it's nothing like the danger involved in having a
Pirate win access the corporate financial reports or development plans, for
instance. That data, if on another server, could (even likely, would)
require an _additional_ SecurID token code... or (perhaps best) might be
simply unavailable through the ACE/Client which serves external network
links.

        This level of control varies with the OS environment and the OTP
system. DPI offers only remote access control -- generally through a comm
server or modem -- but for a Unix environment, both Enigma and SDTI, e.g.,
typically demand authentication, and control access, by the server.

        For a Netware environment, I believe Enigma provides remote access
control.  SDTI provides both remote access ("gateway" control, typically
for a comm server on the phone line) as well as server-based ACE/Clients,
at least in the Netware 3.X environment. So a Netware user  will generally
face repeated demands for SecurID authentication as he or she requests
access to different or additional internal servers.  (NT environments, with
cross-realm authentication, are a different kettle of fish.)

        In all three environments -- with the ACE/SecurID system, at least
-- specific applications (e.g., a database) can also be made to demand
additional SecurID authentications.  One potential response to the hijack
threat -- enough, for now, at some sites -- might be to restrict the use of
Telnet (two-factor-OTP protected, of course) to non-critical applications.
Period.  OTPs often make this feasible, where the use of (multiple)
reusable passwords would be a difficult solution, at best.

        PeiterZ reported that he and his associates were able to penetrate
SecurID-protected systems, apparently from the Internet.  I don't doubt it,
particularly if he was using TCP-splicing with, say, Hobbit's Netcat.  An
OTP, admittedly, does not secure the network.

        I would be surprised if PeiterZ managed to pull off a race attack
-- although, personally, I have always favored a longer wait-loop than the
2-second cycle used as the variable default on ACE/Servers (during which,
identical, or nearly identical, token-codes are recognized and both are
blocked.)  And, of course, I too look forward to the rewrite of five
year-old ACE protocol -- long promised and soon due -- which I will expect
will lock down a user's record when the authentication server receives the
first identifier, typically the user's name, as the answer needed to all
race attacks.  (Revising a protocol which has to remain backward compatible
to ACE/Clients imbedded in some 200 network products from some 50 vendors
is an interesting challenge;-)

        Of the other two categories of attacks described in his White
Paper, I'm certain the F2 attack will fail against the current generation
of servers, and I will be very impressed if PeiterZ was able to located a
WAN with a network design fragile enough to allow an attacker to breech the
network link in two or three places without being immediately detected. (A
local LAN, from the inside, maybe;-)  In any case, again, the integrity of
the network is not really something that any OTP token can guarantee.  I
also can't get too excited about attack scenarios which threaten Denial of
Service. DoS is simply the universal threat, like nightfall; against which
there is no effective defense with current network technology.

        Peiterz correctly pointed out that my objectivity in these matters
is perhaps suspect because I have been a regular consultant to SDTI since
the late Bronze Age, in addition to being the author of the SecurID FAQ.
(New version soon to be available at: <http://www.securid.com>)  I have
also been an advocate of OTP tokens since long before any arrived on the
market, and I remain deeply committed to the value of two-factor user
authentication.

        PeiterZ also expressed umbrage that I had referred to his
associates as "elite hackers."  I willingly apologize to PeiterZ, *Hobbit,
Adam Shostack, and the associates of LHT Industries: Brian Oblivion, Space
Rogue, Tweety Fish, Kingpin, Tan, Tom Icom, Veggie, Alice, Weld Pond, Dr.
Who, Jerry Omaha, Big Brother, Hotrod, Silicosis, Cybernetik, and Mudge
(whom Peiter thanks for their  invaluable assistance in his Paper.)  Is
this sensitivity a generational thing? I still use the term hacker with
respect.  I don't know anything about PeiterZ, nor most of the colorful
folk listed as "the boyz and girlz of LOpht Heavy Industries,"  -- but it
was an honest mistake, the LOpht web site positively wallows in its
Underground status. (The curious might check out <http://10pht.com>;-)  I
also doubt that *Hobbit, Adam, or Mudge would mind the label... nor let it
get in the way of their very considerable talents.

        Withal, given the quality of the talent brought to bear upon it, I
found the Peiterz White Paper an enormously reassuring document, evidence
of the resiliency of the aging ACE protocol.  PeiterZ would doubtless
disagree.

        Suerte,
                        _Vin

         Vin McLellan +The Privacy Guild+ <vin () shore net>
      53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548
                         <*><*><*><*><*><*><*><*><*>