Misc AADS & X9.59 Discussions

AADS Postings and Posting Index,
next, previous - home

when a fraud is a sale, Re: Rubber hose attack
[Fwd: Re: when a fraud is a sale, Re: Rubber hose attack]
Software for PKI
Software for PKI
Software for PKI
Software for PKI
Software for PKI
Software for PKI
Software for PKI
Software for PKI
Software for PKI
Software for PKI
Software for PKI
Software for PKI
Software for PKI
DNSSEC (RE: Software for PKI)
DNSSEC RFCs, was Software for PKI
3D Secure Vulnerabilities?
DNSSEC (RE: Software for PKI)
DNSSEC (RE: Software for PKI)
DNSSEC (RE: Software for PKI)
3D Secure Vulnerabilities?
DNSSEC (RE: Software for PKI)
DNSSEC (RE: Software for PKI)
3D Secure Vulnerabilities?

when a fraud is a sale, Re: Rubber hose attack

Refed: **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/05/2001 03:23 PM
To: JohnE37179@xxxxxxxx
cc: cryptography@xxxxxxxx, egerck@xxxxxxxx, Jason.Gruber@xxxxxxxx,
rick_smith@xxxxxxxx, vertigo@xxxxxxxx
Subject: Re: when a fraud is a sale, Re: Rubber hose attack

there is actually several kinds of fraud ....

1) there is huge amount of financial "theft" in things like credit card transactions ... because they are mostly unauthenticated transactions ... or using simple magstripe (something you have) authentication that is becoming easier to counterfeit. Strong authentication & authorization (w/o any sense of identity) can prevent these sort of things.

2) there are some number of account set ups where somebody uses a false identity to establish an account, runs up the bilss, and skips (since false identity doesn't bear any relationship to any real person, it isn't identity theft, it is false identity). This becomes a deterance & recovery scenerio.

3) there are significantly smaller number of identity theft fraud where somebody takes out a credit card in your name and runs up the bills which get sent to you. If something was done to address #2 with regard to deterance & recovery ... i.e. bank being able to accurately track who it was that opened the account and skipped (with false identity) then it would also address #3, identity theft.

However, for account setups where i deposit the money and I'm not borrowing money from the bank ... but just using my own money .... then it reduces back to simple prevention, authentication, and authorization. If I happen to skip after spending only half of my money .... I'm sure that the financial institution &/or possibly some government would be more than happy to take ownership.

JohnE37179@xxxxxxxx at 11/05/2001 1:30 PM wrote
Of course, mother's maiden name is not safe. It is simply another poor PIN. You are missing the entire point about identification. You are bypassing the issue completely.

No one at First Data, Equifax, TU, Experian, Acxiom, etc., or any major bank could identify me. That door is wide open for anyone wishing to be me, or you for that matter.

The reason there is so much identity fraud is that it is so easy. Anyone can be anyone in today's environment. The door is wide open.

John

[Fwd: Re: when a fraud is a sale, Re: Rubber hose attack]

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/07/2001 11:12 AM
To: Alanslater@xxxxxxxx
cc: egerck@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: [Fwd: Re: when a fraud is a sale, Re: Rubber hose attack]

related subject/thread ... ran other ng .... security proportional to risk
https://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe? ... security proportional to risk
https://www.garlic.com/~lynn/aepay7.htm#netsecure some recent threads on netbanking & e-commerce security
https://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#3dsecure3 financial payment standards ... finger slip

one of the issues in the above is the different approaches ... 1) is to leave the infrastructure with large numbers of serious points of compromise and then try to force them all into secure, hardened buckers or 2) change the situation where the large numbers have the serious compromise eliminated.

note that while outsider fraud frequently gets the most play in the press .... however lots of studies claim that insider fraud has always been the majority of fraud (80 percent or more) ... misc. related to insider fraud:
https://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?

somewhat related
https://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
https://www.garlic.com/~lynn/aadsm6.htm#terror4 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
https://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards? (addenda)
https://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
https://www.garlic.com/~lynn/2001.html#47 What is wrong with the Bell-LaPadula model? Orange Book
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#67 Would this type of credit card help online shopper to feel more secure?
https://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
https://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2001k.html#55 I-net banking security
https://www.garlic.com/~lynn/2001l.html#2 Why is UNIX semi-immune to viral infection?

alanslater@xxxxxxxx at 11/07/2001 9:27 am wrote:
Ed --

You've now defined a boundary between different levels of security or trust. Therefore, one should conclude that anything below that threshold represents an "acceptable risk." If this were not true, then one would have to impose a lower threshold to achieve higher security. The "acceptable risk" category is only eliminated when the threshold is zero. Hence only one security level should be used (I'm not advocating this, it's absurd).

With that said, is "acceptable risk" eliminated? Unfortunately, it's not. Since any level of security used defines a class of attacks to which it is vulnerable, the choice of any method also defines the "acceptable risk" associated with it. Use of a more powerful method of security merely reduces the size of the "acceptable risk" but does not eliminate it.

I guess that this is a somewhat long-winded way of saying that "acceptable risk" is a fact of life and it is not a "... euphemism for that business model that shifts the burden of fraud to the customer. " Especially, since there are few, if any, issuers in the debit or credit card world that are imposing any liability on customers for unauthorized transactions.

Cheers,

Alan

Software for PKI

From: Lynn Wheeler
Date: 11/07/2001 04:06 PM
To: "Galipeau, Jenny" <jgalipeau@xxxxxxxx>
cc: "'Harrington, Chris'" <harringtonc@xxxxxxxx>, ietf-pkix@xxxxxxxx,
    "'Rich Salz'" <rsalz@xxxxxxxx>
Subject: RE: Software for PKI

For 99.9999999 of the certificate associated events in the world today .... aka with SSL domain name certificates .... they aren't really a PKI ... it is manufactured certificates. Furthermore, the users are told that SSL is there to keep people from evesdropping on the credit card number ... which is a key-exchange protocol issue. There is some noise about certificate being used to make sure you are really dealing with the web-site that you think that you are dealing with ... but I believe for the majority of the end-users that is just noise ... the majority already believe that they are dealing with the web-site that they are dealing with. From that stand-point the certificate part of SSL domain name certificates is pretty much extraneous protocol noise.

Furthermore, the perported purpose of the SSL domain name certificates (aside from the SSL key exchange stuff) is because of worries about the integrity of the domain name infrastructure. However, if somebody goes to get a SSL domain name certificate from a TTP ... the TTP has to validate the request with the authoritative agency for domain names (aka the domain name infrastructure). To a large extent domain name infrastructure integrity issues ... that exist can impact not only standard domain-name lookup ... but also validation requests from TTPs. So a proposal to improve the domain name infrastructure for the purposes of TTPs validating information for manufacturing SSL domain name certificates ... turns out would go a long way to improve the integrity of the domain name infrastructure for everybody's use (which in turn, nagates the justification for having SSL domain name certificates in the first place).

random ref:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

jgalipeau@xxxxxxxx on 11/07/2001 11:09 AM wrote:
I agree. Why do you think SSL implementations and IPsec/VPN implementation are widely in use. TRANSPARENT to the end-user!

Software for PKI

Refed: **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/07/2001 08:21 PM
To: EKR <ekr@xxxxxxxx>
cc: ekr@xxxxxxxx, "'Harrington, Chris'" <harringtonc@xxxxxxxx>,
    ietf-pkix@xxxxxxxx, "Galipeau, Jenny" <jgalipeau@xxxxxxxx>,
"'Rich Salz'" <rsalz@xxxxxxxx>
Subject: Re: Software for PKI

The scenerio proposed for improving the integrity of the domain name infrastructure for CAs is to have person registering his domain name, also register his public key along with his domain name in the domain name registery. One of the insecurities of the domain name system .... happens to be domain name hijacking ... somebody impersonating the domain name owner (with domain name hijack) getting a certificate issued to him for that domain name (somewhat the same way that somebody got Verisign to issue them a microsoft certificate). They now have a certificate from verisign for that domain name. So registering the public key is the solution to domain name infrastructure integrity so that the CAs can have better confidence (including verisign) that they are truely dealing with the person that registered the domain name.

Ok, however, if there is a public key registered with the domain name infrastructure (as part of improving the integrity of the domain name infrastructure on behalf of the TTP CAs) .... then the domain name infrastructure could include the public key as part of the domain name record.

Now the original purpose of certificates were the offline world .... the early 80s where somebody called up, downloaded their email and hung up. Now that they are no longer online ... they can not directly contact the authoritative agency for the information directly and so needed a substitute. Now these things called certificates effectively contained a copy of the information kept by the authoritative agency ... these certificates were manufactured at some time in the past and the information by now could be quite stale. However, given the design point for certificates of an offline world, with no authoritative information at all; then a stale certificate was slightly better than now information at all.

Now the interesting part is that if the domain name infrastructure registers the public key for the domain name owner .... and I was interested in timely information .... which would i prefer 1) some piece of stale data manufactured at some time way in the past that is the copy of the information at the authoritative agency (based on the original design point of a totally offline world) or 2) the near real-time information directly from the authoritative agency in an online world (especially considering that the certificate is effectively only a stale copy of that information from the authoritative agency design to address a problem of the offline world and unable to contact the authoritative agency directly).

Now the interesting thing for SSL .... is if the TTP CAs fix the domain name integrity issue for their own purpose with the registering of the public key .... the existing domain name infrastructure can serve up the real-time version of that registered information (public key) in the same transaction that the ip-address is served up. Given a choice of an old stale, static copy of the authoritative agency information .... getting the currect up-to-date information seems a whole lot more interesting (and also as a side-point was actually designed for an online world rather than the certificate copy design point for the offline world). The other interesting part is that the SSL setup hand shaking chatter gets drastically simplified .... all the client does is get the authoritative copy of the public key at the same time it gets the domain name lookup. Huge amounts of SSL setup chatter & noise goes away.

Now have an implementation that was actually designed for an online world .... not the certificate stale copies that were designed for the offline world; also since it is real-time, online ... there is no more of this horrendously complex stuff about PKIs .... not more worry about things like CRLs. These are the exact analogies to the credit-card paper booklets that addressed the offline credit card credential world of the first half of the last century .... every month send out a paper-booklet to everybody of the revoked credit card numbers. The problem was the same issue that PKI is attempting to address .... credentials issued at some time in the past for the offline world ...... and how to try and manage the updating of stale information for an offline world.

Of course, in the 2nd half of the last century ... it appeared that the world started going online ... and a large part of the target market for certificates, CRLs, PKIs, is now having a harder time finding a niche. If I'm dealing with totally inconsequencial information of no value ... that I probably am not as concerned about whether or not I may be dealing with offline year-old stale copy of some information as opposed to a online transaction directly with the authoritative agency for the information to get the current, non-stale version.

random refs and more detail:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

Eric Rescorla at 11/07/2001 5:03 PM wrote
Of course, it's possible that some CAs (even Verisign, perhaps) gets the information from DNS but those CAs have insecure policies. Discovering that they did so wouldn't invalidate the purpose of SSL certificates any more than it would be invalidated by discovering that Verisign left it's private key lying around. You'd just want to stop trusting said CA.

-Ekr

--
[Eric Rescorla ekr@xxxxxxxx]
http://www.rtfm.com/

Software for PKI

Refed: **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/08/2001 07:50 AM
To: EKR <ekr@xxxxxxxx>
cc: ekr@xxxxxxxx, "'Harrington, Chris'" <harringtonc@xxxxxxxx>,
ietf-pkix@xxxxxxxx, "Galipeau, Jenny" <jgalipeau@xxxxxxxx>,
"'Rich Salz'" <rsalz@xxxxxxxx>
Subject: Re: Software for PKI

A "master-database" for the domain name infrastructure is a common integrity problem for both DNS and TTPs ... since that is where all the information about domain name registration resides (both TTPs and DNS are dependant on it). In effect that is the basis of the authoritative agency that TTPs have to use to validate requests for SSL certificates. Until that problem is fixed for domain name infrastructure .... then it continues to be a compromise for the TTPs that wish to validate requests for SSL domain name certificates (since that is where they validate the request). Going to public key registration along with domains ... is in fact almost identical to the RA (registration authority) phase of a TTP. Even TTPs are putting the keys someplace. Then going to signed transactions eliminates many of the things like social engineering. However, the primary point is that if that isn't fixed .... then it is an exposure to not only all of the domain name infrastructure ... but also all the TTP CAs that have to check with the domain name infrastructure as to the validity of a SSL domain name certificate request.

If you want to talk about chain of trust ... then the root for SSL domain name certificates start with those databases ... since they are the authoritative databases for validating a SSL domain name certificate request. In effect a CA ... certification authority ... is "certifying" some piece of information as part of manufacturing a certificate. A CA's certifying domain name information for a SSL domain name certificate request consists of checking/validating with the authoritative agency responsible for the information that is being certified. If that authoritative agency has integrity issues, then the validating/checking has intetrity issues, then the certification has integrity issues .... and we aren't even to the point of actually manufacturing the certificate.

The database(s) have to be armored and the procedures fixed .... and at least one of the proposals (on behalf of TTP trusted operation, if nothing else) is to institute public key registration and public key signed transactions to help address the integrity issue (which has to be fixed for the TTP CAs ... if nobody else). Note that since the signed transactions go directly to the authoritative agency that has registered the keys .... the associated signed transactions don't require that certificates be appended to such transactions .... since the authoritative agency already has the public keys and all the information contained in any such certificate (making the appending of certificates to such transactions, redundant, superfluous, and unnecessary).

Adding keys and distributing them within the domain name infrastructure, in effect, is already supported (mechanically), since DNS already supports that for arbritrary information.

The remaining issue is the real live operation. The current certificate world isn't a real PKI ... it is simply certificate manufacturing. It doesn't actual provide infrastructure management of distributed information (something that DNS already supports). The issue then is how hard is it to add incremental integrity to all (or at least some) DNS transactions. That is compared against adding all the stuff to the current certificate infrastructure for a real-live PKI ..... say for instance, things like guaranteed delivery and receipt of CRL to every entity on the face of the earth that might be faced with relying on a certificate. For instance, my understanding that after the Verisign issuing the Microsoft certificate, Microsoft is distributing software updates to all clients in the world that has special code specific for recognizing the invalid certificates.

ekr@xxxxxxxx at 11/7/2001 9:34 pm wrote:
The security of the database is fundamentally a non-technical problem and I don't believe that putting public keys in the DB will help. It will always be possible for someone to socially engineer the DB maintainers into contaminating the database. The defense against that (to the extent there is one) is good administrative policies.

-Ekr

Software for PKI

Refed: **, - **, - **

From: Lynn Wheeler
Date: 11/08/2001 08:05 AM
To: "Ramsay, Ron" <Ron.Ramsay@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: RE: Software for PKI

The issue is that the domain name infrastructure provides the domain name mapping to ip-address ... and that infrastructure is built to some level of trust. Since it is already being trusted to provide that level of information, it may be possible (if the trust level was sufficient) for the domain name infrastructure to also distribute other associated information associated with the information ... like public keys. The infrastructure supposedly isn't built on random entities with unknown trust levels providing arbitrary information. The point is that the trusted agency for providing domain-name mapping isn't random individuals .... it is the domain name infrastructure.

On the other side, PGP does, in fact, have individuals serving up their own public keys ... and the relying party is given the opportunity to execute (possibly out-of-band) operation for corroborating.

In effect, that is also what happens as the RA/registration authority portion of any TTP CA operation. Somebody serves up their own public key and some other piece of information .... and then it is up to the CA/certification authority to invoke some certification process prior to activating that information/public key (which in the TTP CA case is manufacturing a certificate ... representing the provided information as well as the validation/certification process).

The interesting characteristic about registering a public key at the same time as registering the domain name .... is that puts the level of trust for the public key at the same level of trust as accepting the registration of the domain name i.e. to whatever extent there is trust in the whole domain name registration and whatever trust attached to that domain name, the public key trust is at the same level ... because it was part of the same registration process. Trust in a domain name may include an arbritrary number of previous transactions, word-of-mouth, etc. The other part is that while the whole certificate architecture has an offline-world design point ... the domain name infrastructure was designed for online, near real-time opreation (and so the whole issue of things like CRLs ... the invalid credit card number paper booklets .... from the first half of the previous century, goes away).

Ron.Ramsay@xxxxxxxx on 11/7/2001 9:49 PM wrote
But if I can either give you my IP address, or persuade you that my domain name is the one you need, why do I find it so hard to also give you my public key?

Software for PKI

From: Lynn Wheeler
Date: 11/08/2001 08:20 AM
To: Rich Salz <rsalz@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: Software for PKI

therre is a web site that the rfc-editor points at:

https://www.garlic.com/~lynn/rfcietff.htm

some amount of that information also used to be included in STD1 ... and the process used to generate the information on the web site also is used to cross-check the information in STD1, including, but not limited to the information that used to be carried in section 6.10 of STD1

https://www.garlic.com/~lynn/rfcietf.htm#obsol

however, I apoligize for not having a DNSSEC acronym (but it is possibly a good addition) but go to

https://www.garlic.com/~lynn/rfcietff.htm

and slect Term (term->RFC#)

and then from the keyword screen, select "DNS" ... will get you a list of all DNS (including DNSSEC) related RFCs. The first one on the list (as of this moment) is 3130. Clicking on 3130 serves up

3130 Notes from the State-Of-The-Technology: DNSSEC, Lewis E., 2001/06/18 (10pp) (.txt=22291) (was draft-lewis-state-of-dnssec-02.txt)

clicking on 3130 will get you to all the terms that 3130 is categorized under (domain name system & security). clicking on the "txt" field will retrieve the actual field.

rsatz@xxxxxxxx on 11/8/2001 8:05 AM wrote:
Do you know about DNSSEC, it's support in BIND, etc? /r$

Software for PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/08/2001 09:15 AM
To: EKR <ekr@xxxxxxxx>
cc: ekr@xxxxxxxx, "'Harrington, Chris'" <harringtonc@xxxxxxxx>, ietf-pkix@xxxxxxxx,
"Galipeau, Jenny" <jgalipeau@xxxxxxxx>, "'Rich Salz'" <rsalz@xxxxxxxx>
Subject: Re: Software for PKI

There seems to be a lot of focus on "trust" once a certificate has been manufactured .... and possibly "trust hierachies" of certification authorities, and CRLs and other stuff for the offline world design point. However the "official" word in CA is certification (not certificate), i.e. in general TTPs certify/validate something prior to certificate manufacturing. However, it is hard to make the trust level of the information in a certificate at a higher level than the trust level in the authoritative agency responsible for the information being certified/validated. If the authoritative agency has integrity issues .... then those trust issues propagate thru-out the whole trust chain (regardless of any obfuscating with fancy mathematics that might go on).

following refs including postings in the n.g. on this subject a couple years ago:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

the claim ... as before ... in the domain name infrastructure there have been issues raised regarding integrity ... with SSL domain name certificates as a solution. However, SSL domain name certificates derive their (real) trust root from the same place the domain name infrastructure derives its trust root (since that is the authoritative agency that is responsible for the validity of the information and which TTPs have to validate/certify with as to the correctness of the information they are certifying prior to manufacturing the certificate).

The claim is that any "fixing" necessary of that trust root that goes on because of the issues that TTP CAs may have .... also goes a long way to eliminating the need for having those same TTP CAs issue SSL domain name certificates ... aka catch-22 ... the fix for SSL domain name certificates also goes a long way to eliminating the need for SSL domain name certificates.

lynn.wheeler@xxxxxxxx wrote
If you want to talk about chain of trust ... then the root for SSL domain name certificates start with those databases ... since they are the authoritative databases for validating a SSL domain name certificate request. In effect a CA ... certification authority ... is "certifying" some piece of information as part of manufacturing a certificate. A CA's certifying domain name information for a SSL domain name certificate request consists of checking/validating with the authoritative agency responsible for the information that is being certified. If that authoritative agency has integrity issues, then the validating/checking has intetrity issues, then the certification has integrity issues .... and we aren't even to the point of actually manufacturing the certificate.

Software for PKI

From: Lynn Wheeler
Date: 11/08/2001 09:20 AM
To: Mitchell Arnone <marnone@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, owner-ietf-pkix@xxxxxxxx
Subject: RE: Software for PKI

The database(s) have to be armored and the procedures fixed .... and at least one of the proposals (on behalf of TTP trusted operation, if nothing else) is to institute public key registration and public key signed transactions to help address the integrity issue (which has to be fixed for the TTP CAs ... if nobody else). Note that since the signed transactions go directly to the authoritative agency that has registered the keys .... the associated signed transactions don't require that certificates be appended to such transactions .... since the authoritative agency already has the public keys and all the information contained in any such certificate (making the appending of certificates to such transactions, redundant, superfluous, and unnecessary).

Adding keys and distributing them within the domain name infrastructure, in effect, is already supported (mechanically), since DNS already supports that for arbritrary information.

The remaining issue is the real live operation. The current certificate world isn't a real PKI ... it is simply certificate manufacturing. It doesn't actual provide infrastructure management of distributed information (something that DNS already supports). The issue then is how hard is it to add incremental integrity to all (or at least some) DNS transactions. That is compared against adding all the stuff to the current certificate infrastructure for a real-live PKI ..... say for instance, things like guaranteed delivery and receipt of CRL to every entity on the face of the earth that might be faced with relying on a certificate. For instance, my understanding that after the Verisign issuing the Microsoft certificate, Microsoft is distributing software updates to all clients in the world that has special code specific for recognizing the invalid certificates.

ekr@xxxxxxxx at 11/7/2001 9:34 pm wrote
The security of the database is fundamentally a non-technical problem and I don't believe that putting public keys in the DB will help. It will always be possible for someone to socially engineer the DB maintainers into contaminating the database. The defense against that (to the extent there is one) is good administrative policies.

-Ekr

Software for PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/08/2001 09:37 AM
To: Mitchell Arnone <marnone@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, owner-ietf-pkix@xxxxxxxx
Subject: RE: Software for PKI

One of the problems is that there is significant trade-off between identity schemes and privacy issues. It is possible to authenticate that something is authorized w/o leaking identity information and therefor improving privacy.

There has been some talk about EU making electronic financial point-of-sale transactions as anonymous as cash, aka remove name & other identity information from debit/credit cards .... both the plastic and the magstripe. A problem is that the traditional X.509 "identity" certificates typically represent a horrendous and totally unnecessary leakage of privacy information.

Some number of EU financial institutions have attempted to address the horrendous privacy & totally unnecessary identity leakage with X.509 identity by going to relying-party-only certificates .... basically a certificate signed by the financial institution and essentially containing only an account number and a public key.

As an aside, for financial transactions ... it is trivially possible to show that for relying-party-only certificates it is possible to

1) optimize the size of the certificate to zero bytes since the relying-party that is receiving a transaction with the appended certificate already has a superset of the information contained in the certificate; including the public key

2) eliminate the appending of the certificate to the transaction as superfluous, redundant, and unnecessary since the relying-party already has the original of the certificate (aka the relying-party manufactured the original certificate, stored it in the account record, and returned a copy of the certificate to the client).

Very few electronic transactions are about identity, they are about authentication and authorization. If a bank gets an ATM transaction from me .... they don't really care to know who I am ... they want to know if I'm the authorized party to perform transactions on the specific account. Throwing in identity into such a scheme just results in all sorts of privacy exposures and unnecessary identity leakage.

For a guard at a gate to know my name is pretty superfluous .... the guard just needs to know if I'm authorized to pass the gate. They may check my face against a badge authorizing me to pass .... not because they want to know who i am ... they want to know does the authorization badge really belong to me.

misc. discussions about biometrics and 3-factor authentication:
https://www.garlic.com/~lynn/aadsm2.htm#privacy Identification and Privacy are not Antinomies
https://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
https://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech12 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose14 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose15 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo1 QC Bio-info leak?
https://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
https://www.garlic.com/~lynn/aadsmore.htm#biosigs2 biometrics and electronic signatures
https://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
https://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
https://www.garlic.com/~lynn/aepay3.htm#x959risk3 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
https://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/99.html#157 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#160 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#165 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#166 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#168 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#170 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#189 Internet Credit Card Security
https://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
https://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2000.html#60 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2000f.html#1 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#7 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall?
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001g.html#1 distributed authentication
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
https://www.garlic.com/~lynn/2001k.html#61 I-net banking security

mamone@xxxxxxxx on 11/8/2001 5:51 am wrote:
I am not sure I agree with the statement that no one really cares about identity. How can anyone "know what you are authorized to DO" if you are not confident that you are who you say you are. Only after proper identity has been established can proper permissions be assigned. PKI is all about identity management and it may be the most effective method of identity management on the market today.

these other significant benefits.

PKI and Identity management is a foundation service just like the network infrastructure and directories. You build a strong foundation and construct your application architecture in a manner to leverage the strength of the foundation.

Software for PKI

Refed: **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/08/2001 09:41 AM
To: Mitchell Arnone <marnone@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, owner-ietf-pkix@xxxxxxxx
Subject: RE: Software for PKI

Software for PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/08/2001 11:43 AM
To: EKR <ekr@xxxxxxxx>
cc: ekr@xxxxxxxx, ietf-pkix@xxxxxxxx,
Mitchell Arnone <marnone@xxxxxxxx>
Subject: Re: Software for PKI

the point was that there are integrity exposures with the current SSL domain name certificates .... because of its dependency on the domain name infrastructure. There are proposals to fix the problem by registering public keys in the domain name system.

The claim is that if public keys are in the domain name system as part of fixing the issue for TTP CAs ... then it is relatively trivial for the domain name infrastructure to start using those public keys ... including current domain name infrastructure facilities to "serve-up" those keys in online, real-time requests. The observations is that if the problem was fixed for the TTP CAs that the fix is also the seed for eliminating the need for the SSL domain name certificates.

Furthermore, the claim is that such an implementation (once the keys are being registered) is a much, much simpler (KISS) deployment for online, real-time information that what it would take to turn the current SSL domain name certificate manufacturing infrastructure into a real PKI (aka real-time serving of public keys is much better and simpler strategry with domain name infrastructure .... than trying to turn an offline-world design point certificates into a PKI).

ekr.rtfm.com at 11/8/2001 10:39 am wrote:
Yes, that's true. So? It's still better than nothing which is what we had before.

-Ekr

-- [Eric Rescorla ekr@xxxxxxxx]
http://www.rtfm.com/

Software for PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/08/2001 01:59 PM
To: Mitchell Arnone <marnone@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, owner-ietf-pkix@xxxxxxxx
Subject: RE: Software for PKI

let say it is a bank with bank employees. The bank may be required to run a FBI check on all employees associated with various kinds of financial responsibility. That is obviously a identification issue.

however,. for all the authentication and authorization operations that occur in a banks internal operation .... it is of absolutely no use to know a person's name for authentication and authorization.

in the point-of-sale & e-commerce scenerio it serves little purpose that a people's name & address have to be kept in some 20 million merchant web servers around the world. All that is necessary is for the merchant to know that a correct transaction occurs and the merchant gets their money.

In effect, authentication and authorization w/o identification is sufficient for correct operation. The problem that does crop up is large amounts of incorrect operation (i.e. insdier fraud is documented as being the largest type of fraud). For in-correct operation it is useful to have an audit trail so that it is possible to track back from an authentication & authorization event as part of financial forensics so that recovery and remediation processes can be put into effect. However, it is not necessary to have identity directly invovlved in the direct authentication & authorization process as part of correct operation. Part of it, isn't that the corporation might not have to determine at some point exactly who you are .... but that it is unnecessary to repeatedly propagate large amounts of identity on every transaction (for fraud, it is just sufficient that there is some way of tracking a frauduent activity back to an individual).

The unnecessary propagation of identity related information on transactions which only require authentication and authorization.

Basically I need to proove that some authentication & authorization belong to me ... I don't need to proove who i am (although there may be a way of correlating things that belong to me with who i am).

Following is discussion of picture card ... not for identification purposes ... but for authorization purposes. The ID didn't need name or anything else. The purpose of the picture was that somebody could check that the card being used actually belonged to the person using it.
https://www.garlic.com/~lynn/aadsm7.htm

and how authentication and authorization deals with correct operation and typically identification deals with recovery, remediation, and possibly deterance.

Now, some number of corporations (besides EU banks for customers) have gone to relying-party-only certificates .... basically no identification ... but only an account number .... let's say an employee number. The employee number has associated with it various authentication properties as well as authorization properties. Digital signature operations are one form of authentication in a relying-party type of environment. At the simplest having a "credential" from a specific employer and being able to demonstrate that it is your credential is sufficient for certain minimum authorizations/previleges. However, in the previous posting regarding EU banks it is possible to trivially show that it is unnecessary, redundant and superfluous to append a certificate to a digitally signed message that is going to the relying party (either by the zero byte compression rule or the relying party already has the original rule).

So as in the DNS case registering public keys provides an avenue for totally obsoleting the necessity for SSL domain name certificates .... what about employee/customer certificates. My previous claim that possibly 99.9999 percent of the exiting certificate related authentication events are SSL domain name certificates ... and it is fairly straight-forward to totally obsolete the necessity for such certificates. Also it is possible to show that is straight-forward to totally obsolete the relying-party-only certificates in the financial customer transaction case.

What about the employee/client/corporate case? I would also claim that 99.999 percent of the client-related authentication events that happen in the world today involve RADIUS. RADIUS currently involves shared-secret and/or challenge/response ... frequently observed when customers contact their ISP or employees dial into corporate networks. So, it is relatively straight-forward if a corporation was to register public keys in a database (i.e. the RA, registration authority, part of a certification authority, and also store the original of a manufactured certificate there), then the simplest deployment is to hook up a real-time, online RADIUS infrastructure to that database and also enable RADIUS for digital signature authentication. The message is signed, the message and digital signature are transmitted and RADIUS authenticates the digital signature with the real-time, online access to the RA-registered public key. It has the advantage of being currently deployed infrastructure for 99.999 percent of the internet, and is an online real-time design point. It doesn't have the short-comings of a PKI infrastructure designed for the offline, stale, out-of-date operation with manufactured certificates. Furthermore, any invention for adding online, real-time to a PKI ... can be done better by eliminating the certificate all together and directly using the real-time information.

misc. threads regarding use of public keys in existing RADIUS authentication and authorization infrastructures;
https://www.garlic.com/~lynn/subpubkey.html#radius

For a list of RADIUS RFCs: goto
https://www.garlic.com/~lynn/rfcietff.htm

and click on Term (term->RFC#) and then scroll down in the abbreviations to "RADIUS" and click on "RADIUS".

For a list of authentication related RFCs goto
https://www.garlic.com/~lynn/rfcietff.htm

and click on TERM (term->RFC#) and then scroll the frame down to the term "authentication". Also listed are RFCs from the "Authentication, Authorization and Accounting" work group, as well as terms related specifically to authorization. The authentication term also points "UP" to RFCs that are related to security in general.

You may also find of some interest the security taxonomy & glossary at:
https://www.garlic.com/~lynn/index.html#glossary

there is both the Security specific taxonomy/glossary as well as a X9F standards taxonomy/glossary

Security
Terms merged from: AFSEC, AJP, CC1, CC2, FCv1, FIPS140, IATF, IEEE610, ITSEC, Intel, JTC1/SC27/N734, KeyAll, MSC, NCSC/TG004, NIAP, RFC1983, RFC2504, RFC2828, TCSEC, TDI, TNI, and misc. Updated 20010729 with glossary from IATF V3.

X9F
Terms merged from X9F document glossaries: WD15782, X509, X9.8, X9.24, X9.31, X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69. Terms from ABA/ASC X9 TR1-1999 replace terms from X9F TG-16 glossary (identified by lower case x9 instead of upper-case X9). Original source documents include: X3.92, X3.106, x9.1, x9.5, x9.6, x9.8, x9.9, x9.17, x9.19, x9.23, x9.24, x9.26, x9.28, x9.30, x9.31, x9.41, x9.42, x9.44, x9.45, x9.49, x9.52, x9.55, x9.57, x9.62, x9.69 x9.74, x9.76, x9.78, x9.80, x9.82, and TG-17. (990710)

marnone@xxxxxxxx at 11/08/2001 10:35 AM wrote:
If I understand your point correctly, you are making reference to the usage of real human names in certificates. There is the question of where does privacy begin and where does it end. In a corporate office, do you have a right to keep your name private? Sure you can be as private as you want at home and in your personal transactions but I can't imagine a valid argument for the same level of paranoia in the work place. Privacy is a very important concern but even if you use some other form of unique identification that can not be correlated with obvious private human information, you are still dealing with identity management. Your name may not be included in that certificate but somehow and somewhere there must be some sort of non-reputable association between that certificate and a specific human. This is identity management!

Software for PKI

Refed: **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/08/2001 05:19 PM
To: "Ramsay, Ron" <Ron.Ramsay@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: RE: Software for PKI

... the DNSSEC RFC standards talk about adding security to DNS ... in part by starting with effectively chain of trust/evidence with public keys. independent of the DNSSEC work, registering of public keys would also support making the domain name infrastructure more secure for TTP CA purposes associated with SSL domain name certificates.

the mapping of domain name to ip address integrity issue was the primary reason for having SSL domain name certificates at all in the first place. While most people click on https for secure tunnel for their credit card numbers .... the actual implementation of the SSL handshaking chatter .... checks the domain name in the certificate provided by the server it is talking to at the ip-address provided by dns ... with the domain name that it thinks it is talking to.

Having created that infrastructure for SSL domain name certificates .... somewhat implies that somebody thot the mapping from domain name to ip-address was an issue .... enuf to justify the whole SSL domain name certificates and browser use of those domain name certificates as part of the SSL/TLS protocol .... aka if there was an actual belief that the ip-address for the specified URL was always correct .... there would be no reason for the client to check if the server at the ip-address mapped by DNS is the server that the client thinks it is.

The issues are

1) DNSSEC & public keys can be part of scaffold to address integrity issues in the domain name infrastructure (both for TTP CAs but also for all the clients in the world)

2) with #1, clients can trust the DNS IP-addresses ... then they can eliminate the check that they do with SSL domain name certificates (checking that the server at the DNS-provided ip-address they are talking to has the domain name certificate that matches the domain the client specified in the browser ... prior to the DNS lookup).

3) if #2, then SSL domain name certificates can be eliminated as unnecessary, redundant and superfluous.

4) if #1, and somebody actually wants to know a server's public key, and they can otherwise trust the distribution of information by the domain name infrastructure ... then they can also trust the DNS distribution of public keys ... in so far as the public key is with respect to some network domain name operation.

ron.ramsay@xxxxxxxx on 11/8/2001 4:53 PM wrote:
The problem is not in the registration. The problem is in retrieving the public key. PGP, for example, is based on the "web of trust", and this does not mean picking up public keys where you can find them.

Putting public keys into DNS would be as useless as tits on a bull. DNS offers no security. It is trusted only because providing the IP address for a domain name is not yet regarded as a critical function. Providing public keys in this random way would, I guess, expose the vulnerabilities of the system.

Ron.

Software for PKI

From: Lynn Wheeler
Date: 11/08/2001 06:17 PM
To: Rich Salz <rsalz@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: Software for PKI

as an aside ... rfc3000 went up yesterday (i.e. new STD1) and there were some minor nits when I parsed it ... but there is a new rfc3000 with corrections up now and I've also just finished updating the index at
https://www.garlic.com/~lynn/rfcietff.htm

also if there is interest ... i can go back add an explicit DNSSEC category/indexing to the term index.

and for those of you intested a bunch of new "ancient" RFCs have also gone up (these are old RFCs, typically from the early '70s that lacked a 'electronic' version ... and there is program to go back and generate softcopy from surviving hardcopies.

lynn.wheeler wrote:
therre is a web site that the rfc-editor points at:
https://www.garlic.com/~lynn/rfcietff.htm

some amount of that information also used to be included in STD1 ... and the process used to generate the information on the web site also is used to cross-check the information in STD1, including, but not limited to the information that used to be carried in section 6.10 of STD1
https://www.garlic.com/~lynn/rfcietf.htm#obsol

DNSSEC (RE: Software for PKI)

Refed: **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/09/2001 07:19 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, kelm@xxxxxxxx
Subject: Re: DNSSEC (RE: Software for PKI)

Well, comparing a chain-of-trust:

1) both TTP CAs and DNS are dependent on the same domain name infrastructure registration & operation as the authoritative reference as to the validity of domain name owndership.

2) Registering public keys as part of domain name registeration to improve the integrity of #1 would also be the same for both TTP CAs and DNS

3) DNS would obtain the public key from that data base in real time ... effectively inverting the current TTP CA PKI valid key issue. The TTP CA for SSL domain name certificates doesn't have a real PKI i.e. from the point of view of administrating stale certificates that they have manufactured at some time way in the past .... based on #1 & possibly #2, DNS effectively jumps way ahead of the existing SSL domain name certificate to the equivalent of a real PKI ... having real-time administration of validity of public keys.

4) SSL currently obtains a server public key from a lot of protocol chatter involving certificate distribution, certificates which have been signed by some CA public key. Then the current SSL validates a certificate with CA public keys that have been distributed as part of the browser. Once, the certificate signature has been validating (note that this isn't a real PKI so none of the other certificate validation stuff is in effect), then the cretificate can be checked that the domain name requested and the domain name in the certificate is the same. After that, the validity of some signed something from the server can be validated with the public key in the certificate.

5) In a DNSSEC world, browser could obtain a valid ip-address and public key in the same DNS transaction. By definition, the ip-address is trusted (so the issue of domain name to ip-address translation is eliminated). Also, by definition the public key for that "domain name/ip-address/public key" tuble is trusted. Majority of the protocol setup chatter in the existing SSL is eliminated ... since there is real-time trusted key distribution (as part of real-time trusted ip-address distribution). So the only real SSL setup step that is left is the validaty of some signed something from the server.

The issue ... as always ... with DNS is does it provide real-time trusted information distribution. If DNSSEC can improve the trust & integrity of that process ... then I would claim that there is, in effect, a real PKI (real-time distribution and administration of trusted public keys) as compared to the restricted subset of certificate manufacturing that occurs today for SSL domain name certificates.

anders.rundgren@xxxxxxxx on 11/9/2001 3:10 am wrote:
Stefan, Does not DNSSEC suffer from basically the same problems as web-server certficates with resp to RPs? I.e. you must install trusted root certificates in clients. Or is the hope that there will be just a single root? Signed by UN I guess...

The primary advantage seem to be that people don't have to buy and install web-server certificates. Quite a TTP-market there that goes into pieces!

But does HTTPS really work without these? If it does not, I don't think DNSSEC will be such a success.

Anders

DNSSEC RFCs, was Software for PKI

From: Lynn Wheeler
Date: 11/09/2001 08:05 AM
To: Rich Salz <rsalz@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: DNSSEC RFCs, was Software for PKI

ok, updated rfc index is out with DNSSEC:
https://www.garlic.com/~lynn/rfcietff.htm

select Term (term->RFC#) and then select DNSSEC in the acronym list

entry now looks like:
domain name system security (DNSSEC )
see also domain name system , security
3130 3008 3007 2541 2540 2539 2538 2537 2536 2535 2137 2065

lynn.wheeler@xxxxxxxx on 11/8/2001 wrote:
as an aside ... rfc3000 went up yesterday (i.e. new STD1) and there were some minor nits when I parsed it ... but there is a new rfc3000 with corrections up now and I've also just finished updating the index at
https://www.garlic.com/~lynn/rfcietff.htm

also if there is interest ... i can go back add an explicit DNSSEC category/indexing to the term index.

and for whose of you intested a bunch of new "ancient" RFCs have also gone up (these are old RFCs, typically from the early '70s that lacked a 'electronic' version ... and there is program to go back and generate softcopy from surviving hardcopies.

3D Secure Vulnerabilities?

Refed: **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/09/2001 09:08 AM
To: "Richard D. Brown" <rdbrown@xxxxxxxx>
cc: internet-payments@xxxxxxxx, "Jack A. Hudson" <jackahudson@xxxxxxxx>
Subject: RE: 3D Secure Vulnerabilities?

from an integrity standpoint .... the financial industry's X9.59 provides direct end-to-end secure authentication on the actual authorization transaction .... regardless of what middlemen and/or other's might attempt, the transaction flows all stay the same, it has already been mapped into both debit & credit message formats.

the heavy lifting in either a shared-secret based authentication scheme or a public-key based authentication scheme is the administrative infrastructure to register and keep consist what is registered at the issuer with what the consumer is using .... once such adminstrative issues/infrastructure are handled .... the technology differences between shared-secret authentication vis-a-vis public-key authentication are almost in the noise range.

X9.59 does have the advantage

1) it is a financial industry standard

2) it isn't a shared-secret based authentication scheme

3) it was designed to work for all account-based transactions

4) it was designed (with hardware token) to work in all environments (POS, internet, non-internet, etc).

5) it specifies business requirement that account numbers used in X9.59 transactions can't be used in non-authenticated transactions (eliminating the huge security & compromise exposure of merchant account master files).

refs:
https://www.garlic.com/~lynn/x959.html#x959

the standard publication is available at:
https://web.archive.org/web/20020214081019/http://webstore.ansi.org/ansidocstore/product.asp?sku=DSTU+X9.59-2000

rdbrown@xxxxxxxx on 11/9/2001 8:34 am wrote:
Actually, if you assume the existence of a share secret between the issuer and the card holder, why don't you use said secret to directly authenticate the transaction.

Kedemon have been promoting such a solution for over a year. This approach does not require any directory server nor does it require merchants to change their transaction flows. With further compression and encoding of the authentication code, this solution is strictly compatible with the infrastructures in place today for acceptance and authorization of card transactions.

See http://www.kedemon.com/papers/TVCWP0305.pdf for further details.

DNSSEC (RE: Software for PKI)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/09/2001 09:30 AM
To: EKR <ekr@xxxxxxxx>
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
ietf-pkix@xxxxxxxx, kelm@xxxxxxxx
Subject: Re: DNSSEC (RE: Software for PKI)

since the client already has the public key for the server before it even does anything (i.e. as part of obtaining the ip-address), the client encrypts cypersuites, session id, key all in one message. Server responds accepted/finsihed or changespec. Single round-trip if the server accepts the client's specification. To increase the probability, the server can register the preferred ciphersuite with their key in DNS and DNS can distribute that as a single bundle with the key ... in the single DNS call.

There is no middle man attacks ... assuming trusted distribution of the public key ... since only the server can decode what the client has sent in the initial message.

There is the ancillary issue of flowing HTTP/HTTPS/stateless over short TCP ... with the associated TCP set-up/shutdown (all the performance issues with various TCP linear list scanning from the early & mid-90s)

The issue then is to look at having real tunneling with long-term (TCP) sessions and a real stateless transactiion where the client transaction is piggybacked with the setup ... more like reliable UDP and do the transaction version in single packet round-trip ... aka XTP (actually three packet exchange for reliable setup/transaction/tear-down/etc ... but that is better than the TCP minimum of seven packet)

random ref:
https://www.garlic.com/~lynn/99.html#0 Early tcp development?
https://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#207 Life-Advancing Work of Timothy Berners-Lee
https://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001b.html#57 I am fed up!
https://www.garlic.com/~lynn/2001e.html#24 Pre ARPAnet email?

ekr@xxxxxxxx on 11/9/2001 8:58 AM wrote:
Actually, very little of the SSL protocol overhead is concerned with certificate issues. Most of it is concerned with ciphersuite negotiation, key exchange and handshake verification, none of which would be affected significantly by DNSSEC.

The typical SSL handshake is:



C: ClientHello (ciphersuites, random, session id)
S: ServerHello (ciphersuite selection, random, session id)
S: Certificate
S: ServerHelloDone
C: ClientKeyExchange
C: ChangeCipherSpec
C: Finished
S: ChangeCipherSpec
S: Finished

In a hypothetical world in which we had DNSSEC we'd be able to eliminate exactly one of these messages, the server Certificate.

I agree that a world with DNSSEC would be potentially more secure than the current world of SSL certificates, but it wouldn't make SSL much simpler.

-Ekr

-- [Eric Rescorla ekr@xxxxxxxx]
http://www.rtfm.com/

DNSSEC (RE: Software for PKI)

From: Lynn Wheeler
Date: 11/09/2001 10:16 AM
To: kelm@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: Re: DNSSEC (RE: Software for PKI)

but the cache protocol has life-time specified nominal is in the range of minutes to hours ... which is much better than years for certificates. you don't actually have to revoke a key ... there is just the maintenance of what is the valid key (if any) ... and the issue of what size caching window that you are willing to tolerate for the data. A hypothetical key compromise could take on the order of hours from occurance, discovery, administrative to validate report, etc .... so a reasonable policy might still be a cache life-time of an hour.

and if you were really paranoid you can also do a DNS transaction that looks up the data directly from the server, bypassing the caching i.e. client could choose to bypass whatever the infrastructure chosen policy for cache life-time .... supporting both institutional-centric policy and client-centric policy.

kelm@xxxxxxxx on 11/9/2001 9:57 AM wrote:
Lynn,

yes and no. One of the problems is that you cannot actively "revoke" a key or a signature other than physically delete that information from the DNS zone file. However, the DNS data will still be cached in dozens of servers out there.

Cheers,

Stefan.

DNSSEC (RE: Software for PKI)

From: Lynn Wheeler
Date: 11/09/2001 10:37 AM
To: kelm@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>, EKR <ekr@xxxxxxxx>
Subject: Re: DNSSEC (RE: Software for PKI)

this is confusing two totally different issues.

DNS already provides for arbritrary distribution of information ... like room-number, phone number, etc.

The issue with regard to DNSSEC and public-key distribution isn't with regard to whether DNSSEC is trying to distribute public-keys. DNSSEC is trying to improve the integrity of the distribution of information.

The issue with regard to distribution of public-keys is whether there is integrity & trust in the distribution of the public keys. DNS could be used, unmodified today for distribution of public-keys.

The issue isn't whether existing DNS today could be used for distribution of public-keys ... the issue is whether anybody would trust that distribution.

DNSSEC addresses the integrity and trust issue of DNS distributed information.

Now it just happens that DNSSEC can use public-key infrastructure for improving the integrity for the distribution of information (regardless of what information is being distributed).

In that sense, DNSSEC is analogous to a CA trust hierarchy .... aka CAs' public key infrastructure is used to establish trust in the certificate method of distributing public keys. The CAs' public key infrastructure provides a integrity & trust mechanism for the public keys being distributed in certificates (as well as whatever other information might be distributed in certificates). The method that CAs use to provide integrity & trust in the certificate public key distribution also happens to be public keys.

Now, the other part of the integrity and trust part of the domain name infrastructure is with regard to the administrative end that has resulted in things like domain name hijacking ..... aka that domain name owners register public keys when they register domain names. That improves the integrity and trust of the domain name system .... not only for DNS but also for the CA TTPs that rely on the domain name infrastructure as the authoritative agency with regard to domain name ownership.

So

1) DNS as it is today can distribute any arbtritrary information .... including public keys

2) nominal important in the distribution of public keys are trust and integrity issues which DNSSEC directly addresses

3) domain name infrastructure has administrative reasons for registering public keys that have nothing at all to do with supporting DNS distribution of public keys ... the domain name infrastructure administration has a reason for having domain name public keys registered so that administrative transactions associated with domain name ownership and operation can be authenticated.

4) Given that domain name infrastructure can #1 distribution arbritrary information, including public keys, and #2 DNSSEC addresses the issue of trust and integrity of the distriubtion of information, including public keys, and #3 a administrative interface is put in place ... regardless ... for the registering of public keys .... then I claim that clients can take advantage of all the pieces to improve the integrity and trust in the overall internet operation by having near real-time access to public key distribution

kelm@xxxxxxxx wrote:on 11/9/2001 10:06 AM:
this is not the way DNSSEC is supposed to be working. The KEYs within DNSSEC will mainly be used as DNS zone keys. Yes, one can use DNSSEC to distribute application keys as well but I'm not sure this will happen.

Cheers,

Stefan.

3D Secure Vulnerabilities?

From: Lynn Wheeler
Date: 11/09/2001 10:47 AM
To: "Lewis, Tony" <TLewis@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject: RE: 3D Secure Vulnerabilities?

I believe I wrote that x9.59

1) provides end-to-end authentication of the actual (account-based) authorization transaction

2) has business rules that require that account numbers involved in X9.59 can only be used in authenticated transactions (eliminating much of the horrendous security and integrity issue with regard to harvesting of aggregatted account numbers that is prevalent at most merchants).

there are possibly millions of other authentication and even identification issues faced by the financial industry.

There are lots of non-mons .... non-financial transactions

There are things like account establishment ... when you establish an account, will the financial industry authenticate and/or identify you.

Even in #2 above .... while X9.59 has a business rule specification that says account numbers used in X9.59 will not be used in non-authenticated transactions .... X9.59 only specifies the account-based financial/authorization transaction. For non-financial transactions involving the same account number, X9.59 has no specification (other than a business rule specification that all such transactions should be authenticated).

tlewis@xxxxxxxx on 11/9/2001 9:56 AM wrote:
Does anyone other than Lynn think that X9.59 solves every single authentication problem that the financial industry faces?

DNSSEC (RE: Software for PKI)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/09/2001 02:44 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: DNSSEC (RE: Software for PKI)

yes, well, humm.

my wife and I had been doing these networky things
https://www.garlic.com/~lynn/internet.htm#0
https://www.garlic.com/~lynn/subnetwork.html#hsdt
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

as part of some generalized high-assurance data processing
https://www.garlic.com/~lynn/subtopic.html#hacmp
https://www.garlic.com/~lynn/subtopic.html#smp

anyway several years ago, we were doing some consulting to this financial services company and somebody from this new, small client/server startup wanted to do financial transactions and my wife and I got assigned to work with the small startup (in part because we had worked with the people in charge of the project in previous life):
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/2001i.html#52

in any case they had this thing that they were going to call SSL for protecting the transaction/information in flight .... that involved these things called certificates. As part of the assurance review ... there had to be a detailed end-to-end business process audit ... that was significantly more than end-to-end protocol assusrance audit.

Out of the end-to-end business process reviews and deploying the stuff in operational environment (now frequently referred to as electronic commerce) we happened to gain some working knowledge about where the security and trust issues were. It has actually seen fairly wide-spread and successful deployment.

Some of this experience went into the financial industry work on a electronic payment standard for all account-based transactions
https://www.garlic.com/~lynn/x959.html#x959

and some of it went into attempting to apply public key authentication technology to existing business and technology infrastructures:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
https://www.garlic.com/~lynn/subpubkey.html#radius
https://www.garlic.com/~lynn/x959.html#aads

note that it is possible to apply public-key distribution as part of the existing DNS infrastructure as in this discussion thread. Another application of public-key authentication technology is to integrating it into existing RADIUS (and/or other) client authentication infrastructure .... effectively substituting the registration of a public key in place of registration of a password. In the DNS case, it is to leverage a widely deployed information distribution protocol to also distribute public keys. In the RADIUS (and similar cases) it is for the relying-party to directly use their own public-key registration database w/o actually distributing the keys. There is something of a gray area with regard to the sematics of the process ..... in one case it can be viewed as information push from the database (sort of as in the DNS cache scenerio) and in the other there is a information pull from the database (as in the case of real-time access by RADIUS to the enterprise authentication database).

In any case, the DNS use of caching is a pure implementation thing. Lots of the above .... all the requests always execute against the actual real-time data .... as opposed to having a temporary cache. Now, in database terms, from work that we did on distributed lock manager for super-scaling database
https://www.garlic.com/~lynn/subtopic.html#hacmp
as well as some experience working on design of CPU caches
https://www.garlic.com/~lynn/subtopic.html#smp

things can be stated in terms of strong memory consistency, to week memory consistency, to fuzzy memory consistency. The degree of distributed memory consistency tends to be somewhat dependent on the application requirements. Financial transactions tend to have relatively strong memory consistency. And for some cases, you avoid doing distributed memory at all and all requests execute directly on the repository. Most public-key distribution consistency issues are somewhat simplified because there aren't actually real distributed transactions (changing public key values). All the existing caching schemes have tended to be R/O caching (certificates can be viewed as one form R/O distributed caching of information). The upside of certificates is that they are useful for offline environments. The downside of the existing certificate distribution schemas have effectively little bound on the number of places that R/O copies might occur. DNS is significantly better than that ... with the bounding not so much better in space ... but significantly better bounded in time. It is reasonable to to do a risk assurance on the DNS time-bounding and possibly dynamically adjust values. Also, there is a much more robust distribution infrastructure (from the services stand-point). By comparison, certificates have tended to go to the entity registering the public key and then they do arbritrary re-distribution. By comparision a distributed transaction database that confirms to strick ACID properties will always be able to predictably do transaction operations.

Similar to the RADIUS case is the application of registering public-keys at financial institutions using effectively the same business process used to register PINs (frequently seen in debit &/or atm related activities):
https://www.garlic.com/~lynn/nacharfi.htm
https://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

All of these can be done with a combination of RA technology (from the CA world for registering public keys) and existing business processes currently used for managing other types of authentication information (aka technology upgrades while maintaining existing business processes .... as opposed to trying to introduce radical surgery on business operations).

there has also been a lot of effort put into the hardware token effort:
https://www.garlic.com/~lynn/aadsm2.htm#straw
https://www.garlic.com/~lynn/x959.html#aads

a lot of it tho has come out of prior experience in deploying complex, industrial strength, dataprocessing environments.

anders.rendgren@xxxxxxxx at 11/09/2001 12:19 pm wrote:
Lynn,
This is interesting. What you are saying is that server-based PKI (sort of) that generates fresh (or short-time cached) responses from a database is the way to go.

This is essentially the same thing I have been pushing several years for extranet authentication. That each company server generates freshly signed "tickets" (http://www.x-obi.com/purple) based on their databases instead of issuing and distributing employee certificates.

Server-cryptography rulez!

These DNSSEC servers will not be practical until HW-crypto support is down in the $100 region. This may take another 5 years or so. It is driven by the B2B market that needs such servers as well.

Anders

DNSSEC (RE: Software for PKI)

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/09/2001 03:13 PM
To: EKR <ekr@xxxxxxxx>
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>, ekr@xxxxxxxx,
ietf-pkix@xxxxxxxx, kelm@xxxxxxxx
Subject: Re: DNSSEC (RE: Software for PKI)

oops, the client for current SSL is getting several transmissions from a single source .... and only because PKI has not been implemented (just certificate manufacturing .... if PKI implementation was ever attempted, the client could have a huge number of responses with large number of different entities).

Yes, SSL needs the option of working in the non-DNS environment.

However, the discussion started with my clain with regard specifically to SSL domain name certificates possibly accounts for 99.99999 percent of all certificate relateed operations that occur in the world today and the supposed purpose for the existance of those SSL domain name certificates was because of perceived integrity problems with the DNS domain name infrastructure operation. Also that within the context of that purpose for the existance of the SSL domain name certificates and representing a significant percentage of all such operations .... that something else might make sense.

It might be useful for having a specific optimization for 99.99999 percent of the events .... and let the remaining .0000001 percent of the events be done the less efficient way.

Aka, in a DNS environment ... the client has to make the DNS call regardless and get the DNS results regardless. Piggy-backing the public key on that call does not increase any additional client transactions with any addition entities.

Then SSL setup is done in a single round-trip .... for possibly 99.999999 percent of the cases.

And SSL could be done some other, less efficient way for the remaining .0000001 percent of the cases.

The difficulty of having such an option isn't any worse than the existing option for mutual certificate authentication which gets used even a lower percentage of the time than the non-DNS operations.

ekr@xxxxxxxx on 11/9/2001 12:50 pm wrote:
In fact, what was proposed at the time was an optimization whereby if the client knew the server's public key and preferences (never mind how) it could short-circuit the handshake. This would also have allowed the client to cache the server's identity data.

In any case, this doesn't really simplify things very much. The client needs to process much the same data but from two sources rather than one. And since SSL has to work in situations where DNS is not available, you need to retain the full handshake anyway so you've added complexity to the protocol, not subtracted it. At the time the sense of the group was that DNSSEC was insufficiently deployed to make this a worthwhile optimization. Things haven't changed much in 5 years.

-Ekr

3D Secure Vulnerabilities?

Refed: **, - **, - **, - **

From: Lynn Wheeler
Date: 11/09/2001 04:05 PM
To: "Richard D. Brown" <rdbrown@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject: RE: 3D Secure Vulnerabilities?

actually, the X9.59 standard doesn't mandate digital signature crypto-system. The X9.59 standard defines the data elements for an authenticated transaction.

In the appendix of the X9.59 document there is an example of 1) a specific digitally signed authenticated X9.59 transaction and 2) a methodology of mapping the X9.59 data elements and a digital signature into existing payment network messages. In the example in the appendix, the originally X9.59 data elements are decomposed into individual components for transmission via existing payment network ... and then a methodology for recreating the originally signed object for signature verification .... a fundamental principal of both the standard and the mapping ...... is to the extent absolutely possible the data values in the X9.59 specification are also the actual data values in the financial transaction (to the extent that the financial transaction has corresponding data elements) i.e. the authentication message and the transaction message are not disjoint.

That example ... which is not part of the standard ... but an example of how the standard might be implemented can also be found at:
https://www.garlic.com/~lynn/8583flow.htm

During the several year course of the standard development, numerous people were solicited for implementation examples for the appendix. However, there is nothing that is in the standard that specifies a specific authentication technology (digital signature or otherwise). The specific example referenced does use FIPS.146-2 digital signature authentication ... and in the example space requirements assumes 42-byte signature as the authentication payload part of the message.

There are specific data elements in the X9.59 standard that don't currently exists in most current payment network messages which are also identified. These data elements were decided within the context that X9.59 transactions need to preserve the integrity of the financial infrastructure. However, to the extent that a payment network message has a equivalent data element the value is carried in the actual payment transaction. The issues of additional X9.59 data elements (that currently don't exist in current payment network messages) were decided on to meet the requirement given the X9A10 working group with regard to preserving the integrity of the financial infrastructure for all electronic retail payment transactions.

As mentioned previously, NACHA has already gone ahead and done an ATM/debit pilot somewhat similar to the example implementation given above using digital signature authentication.

rdbrown@xxxxxxxx on 11/9/2001 3:16 pm wrote:
Although a fervent supporter (for the system considered herein) of the AADS concept (even more so about the end-to-end rule of thumb) adopted in X9.59, I've great concern regarding X9.59 itself, and totally disagree with the above statement. The choice of the crypto-system has fundamental implications.

X9.59 mandates the use of a digital signature crypto-system while Kedemon's solution promotes the use of a message authentication code (MAC). The difference I'd like to emphasize is in the verification processes and, more specifically, the implications in term of the authentication payload.

A fundamental principal in a digital signature crypto-system is that the verifier has no mean to compute the authentication payload. The payload is a parameter of the verification algorithm, and cannot be tampered with (at least in a nonreversible way). In other words, the output of the signature algorithm must be presented, as it, to the verification algorithm.

In a MAC crypto-system, the verification is accomplished by computing the 'expected payload' and then comparing said expected payload with the one attached to the message. Because both parties have the ability to compute the MAC, verifiability can be preserved when the parties agree upon given manipulations of the MAC value. More importantly, it does not matter whether these manipulations are reversible or not (one-way).

AADS Postings and Posting Index,
next, previous - home