Alan Altmark wrote: > RSA SecurID is normally integrated into the network access controls. That > is, authentication and host access authorization decisions are made at the > [VPN] network boundary (a la firewall), not on each host.
there is something of a trust disconnect with the SSL/TLS model that has some things in common with the current password model. a couple recent posts that had topic drift on authentication technology http://www.garlic.com/~lynn/2005t.html#27 RSA SecureID product http://www.garlic.com/~lynn/2005t.html#28 RSA SecureID product http://www.garlic.com/~lynn/2005t.html#32 RSA SecureID product original password model had some "something you know" static data recorded and the person needed to reproduce this static data for authentication. as the need for authentication proliferated, the importance of some of the authentication uses increased and the number of different authentications increased. because it was static data, there was a requirement for unique password for every different security boundary/domain. for the important uses, there was requirements for impossible to guess/remember passwords that changed frequently ... and people were saddled with scores of impossible to guess/remember passwords. the proliferation of password use became the basis for fundamental password vulernability (in addition to other vulnerability characteristics of passwords). misc. collected postings on shared-secret authentication (& their vulnerabilities) http://www.garlic.com/~lynn/subpubkey.html#secrets long ago and far away, we were asked to consult with this small client/server startup that wanted to do payment transactions on their server(s) http://www.garlic.com/~lynn/aadsm2.htm#asrn2 http://www.garlic.com/~lynn/aadsm2.htm#asrn3 and as noted in the above ... some topic drift relationship http://www.garlic.com/~lynn/95.html#13 to our work on producing ha/cmp product http://www.garlic.com/~lynn/subtopic.html#hacmp which has some small relationship to having done some work on the original relational/sql dbms http://www.garlic.com/~lynn/subtopic.html#systemr in any case, the startup had this new technology that they called SSL that could be leveraged to secure the payment transaction information (again, shared-secret static data ... that effectively is used for authentication of the payment transaction). as part of the work we went around and audited some of these brand new organizations called certification authorities http://www.garlic.com/~lynn/subtopic.html#sslcert the issue is that the ssl digital certificate binds a public key to a domain name for a URL that the user/client types in. the server provides the digital certificate, the client software checks the validiity of the digital certificate, and then checks that the digital certificate domain name matches the domain name URL typed in. the client then generates a random (symmetrical) encryption key, encrypts it with the public key from the certificate and sends it back to the server. the client and server now only communicate using an encrypted channel. there is an implied "something you have" authentication of the server, since only the server should have access to and use of the corresponding private key (and therefor able to decrypt and use the client's randomly generated symmetric encryption key). the issue analogous to the proliferation of passwords ... is that the use of URLs have so widely proliferated that they happen at every blink and twitch and users rarely type them in any more (or even pay any attention to the domain name in URLs). ssl operation vulnerabilities now include attackers having valid ssl domain name certificates that correspond to supplied URL domain name ... which users rerely, if ever pay any attention to or even look at. in part, because URLs have become so ingrained as part of every WWW twitch and blink ... they are incorporated into the substance of the operation. Users see a word like "bank" that may be clicked on ... and a URL is automatically transmitted that the user never typed or even looked at (and can have perfectly valid SSL authenticatin ... which now can carry with it almost no real security meaning). the situation has put the trusted-third certification authorities in somewhat of a bind. the basic digital signature model has the client validating public keys before loading them into their local repository. In the PGP email case, senders digitally sign their email and can provide a public key. the recipients go thru some validation process before loading any supplied public key into their local trusted public key repository. the PGP email digital signature process takes the displayed email "FROM" address to find a public key in the client's trusted public key repository for validating the email's digital signature. there now is a completely understandable, and direct relationship between the "FROM" (sender), the digital signature, and the client's validation of the supplied public key. The SSL TTP digital certificate model has obfuscated this original model through several layers of indirection that can result in it almost being meaningless. First off, the client's trusted public key repository used for validating the digital signatures on the "messages" produced by certification authorities (aka digital certificates) have typically been preloaded by the application vendor. most users probably aren't even aware that the foundation of ALL digital signature infrastructures are based on local client trusted public key respository ... whether they involve digital certirficates or are certificateless http://www.garlic.com/~lynn/subpubkey.html#certless next, the process by which public keys are validated as part of loading into the client's trusted public key repository is frequently obfuscated (especially compared to the PGP process). the use of URLs occuring at ever twitch and blink ... that the user is frequently unaware of the actual URL ... pretty throughly obfuscates the domain names in the URLs. therefor any security that comes from matching the domain name in the URLs and the domain name in SSL digital certificates is significantly depreciated. in part this led to the series of past postings about "comfort certificates" included in some of the earlier postings on ssl certificate. http://www.garlic.com/~lynn/subpubkey.html#sslcert so, the digital certificate model is also somewhat of an electronic analog to identification credentials (aka the theme that any requirement for the attachment of identification digital certificates to every operation turns even the most trivial authentication event into heavy duty identification operation). the user needs to validate the identification credentials before trusted the party they are dealing with. however, the use of the SSL digital certificates with URL domain names, and the prolificate ingraining of URLs into the very fabric of web infrastructures has resulted in the process becoming authomatic ... and as a result, depreciating much of its original security meaning. by contrast, in the PGP model, the public key is directly associated with the email "FROM", which is always displayed (as opposed to the domain name in a URL, which users rarely, if ever see or pay any attention to). Furthermore, the user performs some sort of validation once, as part of adding the public key to their local, client trusted public key repository. From then on, the users can be assured of that binding between the visiable FROM, the digital signature validation, and the loaded public key (which can be done automatically from then on). PGP systems also support various levels of integrity checking associated with loaded public keys. However, there retains a very simple and observable trust chain between the email "FROM", the email digital signature, the loaded public key, and the process involved in loading that public key. That trust chain isn't throughly obfuscated as has happened with the SSL domain name certificate imfrastructure that it looses almost all security significance. this creates something of a dilemma for the SSL domain name certification authority industry. Any change that results in the user being more involved in verifying the binding of a public key with some entity ... would appear to depreciate the value of the certification authority usefulness and their digital certificates ... aka some PGP analogous mechanism where some value that is known to be user visiable (on a web page) is used for looking up a public key locally stored public key ... which is then used for authentication process. so there are a number of increased security operations being developed ... which involve operations around things known to be displayed on the web page for the user. however, they've tended to avoid chaning the user's perception of digital signatures, public keys and the requirement for digital certificates issued by certification authorities. so a trivial scenario marrying PGP model and SSL is for the user to click on some static data on a web page (logo, image, text, etc) that then looks up a public key from a local client trusted public key repository. then the rest of the SSL operation is performed with the server based on that public key (rather than a public key opbtained from some supplied digital certificate ... and the URL might even be taken from the entry associated with the public key ... instead of from the web page). so there are some administrative functions that are needed to make it easy and simple for users to maintain their local public key responsitory (analogous to the PGP implementation). part of the issue is not to make those events so frequent that they require so much automation that the security issues are throughly obfuscated and become meaningless ... as has essentially happened for much of the SSL domain name certificate use. for some slight drift, one of the most prevalent use of ssl domain name infrastructure is the securing of electronic commerce and the vulnerable static data associated with online, electronic payment transactions. so one of the requirements given the x9a10 standards working group for x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payments. part of the issue has been that the transaction static data isn't just vulnerabile to capture while in transit, but also when it is at rest in large repositories of transaction information ... related post on security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 so x9.59 standard defines http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#x959 1) all x9.59 transactions are authenticated. this can be with digital signatures which are validated with (certificateless) public keys registered and stored in the account record at the individual's financial infrastructure. 2) static data in x9.59 transactions can't be used in non-authenticated, non-x9.59 transactions. the second part eliminates much of the existing fraud that comes from either transaction evesdropping and/or data breaches of transaction repositories. with the elimination of transaction fraud from the capture of transaction static data, there is a much reduced security requirement for protecting such information (with encryption and/or other security means, which, in turn, reduces much of the existing need for ssl domain name certificate infrastructures) ... various. posts related to account number harvesting:treats & vulnerabilities http://www.garlic.com/~lynn/subpubkey.html#harvest of course, there are all the past postings about another ssl domain name certificate catch-22 ... that leads down another path to certificateless use and obsoleting the necessity for ssl domain name certificates: http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability http://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto? http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form) http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM? http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?) http://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming http://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug? http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love http://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame http://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ? http://www.garlic.com/~lynn/2001l.html#22 Web of Trust http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me http://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks http://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification http://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure? http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack http://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack http://www.garlic.com/~lynn/2003d.html#29 SSL questions http://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption in a system to system interface http://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application http://www.garlic.com/~lynn/2004b.html#41 SSL certificates http://www.garlic.com/~lynn/2004g.html#6 Adding Certificates http://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2005.html#35 Do I need a certificat? http://www.garlic.com/~lynn/2005e.html#22 PKI: the end http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix http://www.garlic.com/~lynn/2005e.html#51 TLS-certificates and interoperability-issues sendmail/Exchange/postfix http://www.garlic.com/~lynn/2005g.html#0 What is a Certificate? http://www.garlic.com/~lynn/2005g.html#1 What is a Certificate? http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate? http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used http://www.garlic.com/~lynn/2005i.html#3 General PKI Question http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet http://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand http://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
