Maybe It's Snake Oil All the Way Down

[Anne & Lynn Wheeler]

At 03:04 PM 6/3/2003 -0700, James A. Donald wrote:

>I never figured out how to use a certificate to authenticate a
>client to a web server, how to make a web form available to one
>client and not another.  Where do I start?
>
>What I and everyone else does is use a shared secret, a
>password stored on the server, whereby the otherwise anonymous
>client gets authenticated, then gets an ephemeral cookie
>identifying him..   I cannot seem to find any how-tos or
>examples for anything better, whether for IIS or apache.
>
>As a result we each have a large number of shared secret
>passwords, whereby we each log into a large number of
>webservers.  Was this what the people who created this protocol
>intended?

The issue is where does the authentication material come from.
<blatant aads promotion>
Basically, certificates were solution targeted for offline email from
the early '80s. you dail-up, connect, exchange email, hang-up. then
you read. some random person that you never, ever dealt with before
sends you something. they claim to be somebody .... the certificate
is signed by somebody you trust .... is offered as proof that they are
who they claimed to be.

the other approach in the online world &/or with previous relations,
is have a table of authentication material. the payment (debit/credit) card
world went from non-electronic, offline to electronic and online (and
skipped the step altogether that certificates represent ... the electornic
and offline).

note that even the certificate-based infrastructure are dependent on
this method .... basically the certificate-enabled infrastructures have
local table of "CA" public keys (i.e. those public keys that they've previously
decided to trust) ... then certificates are validated with "CA" public keys
and the current message/document is validate with public key from
certificate. The primary difference between cert-based infrastructure and
certless-based infrastructure is that the cert-based infrastructure there
CAs have the database of all public keys and create these small R/O
copies of their database records called certificates and spray them all
over for use in offline environments. Then relying parties just have
abbreviated CA-only public key tables and can't access the full tables
maintained at the CAs.

In the certless-based infrastructure the relying parties either maintain
their own full tables of all public keys and/or have direct online access to
the full tables. There is no need for these little R/O, static, stale,
redundant and superfluous copies of somebody else offline database entry 
(called
certificates) since there can be direct, online access to the original copy.

generalized case can be hooking the web server to either radius or
kerberos for handling the authentication process. both radius and
kerberos support shared-secrets recorded in database as authentication.
the radius example at
http://www.asuretee.com/
shows example of radius recording public key in lieu of shared-secret
and performing ecdsa digital signature authentication. pkinit for
kerberos also allows for public key recorded in lieu of shared-secret
and digital signature authentication.

misc. radius public key authentication posts
http://www.garlic.com/subpubkey.html#radius
misc. kerberos public key authentication pots
http://www.garlic.com/subpubkey.html#kerberos
futher discussion specifically regarding static, stale, redundant,
superfluous certificates.
http://www.garlic.com/~lynn/subpubkey.html#rpo


slightly related discussions regarding SSL merchant comfort
certificates:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

</blatant aads promotion>
--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
  


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com