A. Padgett Peterson's avuncular bias in favor of challenge/response
tokens -- and my own in favor of time-synchronous OTP security tokens --
are both known quantities.
Padgett's savvy iconoclasm is a treasured asset to this List, so I
suppose it should come as no surprise when he warns of doom and dead-ends
when he refers to Security Dynamic's time-synched SecurID -- a two-factor
HHA tech that, by patent, monopolizes time-synch in security tokens.
(Yet such denunciations are rare, particularly when they condemn a
widely-used security product. Since there has been so much misinformation
about this technology on the List recently, and since proper
ID/authentication of users and data objects is close to the core of
Firewall function, I beg your indulgence for an extended reply.
Corrections or criticisms are always welcome.)
With one million SDI tokens sold, these SecurIDs are notably the
planet's most trusted, popular, and widely-used OTP security tokens. Yet,
in the past week -- as Wall Street tripled (?) the market value of SDI to
give the company $100 million cash for R&D and marketing -- Padgett posted
five different messages in which he sketched vague technical (not
security!) concerns about SDI's time-synch (TS) technology and summarily
declared it as doomed as a Thanksgiving Day duck.
On Thursday, Padgett opined that TS -- apparently because of its
inherent "complexity" -- would emerge as a second-rate technology, despite
its current dominance of the OTP market. "Since Time Synchronous tokens
must operate in a 'window' to accommodate drift" in the electronic clocks
in the server/host and in the multiple TS tokens in the hands of users,
said Padgett, "they are at a disadvantage to Challenge/Response tokens.
"Not an insurmountable one," he mused, "but a significant one."
This, he implied, will become clearer as the OTP market expands to
highlight the potential of software-only pseudo-tokens, and as the Net
culture is finally allowed to take advantage of the enormous potential of
HHA physical tokens as crypto-key generators.)
But by Friday, Padgett was bluntly proclaiming the insurmountable:
"Time Synchronous is a dead-end technology." Again, he offered no real
explanation beyond his earlier (often inaccurate, more on that anon)
generalizations about the mechanics of SDI's time-synch. He had a couple
of specific points to make:
>1) I believe that the major token venders all use reasonably secure
> algorithms and proper separation of serial numbers from seeds.
>2) Having said that, I also believe that current uses only authenticate
> users to hosts (or men-in-the-middle) and do not provide any host
> authentication (could, just don't).
(Not true. In SDI's client/server architecture, per/call host
authentication _is_ mandated. (This is a third of SDI's client base now; it
could be half next year.) SDI's C/S protocol has the ACE client and
ACE/Server mutually authenticate every time they pass along a SecurID user
authentication query. Unless the host is authenticated, the query dies.)
> Even then are still susceptible to MITM and hijacked sessions.
(Unfortunately true. User authentication, per se, can't deal with
network
integrity. The answer is encryption, as Padgett also noted, or maybe a hashed
message digest to at least guarantee the integrity of the data flow.)
But then, he added:
>Now none of this has anything to do with why I believe that Time
>Synchronous is a dead-end technology.
Padgett concedes that users, without his background in security and
system design;-) invariably find SecurIDs much easier to use than C/R
tokens, a competitive tech offered by a number of vendors. But he
repeatedly expressed cryptic fears about the reputed difficulty, the
"complexity," of handling Time as a factor in the authentication cycle.
It's not that TS doesn't work, he said. (After all, it's been installed at
thousands of SDI sites over the past seven years.) And it's not that it is
in any way insecure, he said. So what is the problem?
"Clocks slip," he warned.
Tick-tock. Padgett's fears seem to focus on way SecurIDs -- and the ACE
Access Control Module (ACM) that supports it at the server/host -- depend
upon Time (or a mathematical notation of current time) to define a very
brief period in which the token's OTP (the pseudo-random number displayed
on the face of a SecurID token, changing every 30 or 60 seconds) will be
accepted as a valid ID authenticator.
Clock chips "drift;" i.e. they gain or lose time, on average
plus/minus ten seconds per year, in relationship to absolute GMT. (The
crux of the patents that have given SDI a monopoly on TS in token
authentication have to do with the devices Ken Weiss designed to keep the
ACE/Server or host clock effectively synchronized with the clock chip in
each SecurID registered in its database.) It is this use of Time in a TS
system which allows a SecurID to be used so easily and naturally by a user:
a long password read at a glance off the token. And it is that ease-of-use
which has so often allowed the SecurID to smoke the (C/R) competition.
On Saturday, in his fourth bombing run on TS, Padgett finally
doubled back to put some structure and substance to his plaint.
>Thanks to yet another person asking what I meant by "Time Synchronous
>is a dead end", I finally realized what has been bothering me for
>years about the TS vs. C/R issues was really described a few years ago by
>Willy the Barber.
>
>In a nutshell, Challenge Response depends only on two things - a token
>>with a key/seed and an algorithm, and a host with the same. The user may
>>enter a PIN along with the challenge to release them but the basic
>>dependency is on these two items only.
>
>Time Synchronous introduces two additional elements - the clocks at each
>>end.Being known elements, they add nothing to the security but introduce
>uncertainty into the equation, uncertainty that necessitates the use of
>windows of acceptability, windows that allow not one specific password
>but a range of them and requires a "synchronization factor" to be built
>into the software (host) end.
Some nutshell! Some nuts!
Saturday's "bottom line," concluded Padgett -- after mentioning
again the alleged difficulties in using TS tech in crypto key distribution
and software pseudo-token OTPs -- is that "the simplest system that does
the job is the right approach, and that IMNSHO is C/R."
The interesting question here is: Who gets the simplicity?
The TS SecurIDs -- just because they use the Time notation that
Padgett writes off as inconsequential or counterproductive to security --
are the overwhelming favorite among users just because they are so easy.
So simple. A typical fully-authenticated SecurID signon involves nothing
more than a user typing his SecurID "passcode" (sequentially, a memorized
PIN and the displayed card-code) like a traditional password. Period.
By contrast, a C/R logon involves: an initial contact with the
host; waiting for a random-number "challenge;" tapping a PIN into the
keypad of a C/R calculator to activate it; then tapping the challenge into
the token; then taking the result, the "response" (the token's secret-key
encryption of the challenge,) and typing that at the keyboard in the
second-stage of the C/R cycle. (I understand at least one C/R token
vendors now offers a package which requires a second PIN, to be transmitted
directly to the host -- so C/R authentication at the host will be granted
or withheld on the basis of two factors. Some folks value two-factor
authentication in the classical mode: "something held" plus "something
known.")
This lack of simplicity -- from the users POV -- has led hundreds
of firms which initially installed C/R authentication to switch to SDI's
SecurID. (A common rationale for the switch is that employees will be
more willing to use the system or the network, or to logon regularly from
remote sites, if management is willing to simplify the process by dumping
C/R and importing SecurIDs.)
The SecurID's use of a Time notation -- a token-specific secret key
and Time are the two inputs to the one-way function that generates a
pseudo-random SecurID card-code -- is what allows a TS system to define a
brief "window" in which a SecurID's PRN card-code is valid. It the use of
this window which allows SecurIDs to avoid the interactive two-cycle
exchange required of users of conventional C/R tokens.
Just because there is a (virtual) time-stamp factored into the
SecurID card-code, Time acts as a constraint on the current viability of
the authentication query. A SecurID card-code is generated and accepted
within a time-delimited box: 30 or 60 seconds. To get the same constraint,
the same guarantee that the user is THERE -- holding his token NOW -- C/R
tokens have to rely on the user's active reply (the token-calculated
"response") to a spontaneous and random "challenge" from the host.
IMHO, Padgett's lookin' for simplicity in all the wrong places.
Suerte,
_Vin
Vin McLellan +The Privacy Guild+ <vin @
shore .
net>
53 Nichols St., Chelsea, Ma., USA Tel: (617) 884-5548
<*><*><*><*><*><*><*><*><*>
|
|
