Two-factor Authentication Options?

[Anne & Lynn Wheeler]

hotz at jpl.nasa.gov ("Henry B. Hotz") writes:

> In the long run the Kerberos password is a problem because the human
> brain does not obey Moore's law.  As I see it the solution is to use
> some form of two-factor authentication for the initial ticket exchange.
>
> So what options are there in that space?
>
> AFAIK none --- with the standard open source servers.  There are
> patches available for MIT to support CRYPTOcard and SecureID.  There
> are patches available for Heimdal to support X509 certificates
> (PKINIT).
>
> Anything else out there?

original pkinit specification for kerberos had certificateless public
keys (aka w/o certificates) .... certificate option was added later.

certificateless public keys ... basically registers public keys in
lieu of passwords .... and does digital signature authentication using
the registered public keys from the online registry.

the nominal problem with shared-secret passwords is that you need a
unique shared-secret for every unique security domain. when a person
was only involved in one security domain authentication scenario, it
wasn't too bad .... but as the number of different security domains
grew, people were finding that they needed scores of unique passwords.

the simple public key scenario is you encapsulate the private key in a
token, register the (single) public key in lieu of password, and use
the token for performing a digital signature. the registered public
key is used to authenticate the digital signature. 

the requirement for needing a unique password for every unique
security domain was based on just learning the password (in one
domain) was sufficient for impersonation in a different security
domain (i.e. an ISP garage-operation password shouldn't be the same as
your online banking password). public key doesn't suffer from this
vulnerability since knowing somebody's public key isn't sufficient for
impersonation.

the hardware token, by itself provides one-factor, "something you
have" authentication .... from three-factor authentication

* something you have
* something you know
* something you are

in theory, a single "digital signature" hardware token could be used
across a multitude of different security domains .... since knowing
the aaosicated public key isn't sufficient to impersonate.

it is also possible to have certified hardware tokens that only work
in the approved manner when the appropriate pin has been supplied. The
result can be two-factor authentication .... aka

* something you have
* something you know

w/o the PIN being a shared-secret ... and therefor not subject to
requiring an unique value for every security domain. This is done by
providing the "secret" (NOT shared-secret) PIN to the hardware token.
The security domain doesn't need to know the person PIN ... they just
need to have certified that the hardware token only works in the
approved manner when the correct PIN has been entered. Then based on
having certified the hardware token (to require correct pin for
operation), then authentication of the digital signature implies
two-factor authentication: 

* person has the hardware token 
* person entered the correct pin.

it is also to get hardware tokens which require something like a
fingerprint to work correctly (in lieu of a PIN) ... in which case
it is still two-factor authentication ... but

* person has the hardware token
* person has the correct fingerprint

X.509 identity certificates were somewhat the rage in the early 90s
....  however, it was discovered that they represented a whole bunch
of privacy and liability issues. Some number of x.509 certificates were
used in a truncated manner in the mid-90s ... which effectively only
contained an account number and a public key ... and were referred to
as relying-party-only certificates:
http://www.garlic.com/~lynn/subpubkey.html#rpo

however, it was possible to show that such certificates were redundant
and superfluous for normal online environments:

1) key owner registers their public key with online infrastructure
2) online infrastructure stores the public key in database
3) online infrastructure sends a RPO-certificate back to the key owner
4) key owner authenticates something by doing a digital signature
5) key onwer sends the digital signature and certificate back to the
   online infrastructure
6) online infrastructure pulls public key from online database
7) online infrastructure verifies digital signature with online
   public key

the certificate contains a stale, static subset of the online information.

certificates were originally designed to provide some level of
assurance in an offline environment where the relying party had no
recourse to the real online registered information.

when the relying party has access to the real, online, timely
registered information ... then the stale, static certificate subset
is redundant and superfluous.

a side-note about the "something you have" hardware token; there is
some tendancy that every unique security domain wants to issue its own
"certified" hardware token. this has some human factor issues in much
the same way that trying to manage scores, possibly a hundred
different passwords breaks down in practical application. A person is
as likely going to manage an hundred unique, different hardware tokens
as they are going to manage an hundred unique, different passwords.

a pending issue is how could a person get away with one or possibly
extremely few different, unique hardware tokens .... and avoid getting
into the same proliferation bind that they have with passwords.


misc. other postings on the subject:
http://www.garlic.com/~lynn/aadsm17.htm#0 Difference between TCPA-Hardware and a smart card (was:   example: secure computing kernel needed)<
http://www.garlic.com/~lynn/aadsm17.htm#1 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#2 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#4 Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#7 Phillips, Visa push contactless payments in consumer devices
http://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm17.htm#15 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#16 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#19 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#21 Identity (was PKI International Consortium)
http://www.garlic.com/~lynn/aadsm17.htm#22 secret hackers to aid war on internet fraud
http://www.garlic.com/~lynn/aadsm17.htm#23 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#26 privacy, authentication, identification, authorization
http://www.garlic.com/~lynn/aadsm17.htm#27 Re:Identity Firewall. l PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#34 The future of security
http://www.garlic.com/~lynn/aadsm17.htm#36 Yahoo releases internet standard draft for using DNS as public key server
http://www.garlic.com/~lynn/aadsm17.htm#38 Study: ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm17.htm#39 The future of security
http://www.garlic.com/~lynn/aadsm17.htm#40 The future of security
http://www.garlic.com/~lynn/aadsm17.htm#41 Yahoo releases internet standard draft for using DNS as public key server
http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
http://www.garlic.com/~lynn/aadsm17.htm#46 authentication and authorization (was: Question on the state of the security industry)
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
http://www.garlic.com/~lynn/aadsm17.htm#50 authentication and authorization (was: Question on the state of the security industry)
http://www.garlic.com/~lynn/aadsm17.htm#51 authentication and authorization
http://www.garlic.com/~lynn/aadsm17.htm#53 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/