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

[Anne & Lynn Wheeler]

Stephan Neuhaus wrote:
> That's because PSKs (as I have understood them) have storage and
> management issues that CA certificates don't have, four of which are
> that there will be a lot more PSKs than CA certificates, that you can't
> preinstall them in browsers, that the issue of how to exchange PSKs
> securely in the first place is left as an exercise for the reader (good
> luck!), and that there is a revocation problem.
> 
> To resolve any of those issues, code will need to be written, both on
> the client side and on the server side (except for the secure exchange
> of PSKs, which is IMHO unresolvable without changes to the business
> workflow).  The client side code is manageable, because the code will be
> used by many people so that it may be worthwhile to spend the effort.
> But the server side?  There are many more server applications than there
> are different Web browsers, and each one would have to be changed.  At
> the very least, they'd need an administrative interface to enter and
> delete PSKs.  That means that supporting PSKs is going to cost the
> businesses money (both to change their code and to change their
> workflow), money that they'd rather not spend on something that they
> probably perceive as the customer's (i.e., not their) problem, namely
> phishing.
> 
> Some German banks put warnings on their web pages that they'll never ask
> you for private information such as passwords.  SaarLB
> (http://www.saarlb.de) even urges you to check the certificate
> fingerprint and provides well-written instructions on how to do that. In
> return, they'll assume no responsibility if someone phishes your PIN and
> TANs. They might, out of goodwill, reimburse you.  Then again, they
> might not.  I believe that SaarLB could win in court.  So where is the
> incentive for SaarLB to spend the money for PSK support?

an alternative view of the server side is to recognize that the two most
widest used authentication infrastructures are radius and kerberos
http://www.garlic.com/~lynn/subpubkey.html#radius
http://www.garlic.com/~lynn/subpubkey.html#kerberos

furthermore both radius and kerberos not only have facilities for
abstracting authentication function ... but also abstracting
authorization functions.

one of the short-comings of PKIs, CAs, and digital certificates was the
issue of encorporating authorization information along with the
authentication information into a single paradigm ... for one thing
digital certificates tended to be publicly available .. and
authorization information frequently tends to be sensitive.

frequently then the issue is that attempting to replace existing
authentication infrastructures with PKIs, CAs, and digital certificates
still leaves the rest of the infrastructure for authorization in place.
It is then frequently trivial to demonstrate that the stale, static
digital certificates are redundant and superfluous ... and it is more
efficient and less expensive to have an integrated authentication and
authorization environment by simply registering public keys in lieu of
passwords in an existing integrated authentication/authorizatin environment.

for example ... the original pk-init draft for kerberos specified
registering public keys in lieu of passwords ... giving a integrated
authentication/authorizatin environment using digital signature
verification in place of passwords for authentication. later PKI, CAs,
and digital certificate operation was added to the pk-init draft.

Another aspect was that in the early 90s ... certification authorities
were started to wonder just what set of information would really be
useful for unknown and undefined relying parties ... as a result there
was some direction to start grossly overloading x.509 identity
certificates with huge amounts of personal information.

It was in the mid-90s that some institutions were starting to realize
that x.509 identity certificates, grossly overloading with huge amounts
of personal information represented significant privacy and liability
issues. As a result you started to see the apperance of
relying-party-only certificates (in fact, it may have been a german bank
that started producing the first relying-party-only certificates)
http://www.garlic.com/~lynn/subpubkey.html#rpo

A relying-party-only certificate basically contains some sort of
database lookup value (like userid, account number, etc) where the real
information is kept and a public key. However it is trivial to
demonstrate that a relying-party-only certificate is redundant and
superfluous when the real information has to be directly accessed ... by
demonstrating that the body of the signed message/transaction can also
include the same database index value ... and the real information will
be where the registered public key is recorded. That makes the public
key in the digital certificate redundant and superfluous. Simple
scenarios like transactions have to include the identifier ... and in
certificate-based scenarios ... the identifier in the transaction needs
to match the identifier in the certificate (or otherwise you could have
somebody with a valid account doing transactions against any account at
the same bank). With the identifier in the body of the
message/transaction and the registered public key in the account record,
the relying-party-only digital certificate becomes redundant and
superfluous.

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