[4653] in WWW Security List Archive
Re: SecureID alternatives?
daemon@ATHENA.MIT.EDU (Vin McLellan)
Tue Mar 4 17:56:17 1997
In-Reply-To: <331853C6.516F@vasco.com>
Date: Mon, 3 Mar 1997 14:25:29 -0500
To: jch@vasco.com (Haggard, John C.)
From: Vin McLellan <vin@shore.net>
Cc: www-security <www-security@ns2.rutgers.edu>, tel1dvw@is.ups.com,
aisecur!KClancy@bpd.treas.gov
Errors-To: owner-www-security@ns2.rutgers.edu
Dave Wreski <tel1dvw@is.ups.com> queried the List:
> Hi all. I had heard once of something called 'callback'. Could you tell
> me (first of all if this message belongs here) if I can dial a modem, and
> have it call me back, and my machine answer?
Kim Clancy <aisecur!KClancy@bpd.treas.gov> and others cautioned:
>> When call forwarding became available, it kinda defeated the
>>security of a
>> callback modem.
Then, the estimable John Haggard <jch@vasco.com> suggested Caller
ID (ANI), as used in Vasco's VacMan, as an alternative mode of user
authentication:
>>>VASCO's VACMan, and when Security Dynamics completes their
>>>>>>AccessManager module for their ACE server, support the ability to
>>>register >>>user's home phone numbers and if your Communications Server
>>>has a caller >>>id capability, and your phone company does as well, you
>>>can control access
>>>to your corporate network.
The problem with using CID or ANI as an authentication technology
is that you might be Betting the Company on the integrity and security of
the phone company's switches. AT&T wouldn't do that! (With good reason, as
the antics of Mitnick and sundry phone phreaks have shown.)
Trusting an oblivious third party to provide your core security
technology would seem to be a generically bad idea, unless the resource you
are protecting is virtually without value.
With regard to SDTI's rumored "access manager," Vasco's competitive
intelligence group may have scored a coup -- but I've been a consultant to
SDTI for many years, and I'd be very very surprised if SDTI were to abandon
two-factor authentication for ANI authentication. ANI is, I grant, the
modern version of call-back (a third-party declaration of where the phone
is) but it is _not_ a user authentication tech... and SDTI has always
prided itself on its committment to strong user authentication.
Web mavens routinely get snowed on user authentication. (Whatdaya
expect when "hits" are touted as meaningful numbers;-) In public-key crypto
infrastructure, you've been the pioneers. Thus far, however, the procedure
for a CA to bind a user's identity to a PKI certificiate seems to be
painfully loose. When a CA gains the ability to certify the binding of a
person and a cert with the legal and procedural certainty that, say, the US
Passport Office offers -- then we'll have something. But what will we
have, even then?
The ability to encrypt or decrypt is sure evidence of possession of
the crypto device and the relevant key -- but (despite what you read at
Netscape and/or Alternative sites) possession of a particular cert or
crypto device is not a particularly meaningful form of user authentication
either! A CA-issued certificate merely certifies that a computer
(actually, only a file within a computer) was once assigned to an
individual by the name of John Doe -- who may or may not be the user; and
who may or may not be the current owner of the cpu holding the cert.
>This of course does little for your truely mobil remote users, but that
>is what tokens are for.
Right. Over in the OS systems world, where they've worried about
user authentication for 50 years, the "three factors of user
authentication" are a little mantra:
- something "you know" (a user-memorized password or PIN,)
- something "you are" (a fingerprint or biometric of some sort,)
and
- something "you hold" (a physical token, a personal identifier
given to you by an authorized party able to identify you by other means.)
Vasco's Internet AK II offers two-factor (token and PIN)
authentication in the classic role of the hand-held authentication (HHA)
token: at the gateway, validating user IDs before allowing access to a
protected Netscape server (with a neat little Java applet that drops a
token-readable bar code on the user's screen.)
SDTI used their web app (WebID on NT) for a more grandular control.
With IIS, this means an ISAPI filter which demands a two-factor SecurID
authentication before allowing a user access to any protected object: a
directory, page, or portion of a page. After authenticating the user, the
WebID (which is part of the NT ACE/Client, on the web server) passes a
timed cookie to the user's browser, which gives him continuous
authentication to other protected items on that server (subject to his NT
permissions) until the cookie times out.
Anyone know about DAA??? I'm intrigued by rfc 2069, which offers
Digest Access Authenticaton (DAA) to replace HTTP 1's basic authentication
-- particularly it's optional second digest (which would offer a continuous
authentication, protecting against session hijacking and guaranteeing the
integrity of a downloaded html page.)
DAA's primary goal is to replace HTTP's UU cleartext transmission
of username/passwords with an MD5 cipher, which contains both a challenge
nonce (to be offered by the web server,) and the user's authentication
data. NCSA, Spyglass, and Apache actively support DAA, but no word yet as
to when Microsoft or Netscape might -- although they helped draft the rfc.
The beauty of a token, of course, is that it jumps the air gap and
transfers the physical and logical piece of the user-authentication process
from the user's PC or workstation -- where a program can be doing all sorts
of ill-defined things; and having all sorts of things done to it -- to the
mobile isolation of a personal ID card, tucked into the user's pocket or
purse... with the functionality simple, limited, and obvious.
In the next generation of hand-held authenticators (HHAs) -- and,
to mark the trend, both Vasco and SDTI have developed smart-card "cert
holders" as a token alternative -- even two-factor authentication will
suffer some diminution of trust... just because a plugged-in smart card
lacks some of that apparent and obvious simplicity.
Suerte,
_Vin
Vin McLellan + The Privacy Guild + <vin@shore.net>
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
