Another entry in the internet security hall of shame....

Anne & Lynn Wheeler lynn at garlic.com
Thu Sep 1 16:28:21 EDT 2005


Alaric Dailey wrote:
> If I may inject my humble opinion(that isn't necessarily a response to
> this peticular email), I may not be as informed as some but....
> 
> While I admit that PKI is flawed, I don't see anyway that PSK could used
> effectively.
> 
> How are PSKs going to be shared in a secure way?
> are we talking about generating a new key for every connection?
>     if so how do you validate the key?
>     if not, how do you validate that the key hasn't been compromised by
> someone who put up a phishing site?

on the business/server side ... where x.509 identity certificates
represent horrible privacy and liability issues ... and they've migrated
to relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

by definition, the institution needs to have already registered the
clients public key ... in order to even issue a relying-party-only
certificate ... they client/customers "public key" has been preshared
(otherwise it would have been impossible for the institution to have
issued the certifivate).

at this point it is trivial to demonstrate that the issuing of the
relying-party-only certificate is redundant and superfluous ... since by
definition the institution has the PSK.

so if you look at existing business process where "pre-shared" passwords
are part of an authentication administration infrastructure that is
integrated with the permissions and authorization administrative
infrastructure ... say like either radius or kerberos
http://www.garlic.com/~lynn/subpubkey.html#radius
http://www.garlic.com/~lynn/subpubkey.html#kerberos

it is possible to register public keys in place of password, retaining
the existing business process and integrated administration of
authentication and authorization.

one of the issues when we started dealing with this small client/server
startup that wanted to do payments on their server platform
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

had this new thing called SSL which were dependent on PKI, certification
authorities, and digital certificates. As part of that effort, we had to
 do various kinds of business process and end-to-end audits of these
things called certification authorities. There was a lot of discussion
in these audits about certification authorities having very little to do
with security and technology ... and primarily involved in a traditional
service operation with loads of administrative work.

One of the characteristics of businesses that have existing relationship
management administrative relationship management operations ... like
financial institutions with accounts or business with accounts payable
and accounts billable or ISPs ... is that they have tried to provide
some amount of administrative scaleup and integrity to the operation.

Frequently it is possible to show a trivial toy PKI demo as an add-on
w/o impacting the core authentication and authorization business
processes. The big expenses quickly dawns on them when it starts to
appear that PKI operation might have some impact on real business
operations. At that point of time, it becomes quickly apparent that any
full-scale PKI authentication infrastructure deployment will have an
enormous cost duplication (especially after there has been possibly
scores of years developing scaleable and integrated authentication and
authorization infrastructures).

At that point, the ongoing duplicate PKI operational costs totally
dominate ... any trivial software technology deployment issue. Part of
the issue is that the promise of having x.509 identity certificates
groslly overloaded with enormous amounts of privacy information along
with authorization and permissions ... has been shown to be false. That
the organization isn't able to use the deployment of a X.509 PKI
operation (with the digital certificates containing enormous amounts or
privacy and senstive information) to eliminate their existing integrated
relationship management and administrative infrastructure costs ... it
possible turns out to be possibly doubling the actual business costs (in
any sort of full-scale production deployment used for actual business
purposes.). It may actually be worse than doubling ... the basic PKI
administrative infrastructure may be replicated ... doubling the costs
... however the actual costs may be tripled if the existing production
business operation and the replicated PKI administrative operation then
has to be kept in sync.

>From a business/server standpoint ... upgrading an existing integrated
authentication/authorization/permission infrastructure to use digital
signature authentication with public key registration ... conforms to
existing business practices and doesn't introduce duplicate and
unnecessary administrative operation.

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



More information about the cryptography mailing list