Vin McLellan wrote:
> 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.
This is not necessarily so -- challenge/response need not be
implemented like that. You could have a c/r token which was
interfaced directly to the client software (e.g. a PCMCIA-card
with appropriate drivers, and a token-aware stack, perhaps
implementing SSL or similar). The user's interaction with
such a scheme could actually be _simpler_ than with a TS
token like SecurID--insert your card (maybe enter a PIN), that's
it. Admittedly, it doesn't work with dumb terminals and suchlike,
but I hope you don't see us all transcribing numeric strings in
the 21st century.
Your point is certainly valid if you're comparing _some_ existing
C/R HHAs to SecurID, though. I will admit that my first reactions
on seeing a SecurID token, were "that's neat", closely followed by
"what if the time gets out of synch?", and "what about replay
within the skew period?", and such questions. You've answered
the first question at length--but what's the mechanism for
handling replay? Does it just cache responses within the skew
period? Also, since there is no challenge, surely there is a
race condition on the last digits of the response? How is that
handled? Note that C/R systems (even the primitive ones you
describe) can issue per-session challenges, and thus avoid
this condition.
Also note that C/R includes schemes such as public key
based handshakes, which have the nice side effect of
establishing a session-specific secret which can be used to
encrypt or seal the session thus providing _continuous_
authentication. Distributing session keys in a TS system is
no doubt possible (not by transcribing user-friendly strings,
though)--but the C/R schemes can potentially scale up much
better (possibly globally), requiring no online authentication
server (i.e. no authentication bottleneck in the morning, after
lunch, or after a system crash). You can also scale up by
adding application servers, whereas with a TS system, scaling
up would presumably entail replicating the authentication
server--possible, but good? And what about interdomain
working? With C/R, given a public key infrastructure (admittedly
this is a long time coming), inter-domain authentication may
come free, along with away-from home working, plus perhaps
the ability to sign documents or other data for use outside or
across sessions Perhaps these things can be done in a TS
system, but it is not obvious how, or why one would want to.
Cheers,
Frank O'Dwyer.
|
|
