Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
I asked the guy making the presentation about the similarity to Kerberos message flows and he said something to the effect of ah yes, kerberos. Not sure what the guy meant by that. But yes, SAML flows are just like Kerberos flows. And Liberty and WS-Federation look a lot like DCE cross-cell (er, Kerberos inter-realm) flows. After all, there's only not many ways to do secure online trusted third-party authentication. /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
On Mon, 2003-12-29 at 10:16, Rich Salz wrote: Not sure what the guy meant by that. But yes, SAML flows are just like Kerberos flows. And Liberty and WS-Federation look a lot like DCE cross-cell (er, Kerberos inter-realm) flows. After all, there's only not many ways to do secure online trusted third-party authentication. /r$ talking to the guy after the presentation, i got the impression that they probably exactly copied the kerberos flows ... didn't even try to come up with something that turned out to be similar. there were 30-40 people in the audience and I expected more people in the audience to have participated in discussion about kerberos vis-a-vis saml. kerberos had come out of project athena that had been substantially jointly funded by two corporations ... project athena had a director from mit and two assistant directors, one from each of the funding corporations. one of them i had worked with for a long time when at science center at 545 tech sq. (random refs): http://www.garlic.com/~lynn/subtopic.html#545tech during the period we were doing hsdt ha/cmp ... my wife and I also got to go by and do audits of progress of various project athena activities (including kerberos). One visit we had a lengthy overview and discussion of the recently (then) developed cross-domain protocol. -- Anne Lynn Wheeler - http://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
At 02:01 PM 12/23/2003 -0500, Rich Salz wrote: How many years have you been saying this, now? :) How do those modern online environments achieve end-to-end content integrity and privacy? My guess is that they don't; their use of private value-add networks made it unnecessary. If my guess is/was correct, than as more valuable transactions (or regulated data) flow over the commodity Internet, then those things will become important. Make sense? Am I right? in days before the internet it was there was a lot more lo-tech attacks on financial transactions ... and when things like the credit card master file got harvested it was uaually pretty obviously an insider job. with the advent of the internet ... not only was it a open, insecure, commodity network but a lot of the attached systems were never designed to operate in effectively a hostile environment because of a lot of contributing factors there was significant ambiguity when a merchant master file got harvested ... where the attack originated (insider or outsider). minor side thread regarding security proportional to risk with regard to attacks on the merchant master file: http://www.garlic.com/~lynn/2001h.html#61 during the past ten years there have been some number of technologies for attempting to compensate for just the transport of the shared-secret account number in a transaction on an open, hostile network aka primarily ssl, minor reference with regard to emerging ssl and the original payment gateway: http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 there has been a lot of threads about how much fraud SSL actually prevented since the major consumer retail financial related fraud ... both non-internet, pre-internet, and internet has been bulk harvesting of repositories like a merchant master transaction file (for possibly the same effort to evesdrop packets in flight and extract a single account number it might be possible to harvest a merchant transaction file with tens of thousands of account numbers. so the x9a10 working group was given the requirement for preserving the integrity of the financial infrastructure for all electronic retail transactions. To meet that, the x9.59 standard was defined which basically requires end-to-end authenticated transactions between the consumer and the consumer's financial infrastructure and that account numbers used in authenticated transactions can't be used in non-authenticated transactions. With strong, end-to-end authentication, it is possible to evesdrop a x9.59 transaction, extract the account number and still not be able to execute a fraudulent financial transaction. It is also possible to harvest x9.59 account numbers from merchant transaction files and still not be able to execute fraudulent financial transaction. Hiding account numbers has been associated with identity theft, since in environment where the transactions aren't authenticated the account numbers have to be effectively treated as shared-secrets. The downside is that numerous business processes all along the processing chain require access and use of the account number. Just hiding the account number with SSL did little to address the major vulnerabilities and threats. In effect, the analysis shows that it is effectively impossible to provide necessarily protection for a shared-secret account number, nobody of how deep the earth was blanketed with cryptographic technology. The solution was to change the business process, require end-to-end strong authentication and eliminate the account number as a shared-secret (i.e. knowing the account number is not sufficient for performing a fraudulent transaction). misc. x9.59 standard refs: http://www.garlic.com/~lynn/index.html#x959 There was actually a couple other issues differentiating internet-based transactions and the VPN environment. The VPN environment was circuit based, it is possible to get service level agreements and utilized technology like modem loop-back diagnostics as part of a bootstrap problem determination procedure. Such an environment has a trouble desk and expects to finish first level problem determination in something like 5 minutes. One of the last projects my wife and I had done before taking the early out (and doing some consulting for the payment gateway and ec-commerce stuff) was the HA/CMP product i.e. high availability/cluster multi-processing. http://www.garlic.com/~lynn/subtopic.html#hacmp There is a slight reference in one of the above aadsm5.htm archive posting to http://www.garlic.com/~lynn/95.html#13 because some of the people in the above meeting had left and joined a client/server startup and were responsible for this thing called a commerce server who we then working with on this thing called a payment server for this thing that would be called e-commerce. In any case, packet-based internet not only
Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
At 02:29 PM 12/25/2003 +1300, Peter Gutmann wrote: X.509 certs were designed to solve the problem of authenticating users to the global X.500 directory. So they're good at what they were designed for (solving a problem that doesn't exist [0]), and bad at everything else (solving any other sort of problem). disclaimer: I never actually worked on either X.500 or X.509 standards ... however, I do remember an acm sigmod meeting circa '90 where somebody did characterize x.500 as a bunch of networking engineers trying to re-invent 1960s database technology. minor past refs: http://www.garlic.com/~lynn/2002g.html#24 Why did OSI fail compared with TCP-IP? http://www.garlic.com/~lynn/2002g.html#28 Why did OSI fail compared with TCP-IP? http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP also, (not knowing about original intent of x.509) ... the PKI infrastructures I saw in the early to mid 90s ... had x.509 identity certificates that appeared to be populated with stale, static (and possibly subset) of information from a database entry targeted for use by relying parties in lieu of the relying parties actually being able to contact the real database (contained some piece of a x.500 directory entry that a relying-party could presumably use if they didn't have direct access to the x.500 directory). the relying-party-only certificates of mid ot late 90s appeared to be much more of something that would authenticated an entity to a operational service having thrown out nearly all of the information that might be found in a database (especially anything that might possibly represent a privacy and/or liability issue) . However, relying-party-only certificates could still be shown to be redundant and superfluous ... aka if i'm sending a digitally signed transaction containing an account number (or other database indexing value) to a relying party having the database then appending any kind of certificate that contains a small subset of the complete information from the database entry (including any public key or authentication material) is redundant and superfluous. the IETF OCSP standards work seems to be all about a real-time protocol that a relying party can use to check with a (LDAP?) database about whether the information that might be in a specific certificate can still be relied on. It has some of the flavor of a distributed filesystem/database cache entry invalidation protocol All of the CRL and OCSP stuff isn't about using the certificate for authenticating to an x.500 directory but whether the stale, static copy of information in the certificate is still good. one of the PKI related efforts from the mid-90s specified adding a digital signature and a relying-party-only certificate to a iso8583 oriented financial transaction. It turns out that the typical iso8583 financial transaction eventually gets packaged as something like 60-80 bytes while the typically implemented relying-party-only certificate for this effort was between 4k bytes and 12k bytes. In this case, not only was the relying-party-only certificate redundant and superfluous but also represented a two orders of magnitude payload bloat. -- Anne Lynn Wheelerhttp://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 [EMAIL PROTECTED]
Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
At 02:01 PM 12/23/2003 -0500, Rich Salz wrote: If so, then I believe that we need a federated identity and management infrastructure. The difference is that the third-party PKI enrollment model still doesn't make sense, and organizations will take over their own identity issues, as with SAML and Liberty. Once you do that, adding publicKey as just another attribute is no big deal. With any luck, the new year will bring the analogy SOAP::other middleware as SAML::x.509 :) the one detailed presentation that I've so far seen of a SAML based product looked like it had exactly the same message flows description that I sat thru in a Kerberos project audit in the '80s. I asked the guy making the presentation about the similarity to Kerberos message flows and he said something to the effect of ah yes, kerberos. random kerberos refs: http://www.garlic.com/~lynn/subpubkey.html#kerberos -- Anne Lynn Wheelerhttp://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 [EMAIL PROTECTED]
Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
2) certificates were fundamentally designed to address a trust issue in offline environments where a modicum of static, stale data was better than nothing How many years have you been saying this, now? :) How do those modern online environments achieve end-to-end content integrity and privacy? My guess is that they don't; their use of private value-add networks made it unnecessary. If my guess is/was correct, than as more valuable transactions (or regulated data) flow over the commodity Internet, then those things will become important. Make sense? Am I right? If so, then I believe that we need a federated identity and management infrastructure. The difference is that the third-party PKI enrollment model still doesn't make sense, and organizations will take over their own identity issues, as with SAML and Liberty. Once you do that, adding publicKey as just another attribute is no big deal. With any luck, the new year will bring the analogy SOAP::other middleware as SAML::x.509 :) /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
Ian Grigg [EMAIL PROTECTED] 12/20/2003 12:15:51 PM One of the (many) reasons that PKI failed is that businesses simply don't outsource trust. Of course they do. Examples: DB and other credit reporting agencies. SEC for fair reporting of financial results. International Banking Letters of Credit when no shared root of trust exists. Errors and Ommissions Professional Liability insurance for consultants you don't know. Workman's Compensation insurance for independent contractors you don't know. The point is that the real world has monitized risk. But the crytpo-elite have concentrated too hard on eliminating environmental factors from proofs of correctness of algorithms, protocols, and most importantly, business processes. Crypto is not business-critical. It's the processes its supposed to be protecting that are, and those are the ones that are insured. Legal and regulatory frameworks define how and where liability can be assigned, and that allows insurance companies to factor in stop-loss estimates for their exposure. Without that, everything is a crap shoot. Watching how regulation is evolving right now, we may not see explicit liability assignments to software vendors for their vulnerabilities, whether for operating systems or for S/MIME email clients. Those are all far too limited in what they could offer, anyway. What's happening, instead, is that consumers of those products are themselves facing regulatory pressure to assure their customers and regulators that they're providing adequate systematic security through technology as well as business policies, procedures and (ultimately) controls (ie, auditable tests for control failures and adequacy). When customers can no longer say gee, we collected all this information, and who knew our web server wouldn't keep it from being published on the NYTimes classified pages?, then vendors will be compelled to deliver pieces of the solution that allow THE CUSTOMER (product consumer) to secure their environments. Get ready. Trusted Third Party evaluations, like FIPS 140 is for Crypto, will be the thing insurance companies look to for guidance in factoring their risk exposure when asked to provide warranty coverage to businesses using technology - just like they did to Underwriters Laboratories for electrical appliances, just like they do to DB for commercial credit processing, just like they do to MasterCard and VISA for consumer credit processing. And before you say well, that doesn't apply to internal company security, ask yourself how many companies outsource physical security to Brinks or some other security-guard employeement agency. They can do that, too, because of other insurance (personal bonds) that help them lay off the exposure to misplaced trust. Trust is heavily outsourced. Only the very large or very foolish think they can go it alone. And the very large generally have governments in their pockets to help provide the stop-loss limits for their exposure. No? Ed - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
At 07:34 PM 12/22/2003 -0700, Ed Reed wrote: Of course they do. Examples: DB and other credit reporting agencies. SEC for fair reporting of financial results. International Banking Letters of Credit when no shared root of trust exists. Errors and Ommissions Professional Liability insurance for consultants you don't know. Workman's Compensation insurance for independent contractors you don't know. I don't think that trust checking was so much of the question a not uncommon scenario was 1) institution set up an account possibly that included checking with 3rd party trust agencies 2) did various kinds of online transactions where the actual transaction included account-only information 3) got an offer from a certification authority to move into the modern world a) send the CA a copy of the institutions account database b) the ca would convert the information in each account record into a certificate c) each certificate would be digitally signed by the CA d) the CA would returned each digitally signed transformed account record back to the institution and only charge a $100/certificate 4) the institution was to convert from modern online transactions to archaic offline transactions based on information in the certificate 5) the certificate would be a x.509 identity certificate that contain all of the account entity's identification information which would flow around attached to every transaction fundamentally 1) x.509 certificates broadcast all over the world attacked to every transaction were in serious violation of all sorts of privacy issues 2) certificates were fundamentally designed to address a trust issue in offline environments where a modicum of static, stale data was better than nothing 3) offline, certificate oriented static stale processing was a major step backward compared to online, timely, dynamic processing. 4) the traditional outsourced trust has the relying-party contracted with the trust agency so that there is some form of legal obligation, the traditional CA model has no such legal obligation existing between the relying-party and the trust/certifying agency (the contract is frequently between the trust agency and the key owner, not the relying-party). In the mid to late 90s ... some financial institutions attempted to salvage some of the paradigm (because of the severe privacy and liability issues) by going to relying-party-only, certificates for online transactions. However, it is trivial to show that the static, stale information in the relying-party-only certificate was a trivial subset of the information that would be accessed in the real account record for the online transactions ... and therefor it was trivial to show that static, stale certificates were redundant and superfulous. misc. past posts regarding relying-party-only scenario: http://www.garlic.com/~lynn/subpubkey.html#rpo I think that the current federal gov.PKI tries to address the legal obligation issue ... by creating a legal situation where essentially all the authorized CA operators are effectively agents of the federal PKI ... and all the relying parties have contracts with the federal PKI ... which simulates a legal obligation between the issuer of the certificate and the relying-parties. In something like the DB scenario ... the relying party contracts for some information with DB about the entity that the relying party is interested in. In many of the traditional 3rd party CA-PKIs, there may be absolutely no legal relationship between the CA issuing the certificate (trust information) and any of the relying parties that are relying on the trust information i.e. the contract is between the CA issuing the certificate ... and the entity that the certificate is about. Since the entity (that the trust information is about) may be the party paying for the trust information ... they may have some motivation to shop around and get the most favorable report. Lets say I was applying for a loan and the loan institution needed a credit report. Rather than the loan institution contracting for the credit report, they rely on one supplied by the loan applicate. The loan applicant is free to choose from all the credit reporting agencies which credit report that they will buy for supplying to the loan institution. random past threads on trust propagation: http://www.garlic.com/~lynn/aadsm14.htm#42 An attack on paypal http://www.garlic.com/~lynn/aadsm14.htm#45 Keyservers and Spam http://www.garlic.com/~lynn/aadsm14.htm#46 An attack on paypal http://www.garlic.com/~lynn/aadsm15.htm#26 SSL, client certs, and MITM (was WYTM?) http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB http://www.garlic.com/~lynn/2001g.html#40
