Misc AADS & X9.59 Discussions

AADS Postings and Posting Index, next, previous - home

The case against directories
Who's afraid of Mallory Wolf?
Who's afraid of Mallory Wolf? (addenda)
Armoring websites
Who's afraid of Mallory Wolf?
Who's afraid of Mallory Wolf?
The case against directories
Bank Float May Sink
Labour to launch ID card - and it'll cost you Ł25
"Marginot Web" (SSL, payments, etc)
Microsoft Identity Server Prepped For Windows Server 2003
Oasis Pushes Global E-procurement Standardization
Tackling security threats from within
A Trial Balloon to Ban Email?
blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
Payments as an answer to spam
Payments as an answer to spam (addenda)
Payments as an answer to spam (addenda)
Payments as an answer to spam (addenda)
Payments as an answer to spam (addenda)
Financial Privacy To Take The Floor
Identity Theft Losses Expected to Hit $2 Trillion by 2005
Maybe It's Snake Oil All the Way Down
Microsoft Ties Security to Verisign
OASIS and RosettaNet Set Standards Alliance
Maybe It's Snake Oil All the Way Down
Maybe It's Snake Oil All the Way Down
Maybe It's Snake Oil All the Way Down
Maybe It's Snake Oil All the Way Down
Maybe It's Snake Oil All the Way Down
Maybe It's Snake Oil All the Way Down
An attack on paypal
An attack on paypal
virus attack on banks (was attack on paypal)
The real problem that https has conspicuously failed to fix
An attack on paypal
Keyservers and Spam
An attack on paypal (trivia addenda)
An attack on paypal
The real problem that https has conspicuously failed to fix
certificates & the alternative view
An attack on paypal
PKI "not working"
PKI "not working"
Keyservers and Spam
An attack on paypal
UK: PKI "not working"
basic question: semantics of "map", "tie", etc in PKI
replay & integrity
E-banking is board-level Issue, Says Basel Committee
Feds, industry warn of spike in ID theft scams
Committee calls for better e-banking security management
IT Managers Critical Front in War on Identity Theft
Draft E-Authentication Policy for Federal Agencies
The Best ID Plan? Wait and See
IT Security to be added to FAR
Kinko's spy case: Risks of renting PC's

The case against directories

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

From: Lynn Wheeler
Date: 03/23/2003 12:16 PM
To: David Chadwick <d.w.chadwick@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
    epay@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: The case against directories

ref:
http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories

we've had some long term experience in this. the kerberos reference .... was from one of the audit visits that my wife and I did on project athena .... and sitting thru an extended detailed description of the "new" cross-domain kerberos protocol .... and various subsequent discussons.

however, going back even further ... almost 25 years ago ... a couple of us were sitting around friday night trying to think up ways of getting upper management interesting in online use. one of the compelling business uses was an online telephone directory (for some 450,000 or so employees & increasing). we had some simple objectives .... 1) online lookup elapsed time faster than reaching for a local site paper directory and looking it up, 2) take 2 person weeks or less to implement, 3) take less than a half person day per month to support, 4) in addition to existing informaiton like name, telephone number, internal mail-stop ... allow it to grow into things like email address.

so we started contacting various plant sites .... asking for process that would regularly transmit the machine readable copy that they used for producing the site's paper directory. It turned out what started to consume the most time were discussions with the site security officers about security classification of an online directory .... that was only available inside the corporation ... and only contained name and telephone number ... and was an exact duplicate of the paper directory. Paper directories were classified internal use only .... the security officers wanted to classify the equivalent information (even if it was only name and telephone number) when made available online at a significantly higher security level (even if it was only accesable from inside the corporation).

much longer (including technical) description of the online telephone directory effort:
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)

note that the internal network at the time was larger than the internet/arpanet and continued larger up thru approximately 1985.
http://www.garlic.com/~lynn/internet.htm#4 Internet (TM) and USPTO
http://www.garlic.com/~lynn/internet.htm#0 Internet and/or ARPANET
http://www.garlic.com/~lynn/internet.htm#22 internal network's 1000th node
http://www.garlic.com/~lynn/2003d.html#59 unix

totally random trivia was in the mid-80s i was told that the internal network had over half of all link encryptors in the world.
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

d.w.chadwick@xxxxxxxx on 3/22/2003 7:26 am wrote:
Lynn

well said. Access controls and privacy issues apply regardless of technologies.

David

Who's afraid of Mallory Wolf?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 10:10:53 -0700
To: Ian Grigg <iang@xxxxxxxx>
Subject: Re: Who's afraid of Mallory Wolf?
Cc: cryptography@xxxxxxxx

At 11:10 PM 3/23/2003 -0500, Ian Grigg wrote:
Who's afraid of Mallory Wolf?

slight observations ... i've heard of no cases of credit card number intercepted on the internet "in flight" (requiring crypto) ... and no known cases of MITM attack (requiring certificates)

However there have been some cases of impersonation ... being directed to a counterfeit web-site. I know of no cases of that being done with DNS cache poisoning ... which is also what certificates are targeted at ... both MITM and other impersonations of various kind. the ones i'm aware of is that the person clicks on some URL and goes to that site .... which is a counterfeit website. This isn't caught by SSL ... since it just compares the domain name in the URL against the domain name in the certificate presented by the server. Since the subterfuge happens well before any DNS cache is involved ... the SSL check of matching domain names doesn't catch anything. There have also been various impersonation involving frames and other screen painting techniques.

There have been cache poisonings (ip-address take over) ... there have been also incidents in the press of domain name hijacking ... sending updates to domain name infrastructure convincing them that somebody else is the new domain name owner. getting a new certificate as the new domain name owner is also a way of subverting the SSL check of matching domain names.
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg1
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg2

people registering public keys at the same time they register domain names was one of the suggested countermeasures to domain name hijacking.

There was another press thing last week regarding DNS attacks. The issue raised by the DNS attack last fall and the latest warning is that these have the potential to bring the internet to a halt.
http://www.computerworld.com/securitytopics/security/story/0,10801,79576,00.html

so there is some effort regarding dns integrity because of its critical importance for just having internet function at all.

past dns attack refs:
http://www.garlic.com/~lynn/2003.html#49 also
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,75564,00.html
http://www.zdnetindia.com/news/commentary/stories/73781.html
http://www.zdnetindia.com/print.html?iElementId=73777

from a cost of business standpoint ... i've suggested why not use the existing DNS infrastructure to distribute server public keys in the same way they distribute ip-address (they are pieces of information bound to the domain name, a function of the domain name infrastructure).... and are capable of distributing other things ... like administrative & technical contacts .... although that is getting restricted ... some bleed over from pkix
http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories
http://www.garlic.com/~lynn/aadsm14.htm#0 The case against directories

they could be naked public keys ... which would also be subject to DNS cache poisoning ... or they could be "signed" public keys .... doesn't need all the baggage of x509 certs ... can just be really simple signed public key.

Slightly related to the above posting about long ago and far away .... when looking at allowing people (20 plus years ago) on business trips to use portable terminals/PCs to dial in and access the internal network/email .... a vulnerability assesement found that one of the highest problem areas was hotel PBXs. as a result a special 2400 baud encrypting modem was created. encrypting modem anecdote from the time:
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)

... these weren't in any related to the link encryptors from the previous reference (aka supposedly over half of the link encryptors in the world were installed on the internal network).

in any case, there was a big concern about numerous kinds of evesdropping ... requiring encryption for information hiding. however, the current internet credit card scenario seems to be that it is so much easier to harvest a whole merchant file with tens or hundreds of thousands of numbers ... than trying to get them one or two at a time off some internet connection.

note that the x9.59 approach has always been to remove the credit card numbers as a point of attack (form of shared-secret) by requiring all transactions to be authenticated. as a result, just knowing the number isn't sufficient for fraud (countermeasure against all account number harvesting .... regardless of the technique and whether insider or outsider attack):
http://www.garlic.com/~lynn/x959.html#x959

the low-hanging fruit theory is that if merchant sites were armored then there could be more interest in evesdropping-based harvesting ... (leading to more demand for internet encryption). However. armoring merchant sites is difficult since 1) there are potentially millions, 2) human mistake is frequent/common vulnerability, 3) still leaves insiders as threat.

other parts of security proportional to risk thread:
http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#24 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#25 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#28 Security Proportional to Risk (was: IBM Mainframe at home)

Who's afraid of Mallory Wolf? (addenda)

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 10:21:47 -0700
To: Ian Grigg <iang@xxxxxxxx>
Subject: Re: Who's afraid of Mallory Wolf? (addenda)
Cc: cryptography@xxxxxxxx

.... and while I don't know of any internet-based evesdropping for account number harvesting .... there are numerous reports of skimming in the physical world .... harvesting of account numbers by all sorts of techniques. These include things like video cameras by crooks trained on various kinds of POS and other terminals.

misc. skimming references:
http://www.garlic.com/~lynn/aadsm12.htm#40 In Brief: Anti-'Skimming' Guidelines Coming
http://www.garlic.com/~lynn/aadsm12.htm#57 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aepay10.htm#3 High-tech Thieves Snatch Data From ATMs (including PINs)
http://www.garlic.com/~lynn/aepay10.htm#41 ATM Scams - Whose Liability Is It, Anyway?
http://www.garlic.com/~lynn/aepay10.htm#44 Credit Card Skimming Rising In The US
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
http://www.garlic.com/~lynn/aepay9.htm#skim High-tech Thieves Snatch Data From ATMs (including PINs)
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
http://www.garlic.com/~lynn/2002i.html#74 A Lesson In Security
http://www.garlic.com/~lynn/2002j.html#60 How to map a user account to a digital cert?
http://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002l.html#20 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology, was: Convenient and secure

Armoring websites

Refed: **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 12:29:17 -0700
To: Ian Grigg <iang@xxxxxxxx>
Subject: Armoring websites
Cc: cryptography@xxxxxxxx, epay@xxxxxxxx

ref:
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#2 Who's afraid of Mallory Wolf? (addenda)

here is discussion of armoring websites with respect to security proportional to what is at risk
http://www.garlic.com/~lynn/2001h.html#61 net banking, is it safe???
http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk

random refs to hardened sites:
http://www.garlic.com/~lynn/aadsm2.htm#risk another characteristic of online validation.
http://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2002.html#44 Calculating a Gigalapse
http://www.garlic.com/~lynn/2002m.html#5 Dumb Question - Hardend Site ?
http://www.garlic.com/~lynn/2002m.html#6 Dumb Question - Hardend Site ?
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2003c.html#52 diffence between itanium and alpha

Who's afraid of Mallory Wolf?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 17:50:17 -0700
To: daw@xxxxxxxx (David Wagner)
Subject: Re: Who's afraid of Mallory Wolf?
Cc: cryptography@xxxxxxxx

At 10:02 PM 3/24/2003 +0000, David Wagner wrote:
You could take your argument even further and ask whether any crypto was needed at all. After all, most attacks have worked by compromising the endpoint, not by sniffing network traffic. I'll let you decide whether to count this as a success story for SSL, or as indication that the crypto wasn't needed in the first place. (I'm a little skeptical of this argument, by the way, but hey, if we're playing devil's advocate, why not aim high?)

I assert that there may be more sites that transmit credit card numbers w/o crypto, as sites that use SSL (although transaction rates are highly skewed so they even if it were ten times the number of sites, it might represent fewer actual transmissions). I don't have actual numbers, but I am aware of significant number of sites. However, I would contend that harvesting numbers from end-point merchant files has significantly higher return (ROI, expected results for the effort) than any sort of network evesdropping ... and that it is practically impossible to provide the necessary armoring as countermeasure for this vulnerability; end point attacks by either insider and outsider (historically, insider attacks on financial infrastructure have represented vast majority of incidents. While it may be possible to do a single armored site .... it isn't practical to do a million such sites (for one thing, people make too many mistakes) ... as per previous ref to security proportional to risk (and the merchant file risk is proportional to the credit limits of the accounts, not the specific merchant transaction).

I would expect that network evesdropping would be employed where vulnerability was something other than kind of fraud do'able by attacking the end-point merchant file. Note however, skimming (various kinds of electronic & non-electronic recording) does go on in the physical world. Part of the issue may be that the target object (account number) has much lower occurance in general internet traffic (physical world skimming involves traffic that is almost solely account numbers). If you just have to skim, there are some number of points that are much more target rich environments (better fraud ROI) than internet traffic.

There is some phrase that if the only thing you know how to use is a hammer, then every solution may involve a nail.

The fundamental problem with account numbers is that they are effectively a kind of shared-secret .... acquiring/harvesting the numbers enables fraud. There are significant number of business processes that require the availability of the account numbers. This is one of the reasons for the end-point merchant files and also why "SET" (with significantly more complex crypto infrastructure and essentially only, also addressing data in-flight) offered very little additional over what my wife and I were involved with setting up the original SSL for e-commerce.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

The point of x9.59 wasn't to add even more layers of crypto and information hiding to protect these shared-secrets .... but to change the business model so that the account numbers were no longer shared-secrets. X9.59 uses simple digital signature for authenticated payment transactions and a business rule that account numbers used in x9.59 transactions can't be used in non-authenticated payment transactions.
http://www.garlic.com/~lynn/x959.html#x959
aka just by evesdropping an x9.59 transactions or harvesting account numbers used in x9.59 transactions doesn't enable a crook to initiate a fraudulent payment transaction.

Who's afraid of Mallory Wolf?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 25 Mar 2003 15:32:00 -0700
To: bear <bear@xxxxxxxx>
Subject: Re: Who's afraid of Mallory Wolf?
Cc: Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx

At 12:09 PM 3/25/2003 -0800, bear wrote:
ISP's don't want to support encrypted links because it raises their CPU costs. And mail clients generally aren't intelligently designed to handle encrypted email which the mail servers could just "pass through without decrypting and encrypting".

circa '95 .... there were comments that ISP's didn't want to verify from/spoofed packet addresses on DHCP modem connections because it increased their router cpu costs (actually one of the most common routers didn't have enuf processor power to implement even trivial packet filtering on modem lines).
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

now there is the observation in this thread (or the previous thread) that many websites use SSL very sparingly because it cuts their web traffic capacity by 80-90 percent (http vis-a-vis https given the same hardware).

Typical sequence is that person clicks-on/types something and goes to a site with straight HTTP, they shop for a while ... until they are ready to check-out, they then click on the "check-out" button. That button supplies a URL that sends them off to a HTTPS site (aka the user didn't actually originated the HTTPS url) ... where all the payment information is provided. Now since the client/consumer never provided the actual HTTPS sequence .... but it was provided for them by a webpage at the HTTP site they were shopping at .... it is presumably trivial for the HTTP site that they are shopping at to make sure that the HTTPS URL domain that clients are sent to .... matches the certificate domain at that site (and a lot of shopping URLs have a lot of appended history so that it is relatively easily contrived that the consumer doesn't notice the domain name of the "check-out/payment" page).

A lot of the requirement for encryption is end-to-end ... or at least VPN-like .... so encrypted packets should mostly be transparent to operations in their ISP roles. This isn't as true on the web-hosting side of the house ... where SSL or similar encryption activity can represent significant additional CPU processing load.

The case against directories

From: Lynn Wheeler
Date: 03/28/2003 08:34 AM
To: Peter Gietz <Peter.Gietz@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
    ietf-pkix@xxxxxxxx, owner-ietf-pkix@xxxxxxxx
Subject: Re: The case against directories

the one detailed implementation presentation I've seen on a SAML based product .... looked exactly like Kerberos .... but the transmissions were SAML-encoded (and carried authorizations in addition to authentication)

misc kerberos
http://www.garlic.com/~lynn/subpubkey.html#kerberos

--

Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

peter.gietz@xxxxxxxx on 3/28/2003 4:55 am wrote:
> Using authentication systems like OASIS' SAML, organizations can
> (through their employees), authenticate to each others' intranets and
> through this get access to exactly the information they should have
> and in a format that make sense. The latter may be a directory tree,
> a PDF-file, a database listing, an HTML form, etc.
>
> Unlike directory systems, SAML allows secure access to any kind
> of active or passive information source, including purchasing and
> work-flow systems.

SAML is a good but complex means for communicating authorizations ans assertions, it is not a whole middleware infrastructure.

Bank Float May Sink

From: Lynn Wheeler
Date: 03/31/2003 12:27 PM
To: Alanslater@xxxxxxxx
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Bank Float May Sink

the reference was not between technology issues of substitute checks and e-check .... the reference was to some common business issues regarding float (as in the subject line). there were two specific processing implementations for e-check done by two different organizations. one of the organizations chose a specific implementation because it had more float than the other implementation (and there was lots of business discussion of float with regard to e-echeck) ... it appeared that lots of the business people seemed to believed that the business issues of float by far dominated numerous different technical implementations.

somewhat related is that the ACH networks tend to perform settlement of some amount of check related funds (fedwire tends to handle higher value settlement). however the aads nacha trials:
http://www.garlic.com/~lynn/x959.html#aads

used the ATM debit network providing real-time authorization.

there is some comparison with canada which is now doing ACH settlement twice a day .... eliminating some amount of float in the ACH network (however, canada has much fewer participants that need to be syncronized).

random past discussion of float
http://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
http://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

alanslater@xxxxxxxx on 3/31/2003 8:55 arm wrote:
Lynn --

It would be incorrect to associate Substitute Checks in any way with the FSTC e-check project. Several years ago, I created the concept of Substitute Checks as a way to overcome the obstacles the industry faced in implementing truncation projects. On the surface, the concept is anti-intuitiive and defies logic (we're in the process of solving the problem that it was also illegal) -- but it works.

Simply put, the concept allows an entity to digitize the image of a check, place that digitized image into the payments system and then, most importantly, gives the paying bank the option of accepting the digital image or re-creating a paper copy, including MICR, for payment. The Check Clearing for the 21st Century Act gives the same legal standing to the digital image or re-created paper copy as the original paper copy now has.

There are profound implications for this. Reduction in float is one of the minor benefits. There are significant benefits that accrue to consumers, banks and businesses from substitute checks. Consider the benefits to consumers if the checks they deposit at an ATM are digitized. Since banks no longer have to physically pick up checks daily during very tight timeframes, checks deposited up to say 7pm could be processed the same day (currently many banks use a noon cutoff). This would make the funds from the deposited checks available a business day sooner and would earn them additional interest. Banks could accept deposits for other banks thereby providing the other banks customers additional time-place convenience without increasing in fact decreasing the other bank's risk of returned checks. Merchants could be empowered and paid to accept deposits further increasing consumer convenience.

With digitized images, banks could verify signatures and look for signs of fraud at the time of deposit and make decisions about availability on the spot.

Post offices could be used to create the digital images of payments thereby eliminating physically moving the mail in addition to physically moving the paper check.

For overseas payments, US checks become readily accepted payment vehicles because the foreign countries can present these checks electronically as if they had an office in the US down the block from the paying bank.

I can go on for a long time about the benefits of this type of payment but I'll end it here. However, if you have any ideas about how we should handle checks presented in Hong Kong at 9 a.m. local time which are presented in the U.S. on the day before they were written, I'd like to know.

Regards,

Alan

Labour to launch ID card - and it'll cost you Ł25

From: Lynn Wheeler
Date: 04/20/2003 04:41 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Labour to launch ID card - and it'll cost you Ł25

http://news.telegraph.co.uk/core/Content/displayPrintable.jhtml?xml=/news/2003/04/20/nid20.xml&site=5
Labour to launch ID card - and it'll cost you Ł25
By Colin Brown and Francis Elliott
(Filed: 20/04/2003)

Everyone in Britain will have to pay around Ł25 for a compulsory identity card under proposals being put to the cabinet by David Blunkett, the Home Secretary.

The "smart" card will identify the holder using iris-recognition technology. Failure to carry the card will not be an offence but police will be able to order people to present it at a police station.

The charge is aimed at overcoming resistance to the scheme from the Treasury. Until now Cabinet support for a national compulsory identity card has been outweighed by the Treasury, which has objected to footing the estimated Ł1.6 billion bill.

... snip ...
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

"Marginot Web" (SSL, payments, etc)

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

From: Lynn Wheeler
Date: 04/20/2003 05:01 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: "Marginot Web" (SSL, payments, etc)

note that x9.59 addresses many of the payment transaction issues, however various social engineering vulnerabilities can still exist.

article:
http://www.iang.org/ssl/maginot_web.html
from above:
[4] This has been going on for a long time in the e-gold community, but now seems to have crossed over to credit cards

New way to steal password. A Discover credit card customer receives an e-mail telling him that his account is on hold due to inactivity, and that in order to reactivate his account, he must log in to this phony Web site. The information collected includes plenty of data that would enable identity theft Social Security number, mother's maiden name, account number, and passwords. Similar scams have targeted PayPal and eBay customers.

http://www.msnbc.com/news/884810.asp
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,79380,00.html
http://tinyurl.com/7mgh

...........
the above referenced article includes references to the following threads/postings
http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm13.htm#27 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm13.htm#28 How effective is open source crypto? (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#29 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#30 How effective is open source crypto? (aads addenda)
http://www.garlic.com/~lynn/aadsm13.htm#31 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#33 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#34 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#36 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#37 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#2 Who's afraid of Mallory Wolf? (addenda)
http://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#5 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Microsoft Identity Server Prepped For Windows Server 2003

From: Lynn Wheeler
Date: 04/29/2003 04:41 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Microsoft Identity Server Prepped For Windows Server 2003

http://www.internetweek.com/breakingNews/showArticle.jhtml;jsessionid=XOGY0QCHI1VBQQSNDBCCKH0CJUMEYJVN?articleID=9400091

Microsoft Identity Server Prepped For Windows Server 2003
By Paula Rooney, CRN

San Francisco -- Microsoft is turning its attention to the identity management space.

To that end, the software giant is preparing to launch the Microsoft Identity Server, formerly referred to as Microsoft MetaDirectory Services 2003, said Bill Veghte, corporate vice president of Microsoft's Windows Server Group.
.. snip ..
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Oasis Pushes Global E-procurement Standardization

From: Lynn Wheeler
Date: 04/29/2003 04:43 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Oasis Pushes Global E-procurement Standardization

http://www.internetnews.com/dev-news/article.php/2197641

April 28, 2003
Oasis Pushes Global E-procurement Standardization
By Mark Leon

The Organization for the Advancement of Structured Information Standards (OASIS) consortium has created a forum for government agencies, organizations, and private companies to work together on global e-procurement standards.

The new Electronic Procurement Standardization (EPS) Technical Committee will analyze requirements, identify gaps, and make recommendations for improving the interoperability of XML, internet based e- procurement systems.
.. snip ..
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Tackling security threats from within

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

From: Lynn Wheeler
Date: 04/29/2003 04:46 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Tackling security threats from within

note some amount of following is about identity theft (by insiders) and identity management (as a security paradigm/coutermeasure).

http://www.infoworld.com/article/03/04/25/17FEinjob_1.html

Tackling security threats from within
Bolstering your company's security system provides protection against the enemy within

By David L. Margulius
April 25, 2003

A University of Texas student steals 55,000 Social Security numbers from the school's administrative databases. A UBS Pain Webber system administrator activates a logic bomb in the company's network, causing $3 million in damage. A disgruntled Australian IT employee commandeers his company's sewage management software to dump millions of gallons of raw sewage into local parks and rivers.
... snip ...
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

A Trial Balloon to Ban Email?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Adam Back <adam@xxxxxxxx>
Subject: Re: A Trial Balloon to Ban Email?
Cc: cypherpunks@xxxxxxxx, cryptography@xxxxxxxx, lauren@xxxxxxxx, Adam Back <adam@xxxxxxxx>

the proposal in the past has been that ISPs filter spam at ingress from their customers. the counter-argument has been that there are lots of ISPs that can't be trusted to do it.

So it is much easier for ISPs to have lists of other trusted &/or untrusted ISPs that they will accept email from.

It is orders of magnitude easier (and more efficient) for ISPs to do ingress filtering for SPAM and effectively ISP blacklists than it is to populate the whole consumer infrastructure.

There are still some ways to slip thru the cracks with small amounts .... but it isn't the 40-80% volume of all email that is seen today.

It does have an analogous downside to the individual privacy issues ... which are that the big ISPs could use blacklisting for other purposes than addressing SPAM issues.

Some of the ingress filtering pushback may be similar to the early counter-arguments for packet ingress filtering related to ip-address spoofing. however, that seemed to be more a case of disparity among the router vendors in which could & could not implement ingress filtering. as majority of the router vendors achieved such capability ... the push-back significantly reduced.
http://www.garlic.com/~lynn/rfcidx7.htm#2267 2267 - Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, Ferguson P., Senie D., 1998/01/23 (10pp) (.txt=21032) (Obsoleted by 2827)

there already are logs relating ingress email to originating ISP customer id. that could be made available via some sort of legal action. the only issue then is the strength of authentication that is performed on customer connection to the ISP ... rather than some sort of origin authentication for every email.

At 03:40 AM 5/9/2003 +0100, Adam Back wrote:
Yes, there is some discussion of it on slashdot, including several other people who have commented similarly to anonymous that it is a pretty big privacy invasion and centralised control point problem.

The claim that you can optionally be anonymous and not use a cert, or get an anonymous cert is plainly practically bogus. You'd stand about as much chance of having your mail read as if you shared mail hub with spamford wallace -- ie 90+% of internet mail infrastructure would drop your mail on the floor on the presumption it was spam.

Plus a point I made in that thread is that it is often not in the internet user's interests to non-repudiably sign every message they send just to be able to send mail because that lends amunition to hostile recipients who from time-to-time target internet users for bullshit libel and unauthorised investment advice etc.

Companies also are I would expect somewhat sensitive to not signing everything for similar reasons as those behind their retention policies where they have policies of deleteing emails, files and shredding paper files after some period.

In addition PKIs because of the infrastructure requirements have probem complex to setup and administer. So now we've taken one hard problem (stopping spam) and added another hard problem (hierarchical PKI deployment) and somehow this is supposed to be effective at stopping spam.

In addition unless there is significant financial cost for certificates and/or signifcant and enforceable financial penalty and good identification and registration procedures enforced by the CAs it wouldn't even slow spammers who would just get a cert, spam, get revoked, get another cert and repeat.

Certificate revocation is already a weak point of PKI technology, and to reasonably stop spam before the spammer manages to send too many millions of spams with a cert, you have to revoke the cert PDQ!

And finally it all ends up being no more than an expensive implementation of blacklists (or I suppose more properly whitelists), because the CAs are maintaining lists of people who have not yet been revoked as spammers. Some click through agreement isn't going to stop spammers. Legislation or legal or financial threat is going to stop spammers either because any level of registration time identity verification that is plausibly going to be accepted by users, and this is also limited by the cost -- higher assurance is more cost which users also won't be willing to accept -- will be too easy for the spammers to fake. And email is international and laws are not.

It is pretty much an "internet drivers license" for email.

I also think that fully distributed systems such as hashcash are more suitable for a global internet service. My preferred method for deploying hashcash is as a token exempting it's sender from bayesian filtering, and any other content based or sender based filtering.

That way as an email user you have an incentive to install a hashcash plugin http://www.cypherspace.org/hashcash/ because it will ensure your mail does not get deleted by ever-more aggressive filtering and scattergun blackhole systems. The camram system
http://www.camram.org/ is a variant of this.

It also more directly addresses the problem: it makes it more expensive for spammers to send the volumes of mail they need to to break even.

Adam

On Fri, May 09, 2003 at 03:50:02AM +0200, Nomen Nescio wrote:
> Lauren Weinstein, founder of People for Internet Responsibility, has
> come out with a new spam solution at http://www.pfir.org/tripoli-overview.
>
> According to this proposal, the Internet email architecture would be
> revamped. Each piece of mail would include a PIT, a Payload Identity
> Token, emphasis on Identity. This would be a token certifying that you
> were an Authorized Email User as judged by the authorities. Based on
> your PIT, the receiving email software could decide to reject your
> email.
>
> It is anticipated that all Pits considered acceptable by the vast
> majority of all Tripoli-compliant software user would be digitally
> signed by one or more designated, trustworthy, third-pary authorities
> who would be delegated the power to certify the validity of identity
> and other relevant information within Pits.
>
> In other words, here comes Verisign again.
>
> It is anticipated that in most cases, in order for the sender of an
> e-mail message to become initially certified by a Pit Certification
> Authority (PCA), the sender would need to first formally accept
> Terms of Service (ToS) that may well prohibit the sending of spam,
> and equally importantly, would authorize the certification authority
> to "downgrade" the sender's authentication certification in the case
> of spam or other ToS violations.
>
> Thus you have to be politically acceptable to the Powers That Be in
> order to receive your license to email, aka your PIT. And be careful
> what you say or your PIT will be downgraded.
>
> Unfortunately he doesn't discuss various crypto protocol issues:
>
> If the PIT is just a datum, what keeps someone from stealing your PIT
> and spams with it?
>
> If the PIT is a cert on a key, what do you sign? The message? What if
> it gets munged in transit, as messages do? You've just lost most of
> your email reliability.
>
> Or maybe you sign the current date/time? Then delayed mail is dead mail.
>
> Or maybe you respond to a challenge and sign that? That won't work if
> relays are involved, because they can't sign for you.
>
> Spam is a problem, but it's no excuse to add more centralized
> administrative control to the Internet. Far better to go with a
> decentralized solution like camram.sourceforge.net, basically a matter
> of looking for hashcash in the mail headers. This raises the cost to
> spammers without significantly impacting normal users.
>

blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)

Date: Fri, 09 May 2003 23:35:36 -0600
To: Adam Back <adam@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>, cypherpunks@xxxxxxxx, cryptography@xxxxxxxx, lauren@xxxxxxxx, Adam Back <adam@xxxxxxxx>

Currently ISPs typically "notice" when they get complaints. ISPs could do a much better job of actively noticing and limiting mail at ingress ... as opposed to waiting for somebody to complain and canceling the account. Many of the recent statements about ISPs can't limit email at ingress dynamically are similar to the comments about not being able to filter ingress packets if their origin address didn't match the ip address of the sender (as stated in the original posting) ... per the ingress packet filtering RFC referenced in the original post.

My original post mentioned that the ISPs could then do their own effort of blacklisting (of other ISPs). Currently spam blacklists can be somewhat like vigilantes .... with the argument analogy that since vigilantly justice can make mistakes then there shouldn't be any highway patrol, FBI, and/or secret service. ISPs would be expected to filter on ingress of email from their own customers .... and even if the 10 top ISPs blacklisted other ISPs that didn't do a reasonable job of ingress filtering ... it could start to put a big dent in the spamming business, possibly cutting it from 40-80% of existing email down under 5-10%. It is sort of like stop signs and stop lights .... there are typically hundreds of more intersections than there are traffic enforcers .... however with sufficient leverage ... it can significantly improve the situation ... even if it can be proved that it can't, absolutely, 100% guarantee one hundred percent compliance.

I didn't make any statement about ISPs attempting to identify spammers when they register the account .... the original post was only with regard to ISPs doing active email ingress filtering. My ISP recognizes and bills me extra if I'm simultaneously connected multiple times ... there is a little latitude for modem hanging, my dropping the line ... but the modem not reporting it ... and my connecting on a different modem. It also does traffic load-leveling if I really try and hit it hard. If it can bill extra for simultaneous connects and traffic load leveling, it can do both packet ingress filtering and email ingress filtering.

past thread drawing the analogy that the information superhighway is something like the wild west .... w/o traffic rules, traffic signs, traffic lights, speed limits, and enforcement. start with a couple hundred people in town .... and went to millions ... and there still isn't even any rule about which side of the road people should be driving on.
http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

At 06:02 AM 5/10/2003 +0100, Adam Back wrote:
On Fri, May 09, 2003 at 10:11:52AM -0600, Anne & Lynn Wheeler wrote:
> So it is much easier for ISPs to have lists of other trusted &/or
> untrusted ISPs that they will accept email from.

Any internet user needs to be able to send mail to any other internet user. Which means the default has to be open (blacklists rather than whitelists). Then you have the blackhole lists like ORBs etc, which block domains used predominantly by spammers. But the problem is spammers don't stay in one place, they buy service from ISPs and spam flat-out until the ISP notices and cancels the account. Some ISPs are more grey -- they want to make money from spammers by providing them service, and some ISPs just don't notice or respond that quickly. The ISP can't distinguish spammers from non-spammers when they receive customer orders. The blackhole people are arbitrary vigilantes by and large, so the overall effect you might argue does reduce spam, but it also results in lost mail.

My experience was I couldn't get mail from my brother who was using btinternet, one of the largest ISPs in the UK because some idiot blackholer blackholed their dynamic IPs. Not doubt there were at some time some spammers using BTinternet as with just about any other ISP. Recently I couldn't receive mail from John Gilmore, and so it goes.

So I don't see how this is a "solution", rather it is just a broken countermeasure with scatter gun fall-out of false positives for all the other people who find themselves sharing the same ISP as spammers long enough for the blackhole people to add them.

Adam

blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)

Date: Sat, 10 May 2003 09:36:43 -0600
To: Adam Back <adam@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>, cypherpunks@xxxxxxxx, cryptography@xxxxxxxx, lauren@xxxxxxxx, Adam Back <adam@xxxxxxxx>

do you think that earthlink would automatically blacklist aol if it found incoming spam from aol? I think that earthlink would contact aol and say ... your ingress filtering doesn't seem to be working. It would only be after all attempts to understand aol's ingress filtering that earthlink might take action.

again ... it is analogous to somebody hearing about traffic lights for the first time and coming up with all the reasons why people would ignore traffic lights.

I would claim that the current issue isn't that spam exists (aka traffic violations), it is that there are billions of spams each day. and that this easily cuts the majority of it if the top ten start doing ingress mail filtering and that ingress mail filtering is orders of magnitude more efficient than other kinds of solutions.

the blacklisting isn't for the mistakes ... it is for the ISPs that obviously aren't going to follow the traffic rules.

so there are lots of kinds of tunneling. the major ISPs are already doing ingress filtering for email not coming from a recognizable customer. so tunneling actually reduces to a common vulnerability with ISPs not doing ingress email filtering (aka the tunneling issue to a ISP that isn't doing ingress email filtering is common vulnerability with a customer directly getting an email account with ISP that isn't doing ingress email filtering). So the issue comes back to ISPs that are recognized as not doing ingress email filtering.

So lets say this gets something like 80 percent of the traffic violations.

So the majority of the random traffic violations are now starting to be taken care of. There are 1) the corporations effectively operating as private ISPs, 2) compromised machines, 3) random anarchy.

So both #2 and #3 are vulnerabilities treated just the same as a real spammer getting a real account and directly doing spam. These two vulnerabilities should be caught be ingress email filtering. Real spammers caught by ISP ingress filtering, compromised machines caught by ISP ingress filtering, and hit&run anarchist caught by ingress filtering .... all appear to be a common vulnerability caught by ingress email filtering.

The issues actual reduce to a very few simple, non-complex vulnerabilities from a business process standpoint (ignoring all the technology twists and turns): 1) ISPs that do ingress email filtering and 2) ISPs that do not do ingress email filtering.

If ISPs are doing ingress email filtering .... then all the situations of known spammers, spammers masquerading enormously getting accounts, spammers compromising other machines and masquerading enormously, tunneling, etc ... all get taken care of. There are still the periodic traffic accidents where somebody might be able to do a couple hundred before getting cut .... but it probably reduces over 90 percent of the traffic.

So the remain issue is whether an ISP is following the traffic laws and doing ingress email filtering or flagrantly flaunting the law and letting millions of spam thru. This is regardless of whether it is a real public ISP ... or effectively a corporate/private ISP. The other ISPs then use blacklisting. The first line of defense is that all ISPs are to do ingress email filtering and the 2nd line of defense is that the major ISPs do blacklisting on the ISPs that obviously are flaunting the law.

The primary business issue is that majority of spam is being done for some profit .... that the cost of sending the spam is less than the expected financial return. This should address the 99 percentile.

Again, it is very simple, first line of defense is ingress email filtering. This is only a moderate extension of what the major ISPs are currently doing with regard to not accepting email from entities that are obviously not their customers, current traffic limiting business rules, etc. The second line of defense is blacklisting ISPs that aren't following the traffic rules. I claim, it actually is rather much simpler and much more effective.

So back to the obvious traffic violations. One is the compromised machines. Large proportion of the compromised machines are their because they all got hit by spamming virus. I claim, that over time if over 90 percent of spamming gets cut ... then 90 percent of the machines that get compromised by virus in spam can also get cut.

Situation is now down to large number of compromised machines each sending couple hundred emails each ... staying under the ingress filtering radar. That is orders of magnitude better than the current situation but it is starting to reduce the case to manageable traffic violations.

So this scenario gets down to providing significantly more focus on compromised machines ... and back to a recent comment about lots of vendors saying that consumers won't pay for better security ... because they have no motivation. This is somewhat the insurance industry theory of improving on severity of traffic accidents (what motivated automobile manufactury to build safer cars). My ISP currently charges me extra over the flat rate for certain behavioral activities. Violating ingress email filtering rules would be such a valid inducement. I get ingress email filtering accident insurance the premiums are based on the integrity of the machine i'm operating.

So, two simple rules .... 1) ISPs do ingress email filtering, and 2) ISPs blacklist other ISPs that flagrantly violate the ingress email filtering rules.

With a sizeable reduction in spam, there is corresponding sizeable reduction in compromised machines. However, compromised machines that do spam and hit the ISPs ingress email filtering rules, get fined. It is treated as accident and operating an unsafe vehicle. You can get accident and fine insurance .... but the premium is related to kind of machine you operate. Some inducement for consuming public to purchase safer machines. The two simple rules ... with the fines for violations then provides some inducement for consumer buying habit regarding purchasing safer machines. And it is all quite similar to policies and practices currently in place.

Payments as an answer to spam

Date: Sat, 17 May 2003 08:07:35 -0600
To: "Anton Stiglic" <astiglic@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Payments as an answer to spam
Cc: <iang@xxxxxxxx>, <cryptography@xxxxxxxx>

At 11:03 AM 5/15/2003 -0400, Anton Stiglic wrote:

PODS using something ŕ la PGP would not imply PKI, but still a centralized server as you said. Payment systems don't need a PKI, but a centralized server as you said, and also needs some kind of financial institution to bootstrap things (which is easier to do in a closed system, than in an open system like the Internet).

x9.59 standard for all elecronic payments can use digital signatures w/o PKI or certificates ... just public key registered with account and connectivity to senders financial institution. It isn't "centralized" any more than the existing payment card operation is centralized .... aka huge number of different consumer financial institutions all with their individual operation and account records. however, much of it is based on a private network interconnecting all of these financial operations that predates the existing internet ... but effectively functionally equivalent.

The existing payment card infrastructures are open in the sense thay they do have an international standard, iso8583 .... in much the same way that certificates have iso international standard. and there are numerous interconnects between the internet and these infrastructure ... witness the existing electronic commerce. It is less open than the "internet" in the sense that there are contractual, institutional, and financial obligations that are necessary to directly participate (but i believe that will tend to be always true except in the cases of toy demos). However, that isn't precluding the migration of more electronic commerce related traffic to internet-based technology in various ways. The issue isn't directly whether it is internet-related technology or non-internet related technology .... but much more of an issue whether there are explicit legal and other obligations required to participate.

x9.59 standard reference
http://www.garlic.com/~lynn/x959.html#x959
account record public key infrastructures
http://www.garlic.com/~lynn/x959.html#aads

Payments as an answer to spam (addenda)

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sat, 17 May 2003 09:21:21 -0600
To: "Anton Stiglic" <astiglic@xxxxxxxx>
Subject: Re: Payments as an answer to spam (addenda)
Cc: <iang@xxxxxxxx>, <cryptography@xxxxxxxx>

The existing payment card infrastructure (credit, debit, online stored-value, 3rd party, etc) had used a PKI-type infrastructure prior to about 1970, aka credential (in this case in the guise of a plastic physical card with varioius embossing and printing) that could be used in offline transactions, unconnected transactions.

The transition to online transactions started in the early '70s ... used an electronic end-point in the guise of magstripe added to the existing physical credential ... while they were emboddied in the same physical package, they represented totally different paradigms.

The existing PKI certificates are a return to the offline, pre-70s paradigm that the existing payment card infrastructure left long ago. The existing payment card paradigm is not only online in the sense that it checks whether the account is still valid ... but also checks real-time, aggregated information regarding whether there is sufficient funds.

OCSP for PKIs is a limiting baby step into an online world with real-time checking of whether the offline credential is still valid .... but it doesn't actually make it into the 1970s where a stale, static certificate is redundant and superfluous and there is direct access to much higher quality real-time and possibly aggregated information used for financial operations. OCSP is actually a more timely version of the paper booklets that were distributed in the 50s & 60s .... not an actual switch from a basically offline paradigm to an online paradigm.

Frequently there were were comments equating statements about redundant and superfluous certificates as being a transition to a centralized paradigm. However the issue isn't with regard to centralized/non-centralized ... which is effectively orthogonal to the issue regarding stale, static certificates .... it is an issue of offline/online (not centralized/non-centralized). There is the issue that if it is online paradigm ... it is possible to have either a centralized or a non-centralized paradigm .... which is somewhat more difficult to have such option in a purely offline paradigm.

random past posts on redundant and superfluous offline credentials for an online paradigm
http://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki6 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki7 CFP: PKI research worksho
http://www.garlic.com/~lynn/aadsm10.htm#limit Q: Where should do I put a max amount in a X.509v3 certificat e?
http://www.garlic.com/~lynn/aadsm10.htm#limit2 Q: Where should do I put a max amount in a X.509v3 certificate?
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01
http://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
http://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt

Payments as an answer to spam (addenda)

Date: Sat, 17 May 2003 17:56:52 -0600
To: Rich Salz <rsalz@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Payments as an answer to spam (addenda)
Cc: "cryptography@xxxxxxxx" <cryptography@xxxxxxxx>

At 07:17 PM 5/17/2003 -0400, Rich Salz wrote:
Curious.

A couple of years ago, we'd go around explaining that CRL's were the paper booklets, and OCSP was the Verifone terminal, giving per-transactional validity to the credentials.

I still think that makes more sense than your analogy. But then, the company I was working for back then is now gone. /r$

the description was that CRLs were an exact analogy of the paper booklet, while OCSP is a more timely version of the paper booklet; aka it is a more timely solution for an offline paradigm ... using a little bit of online technology; but not with the actual transition from an offline paradigm to an online paradigm.

theoretically, the payment system could have preserved the offline paradigm and just used the online terminal to check whether the offline credential is still valid .... however, they actually used the online capability to actually change from an offline paradigm to an online paradigm ... rather than using the online capability as sort of a kludgey crutch for continuing to prop up an offline paradigm.

Payments as an answer to spam (addenda)

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sat, 17 May 2003 18:22:18 -0600
To: Rich Salz <rsalz@xxxxxxxx>
Subject: Re: Payments as an answer to spam (addenda)
Cc: "cryptography@xxxxxxxx" <cryptography@xxxxxxxx>

At 07:17 PM 5/17/2003 -0400, Rich Salz wrote:
A couple of years ago, we'd go around explaining that CRL's were the paper booklets, and OCSP was the Verifone terminal, giving per-transactional validity to the credentials.

I still think that makes more sense than your analogy. But then, the company I was working for back then is now gone. /r$

actually, i believe that my wife and I were one of the first to use the comparison of CRLs to the paper booklets at about the same time we coined the term certificate manufacturing to distinguish the SSL infrastructure from a PKI (in conjunction with this thing that was to be called electronic commerce).

some old booklet references:
http://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
http://www.garlic.com/~lynn/aepay2.htm#position AADS NWI and XML encoded X9.59 NWI
http://www.garlic.com/~lynn/aadsm2.htm#strawm4 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#activity AADS Activity
http://www.garlic.com/~lynn/aadsm5.htm#faith faith-based security and kinds of trust
http://www.garlic.com/~lynn/aadsm5.htm#spki3 Simple PKI

misc. certificate manufacturing refs:
http://www.garlic.com/~lynn/aadsm2.htm#scale Scale (and the SRV record)
http://www.garlic.com/~lynn/aepay2.htm#cadis disaster recovery cross-posting
http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm5.htm#pkimort2 problem with the death of X.509 PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Payments as an answer to spam (addenda)

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 May 2003 06:47:13 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
Subject: Re: Payments as an answer to spam (addenda)
Cc: rsalz@xxxxxxxx, cryptography@xxxxxxxx

At 05:50 PM 5/18/2003 +1200, Peter Gutmann wrote:
So I agree with the statement that "OCSP is actually a more timely version of the paper booklets that were distributed in the 50s & 60s". A real solution to the problem would follow the online authorisation model used for financial transactions, just a straight "Accepted/Declined" response, rather than the "Maybe/Maybe not" silly-walk that OCSP does.

But the actual transformation from offline paradigm to online paradigm had nothing to do with the credential. In the credential world, there is something emboddied in the credntial that convinces the relying party to accept or reject the operation modula a currently valid/active credential (aka as previously outline, these credentials are stale, static subset copy of some master information someplace, typically kept in an account record). The transition to the online paradigm involved asking is the payment approved, nothing to do (directly) with the validity of any credential. The certification authority had up-to-date information about authentication ... but also up-to-date and aggregated information about patterns leading up to this event. The certifying authority ... instead of commenting about any credential ... providing yes/no regarding the transaction in the context of real-time and aggregated information.

In fact, to the extent that any financial institution using a certificate .... it did go thru a period of being used because of requirement by various off-the-shelf software on the internet. However, because of privacy and liability reasons they aborted the contents to just an account number for a relying-party-only certificate. However, (other than requirement to satisfy certain off-the-shelf software), it is trivial to show that such relying-party-only certificates are redundant and superfluous from a business process & flow perspective.

In general, there is almost nothing that you really want to put into some document that is going to be sprayed all over the infrastructure for everybody to examine. The original premise for X.509 was that there would be some information in the contents of the certificate, that a relying-party could take a look at for the basis of making a decision w/o requiring anything more .. like online access or previously obtained information. Given online access and/or previously obtained information (prior/previous business relationship) .... it is possible to show that stale, static information embodied in a certificate is redundant and superfluous.

random past comments on relying-party-only certificates:
http://www.garlic.com/~lynn/subpubkey.html#rpo
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#40 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000b.html#40 general questions on SSL certificates
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format standard
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#0 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2002d.html#39 PKI Implementation
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002e.html#72 Digital certificate varification
http://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias
http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?

Financial Privacy To Take The Floor

From: Lynn Wheeler
Date: 05/21/2003 06:14 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Financial Privacy To Take The Floor

http://www.banktech.com/story/enews/BNK20030519S0003
Financial Privacy To Take The Floor
Ivan Schneider
May 19, 2003

Congress has a lot of banking-related legislation on its plate. But anything that doesn't take financial privacy into consideration may get sent right back to the kitchen.

"Financial privacy, as an issue, will affect and overshadow all other legislative issues this year," said Michael Flood, senior analyst for banking in the regulatory advisory services group at KPMG LLP, during its regulatory perspectives teleconference.

The primary battleground is the Fair Credit Reporting Act, which has pre-approved credit provisions scheduled to lapse at the start of 2004. These provisions allow banks to share loan application data and credit bureau reports with their affiliates, provided that the customer has been given the chance to 'opt-out.' "If it isn't reauthorized, states can enact their own privacy legislation, which can lead to a miasma of 50 different regulations," said Flood, who likened the possible result to the situation faced by the insurance industry.
... snip ..

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Identity Theft Losses Expected to Hit $2 Trillion by 2005

From: Lynn Wheeler
Date: 05/22/2003 10:39 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Identity Theft Losses Expected to Hit $2 Trillion by 2005

http://itmanagement.earthweb.com/secu/article.php/2211101
Identity Theft Losses Expected to Hit $2 Trillion by 2005
May 22, 2003
By Sharon Gaudin

The financial damage caused by online identity theft is not only mounting, it's exploding at a growth rate of about 300 percent a year, according to Aberdeen Group, a Boston-based industry analyst firm.

Financial loss from identity theft is expected to reach $73.8 billion in the United States by the end of this year -- $221.2 billion worldwide, reports Aberdeen analysts in a study released this week.

.. snip ..
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Maybe It's Snake Oil All the Way Down

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: pgut001@xxxxxxxx (Peter Gutmann)
Cc: ericm@xxxxxxxx, iang@xxxxxxxx, bill.stewart@xxxxxxxx,
    cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
    ekr@xxxxxxxx, rsalz@xxxxxxxx, sguthery@xxxxxxxx
Subject: Re: Maybe It's Snake Oil All the Way Down
Date: Tue, 03 Jun 2003 14:46:27 -0600

On Tue, 2003-06-03 at 07:04, Peter Gutmann wrote:

That's a red herring. It happens to use X.509 as its preferred bit-bagging format for public keys, but that's about it. People use self-signed certs, certs from unknown CAs [0], etc etc, and you don't need certs at all if you don't need them, <blatant self-promotion>I've just done an RFC draft that uses shared-secret keys for mutual authentication of client and server, with no need for certificates of any kind</blatant self-promotion>, so the use of certs, and in particular a hierarchical PKI, is merely an optional extra. It's no more required in SSL than it is in SSHv2.

the pk-init draft for kerberos allows public keys .... allowing both cert & cert-less implementations

<blatant aads-promotion>

the scenario allows for public key registration in lieu of shared-secret registration. the benefit is that r/o access, divulging, sniffing, etc doesn't result in compromise (as in shared-secret)

in the token form ....
http://www.garlic.com/~lynn/x959.html#aads

the key-pair is gen'ed in the chip and never leaves the chip.

as part of 3-factor authentication
* something you have
* something you know
* something you are

the chip in the token purely provides something you have authentication ... and the digital signature done by the token is purely to prove that you have that particular token. It doesn't prove who you are, it just proves that you have a specific (extremely difficult to counterfeit) token as part of something you have authentication.

if the token is augmented with a pin/password for its correct operation, then there can be 2-factor authentication. It doesn't involve shared-secrets since the pin/password is purely between the person and the hardware token.

A business process may validate that the token is of the type requiring PIN and/or biometric for correct operation (in order to meet particular business integrity constraints).

An ecdsa digital signature authentication protocol for kerberos, radius, x9.59 for all retail financial transactions, or ssh can be identical regardless of various additional business integrity requirements.

The ecdsa digital signature authentication protocol can be ubiquitous regardless of various additional business integrity requirements.

The business process (for specific integrity requirements) then can require: sofware key-pair, hardware token key-pair, the level of integrity of the hardware token, and/or the operational characteristics of the hardware token (no-pin, pin, biometrics, etc) w/o changing the protocol.

If the protocol is independent of much of the business process integrity issue then either the business and/or the end-user may be able to have personal choice about the level of integrity required. Furthermore, the person might even have personal choice whether they need a unique token per security environment, a single token for all security environments, and/or a small number of tokens selectively applied to specific security environments

the digital signature has nothing at all to do directly with the person, it is purely related to demonstrating the possession of the token (as part of something you have authentication) and possibly the integrity level of the token.

The issue of the authentication protocol is getting the bits and bytes for transmission correct but doesn't normally say what it means ... i.e. secret, shared-secret, one-factor authentication, two-factor authentication, something you have authentication, something you know authentication, etc. ... even tho frequently the protocol is envisioned to be a specific implementation of a specific kind of authentication and trust/integrity level.

recent token discussions
http://www.garlic.com/~lynn/2003i.html#1 two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#2 two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation

older token discussions
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002i.html#65 privileged IDs and non-privileged IDs
http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government

</blatent aads promotion>

Microsoft Ties Security to Verisign

From: Lynn Wheeler
Date: 06/03/2003 04:24 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Microsoft Ties Security to Verisign

http://www.internetnews.com/ent-news/article.php/2216571

June 3, 2003
Microsoft Ties Security to VeriSign, Certifications
By Thor Olavsrud and Mark Berniker

Microsoft Ties Security to VeriSign, Certifications By Thor Olavsrud and Mark Berniker Microsoft (Quote, Company Info) moved to bolster its code-securing effort called Trustworthy Computing Initiative by announcing two security initiatives Tuesday. Microsoft and VeriSign said they would jointly develop improved solutions for authentication security, digital rights management (DRM) and other online security enhancements. Financial terms of the deal were not disclosed.

.. snip ..
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

OASIS and RosettaNet Set Standards Alliance

From: Lynn Wheeler
Date: 06/03/2003 04:26 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: OASIS and RosettaNet Set Standards Alliance

http://www.internetnews.com/dev-news/article.php/2216641

June 3, 2003
OASIS and RosettaNet Set Standards Alliance
By Michael Singer

Cementing their casual relationship, industry standards consortia, OASIS (Organization for the Advancement of Structured Information Standards) and RosettaNet Tuesday said they are now working in tangent to streamline Web services (define) specifications for supply chain companies. The groups actively participate in the technical work of the other but say the partnership (dubbed the "Standards Development-to-Implementation Alliance") is a chance to advance e-business standards without having to do double the work.

... snip ...
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Maybe It's Snake Oil All the Way Down

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

Date: Tue, 03 Jun 2003 17:29:44 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: pgut001@xxxxxxxx (Peter Gutmann),
    bill.stewart@xxxxxxxx, cryptography@xxxxxxxx,
    cypherpunks@xxxxxxxx, ekr@xxxxxxxx, rsalz@xxxxxxxx,
    sguthery@xxxxxxxx

At 03:04 PM 6/3/2003 -0700, James A. Donald wrote:

I never figured out how to use a certificate to authenticate a client to a web server, how to make a web form available to one client and not another. Where do I start?

What I and everyone else does is use a shared-secret, a password stored on the server, whereby the otherwise anonymous client gets authenticated, then gets an ephemeral cookie identifying him.. I cannot seem to find any how-tos or examples for anything better, whether for IIS or apache.

As a result we each have a large number of shared-secret passwords, whereby we each log into a large number of webservers. Was this what the people who created this protocol intended?

The issue is where does the authentication material come from.

<blatant aads promotion>

Basically, certificates were solution targeted for offline email from the early '80s. you dial-up, connect, exchange email, hang-up. then you read. some random person that you never, ever dealt with before sends you something; they claim to be somebody .... the certificate is signed by somebody you trust .... and is offered as proof that they are who they claim to be.

the other approach in the online world &/or with previous relations, is to have a directly accessable table of authentication material (passwords, pins, public keys). the payment (debit/credit) card world went from non-electronic, offline to electronic and online (and skipped the step altogether that certificates represent ... the electornic and offline).

note that even the certificate-based infrastructure are dependent on this method .... basically the certificate-enabled infrastructures everybody has a local table of "CA" public keys (i.e. those public keys that they've previously decided to trust) ... then certificates are validated with "CA" public keys (from their local table) and the current message/document is validated with public key from certificate. The primary difference between cert-based infrastructure and certless-based infrastructure is that in the cert-based infrastructure,, the CAs have their database of all public keys and create these small R/O, stale, static copies of their database records (called certificates) and spray them all over for use in offline environments. Then relying parties just have abbreviated CA-only public key tables and supposedly can't access the full tables maintained at the CAs.

In the certless-based infrastructure the relying parties either maintain their own full tables of all public keys and/or have direct online access to the full tables. There is no need for these little R/O, stale, static, redundant and superfluous copies of somebody else's offline database entry (called certificates) since there can be direct, online access to the original copy.

the generalized case can be hooking a web server to either radius or kerberos for handling the authentication process. both radius and kerberos support shared-secrets recorded in authentication database (potentially along with various authorization material).

radius recording public key in lieu of shared-secret and performing ecdsa digital signature authentication. pkinit for kerberos also allows for public key recorded in lieu of shared-secret with digital signature authentication (not that radius can determine authentication method, authentication material, and authorization on an account by account basis).

misc. radius public key authentication posts
http://www.garlic.com/~lynn/subpubkey.html#radius
misc. kerberos public key authentication posts
http://www.garlic.com/~lynn/subpubkey.html#kerberos
futher discussion specifically regarding stale, static, redundant, superfluous certificates.
http://www.garlic.com/~lynn/subpubkey.html#rpo

slightly related discussions regarding SSL merchant comfort certificates:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

</blatant aads promotion>

Maybe It's Snake Oil All the Way Down

Date: Tue, 03 Jun 2003 20:49:48 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: pgut001@xxxxxxxx (Peter Gutmann),
    bill.stewart@xxxxxxxx, cryptography@xxxxxxxx,
    cypherpunks@xxxxxxxx, ekr@xxxxxxxx, rsalz@xxxxxxxx,
    sguthery@xxxxxxxx

some generic reasons for hooking radius (or one of the AAA technologies) into your webserver for authentication are:

1) supports a variety of authentication mechanisms on an account by account basis. day one, none of the users actually need to see any difference (single administrative interface supporting all the client authentication options that might be in use). existing userid/password, challenge/response and in the referenced asuretee url, ecdsa digital signature.

2) single administrative interface for both client authentication options as well as all of their authorization and privilege options.

3) client database is accessable in real-time by the webserver, real-time updates can occur to both authentication information as well as authorization, permission and privilege information using single consistent administrative operation

4) there is no disconnect between client administration and stale, stale, redundant and superfluous certificates that are a subset of a r/o administrative database entry. (RADIUS) Updates can take place in real time and immediately reflected. The certificate story (as mentioned previously, created for offline, disconnected environment) basically would do something like a) invalidate the old certificate, b) issue new CRLs, c) possibly update a OCSP LDAP, d) update the master database permissions entry for that client, e) generate a certificate that represents a subset of the master information, f) distribute it to the client and g) then have the client install the new certificate. This of course becomes unnecessary if the certificate doesn't actually contain any information and the webserver accesses the authorization and permissions from an online database. However, as has repeatedly been pointed out before, if the certificate doesn't contain any information and the webserver is accessing an online database for authorizations and permissions ... then the webserver can access the online database for the authentication material also. The certificate then is stale, static, redundant and superfluous and you are back to a single online, real-time comprehensive administrative facility (like radius) that supports client/account specifics for authentication, authorization, permissions, accounting, privileges, etc.

Maybe It's Snake Oil All the Way Down

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 04 Jun 2003 10:12:04 -0600
To: "Dave Howe" <DaveHowe@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: "Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
    "Email List: Cryptography" <cryptography@xxxxxxxx>

At 12:02 PM 6/4/2003 +0100, Dave Howe wrote:
For that matter, our system here discards the CC after use (the pre-auth step with the merchant bank agent gives us back a "fulfillment handle" that can only be used to fulfill or cancel that individual transaction - but of course Amazon want to keep your CC details so they can do their fast-checkout patented thingy.

the ground rules given the x9a10 working group for the x9.59 standard was to preserve the integrity of the financial infrastructure for all electronic retail payments (credit, debit, stored-value, POS, internet, non-internet, aka ALL). it was one of the things that led us down the path of certless operation. We had previously done the work on the original payment gateway and had to perform various kinds of due diligence on all the major CA vendors .... which started to dawn on us that stale, static certificates were actually redundant and superfluous in the financial business process.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

sort of the next clinker was starting to do operational and performance profile on any of the existing payment networks .... and it was evident that there was a huge mismatch between the existing payment transaction payload size and any of the commonly used certificates (even the drastically simplified replying-party-only certificates carrying only an account number and public key).

Two major characteristics of X9.59 was that it would provide 1) end-to-end authentication (aka the consumers financial institution would be the one responsible for performing authentication) and 2) account numbers used in X9.59 transactions could not be used in unauthenticated transactions.

Some of the '90s digitally signature oriented specifications had authentication occurring at the internet boundary and stripping off the certificate (avoiding the extreme certificate payload penalty in the payment network). The downside was that the party performing the authentication didn't necessarily have the consumer's interest in mind and Visa subsequently presented statistics at a ISO standards meeting on the number of transactions flowing through the network 1) with a flag claiming to have been digitally signature authenticated and 2) they could prove that no digital signature technology was ever involved.

Evesdropping, sniffing or harvesting account numbers in the current infrastructure (at any point in the process, by insiders or outsiders, traditionally financial exploits have been 90 percent insiders) can result in fraudulent transactions. As a result, existing account numbers effectively become a form of shared-secret and need to be protected. With the X9.59 business rule requiring the account number to only be used in authenticated transactions, simple harvesting of a X9.59 account number doesn't result in fraud. Issuing financial institutions then can use existing business processes that support mapping of different account numbers to the same account. A discussion of the security proportional to risk with regard to credit card transactions:
http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe?

The issue with the use of SSL for protecting credit card transactions isn't addressing all or even the major vulnerability to the infrastructure. Eliminating the account number as a form of shared-secret addresses all of the vulnerabilities, not just the transaction-in-flight vulnerability addressed by SSL. As a byproduct of addressing all of the shared-secret related vulnerabilities, it also eliminates the need to use SSL for protecting the shared-secret while being transmitted.

Detailed report of its use in the NACHA debit network trials can be found at
http://internetcouncil.nacha.org/News/news.html
scroll down to "July 23, 2001: Digital Signatures Can Secure ATM Card Payments"

More details of X9.59 standard:
http://www.garlic.com/~lynn/x959.html#x959

Maybe It's Snake Oil All the Way Down

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 04 Jun 2003 20:58:47 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: "Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
    "Email List: Cryptography" <cryptography@xxxxxxxx>

At 04:25 PM 6/4/2003 -0700, James A. Donald wrote:
Everyone in America has several shared-secrets identifying them -- the number of the beast to identify them to the state, and their credit card numbers identifying them to various financial institutions, plus a hundred passwords to login to their email, their bank, their network provider, e-gold, etc.

The PKI idea was that we would instead use PK in place of shared-secrets, but if an ordinary person had a private key, what could he use it for?

The spam that seeks to get us to login to e-g0ld and the BankOf4merica.com works because the logins are based on shared-secrets, not private keys, and the networks are setup to rely on shared-secrets because there is no practical alternative.

one could claim that public-key is a practical alternative but it got significantly sidetracked with independent business model that wanted to extract huge amount of money out of existing infrastructures (say totally brand new independent operations wanting $100/annum for every person, extracted from the existing infrastructure for no significant positive benefit ... aka say 200m people at @$100/annum is $20b/annum ... in return for some abstract bit vapor that doesn't change any core business issue).

it is relatively trivial to demonstrate that public keys can be registered in every business process that currently registers shared-secrets (pins, passwords, radius, kerberos, etc, etc). the issue then becomes one of cost to change/upgrade those infrastructures to support digital signature authentication with the stored public keys in lieu of string comparison (no new business operations, no new significant transfer of wealth to brand new outside business entities, etc).

however, think about even these simple economics for a minute .... even for relatively modest technology changes that don't change any of the business processes/relationships ... it still costs some money ... and the beneficiary isn't the institution, it is the individual. The individual has the paradigm changed from hundreds of shared-secrets to a single key-pair ... however each institution continues to see just as many individuals and account records. From a very practical standpoint ... entities don't frequently fund things that they don't benefit from ... and typically most success is achieved when the entity that benefits from the change is also driving/funding the change.

the issue is to find out how the individual pays for the change .... or figure out how the institutions are going to benefit.

--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Maybe It's Snake Oil All the Way Down

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: EKR <ekr@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Date: Fri, 06 Jun 2003 13:34:41 -0600
Cc: "James A. Donald" <jamesd@xxxxxxxx>,
    pgut001@xxxxxxxx (Peter Gutmann),
    bill.stewart@xxxxxxxx, cryptography@xxxxxxxx,
    cypherpunks@xxxxxxxx, rsalz@xxxxxxxx,
    sguthery@xxxxxxxx

At 04:42 PM 6/4/2003 -0700, Eric Rescorla wrote:
Nonsense. One can simply cache the certificate, exactly as one does with SSH. In fact, Mozilla at least does exactly this if you tell it to. The reason that this is uncommon is because the environments where HTTPS is used are generally spontaneous and therefore certificate caching is less useful.

there are actually two scenarios .... one is to pre-cache it (so that its transmission never actually has to happen) and the other is to compress to zero bytes. detailed discussion of certificate pre-caching and certificate zero byte compression:
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2

the typical use for HTTPS for e-commerce is to hide the account number on its way to the financial institution. for the most part, the merchant is primarily interested in the response from the consumer's financial institution on whether or not the merchant gets paid. If it weren't for the associated business processes, the merchant could get by with never knowing anything at all about the consumer (the merchant just passes the account number on ... and gets back what they are really interested in .... the notification from the bank that they will get paid).

So a HTTPS type solution is that the consumer pre-caches their bank's certificate (when they establish a bank account). .... and they transmit the account number "hidden" using the bank's public key. This happens to pass thru the merchants processing .... but for purposes of the authorization, the merchant never really has to see it. The protocol would require minor issues of replay attacks .... and be able to be done in a single round trip .... w/o all the SSL protocol chatter. Actually, is isn't so much pre-caching their bank's certificate .... as loading their bank's public key into a table .... analogous to the way CA public keys are loading into tables (aka using out-of-band processing .... the convention that they may be self-signed and encoded in a certificate format is an anomoly of available software and in no way implies a PKI). The primary purpose of HTTPS hasn't been to have a secure channel with the merchant, the primary purpose of the HTTPS is to try and hide the consumer's account number as it makes its way to the consumer's financial institution.

The other solution is the X9.59 standard (preserve the integrity of the financial infrastructure for all electronic retail payments, not just internet, not just POS, not just credit, ALL; credit, debit, stored value, etc) that creates authenticated transactions and account numbers that can only be used in authenticated transaction. The consumer's public key is registered in their bank account (out of band process, again no PKI). X9.59 transactions are signed and transmitted. Since the account number can only be used in authenticated transactions .... it changes from needing encryption to hide the value as part of a shared-secret paradigm to purely a paradigm that supports integrity and authentication. As in the above, scenario, the merchant passes the value thru on its way to the consumer's financial institution; and is focused on getting the approved/disapproved answer back about whether they will be paid. As in the bank HTTPS scenario where the bank's pubilc key is pre-cached at the consumer, the consumer's public key is pre-cached at the bank .... involves no PKI business processes (although there may be some similarities that the transport of the public key involves encoding in a certificate defined format). misc. x9.59 refs:
http://www.garlic.com/~lynn/x959.html#x959

Both pre-caching solutions are between the business entities that are directly involved; the consumer and the consumer's financial institution based on having an established business relationship.

The invention of PKI was primarily to address the issue of an event between two parties that had no prior business relationship and possibly weren't going to have any future business relationship and that they would conclude their business relying on some mutual trust in the integrity of a 3rd party w/o actually having to resort to an online environment. The e-commerce scenario is that there is real-time, online transaction with the trusted 3rd party (the consumer's financial institution) involving prior business relationship. This negates the basic original assumptions about the environment that PKIs are targeted at addressing.

Maybe It's Snake Oil All the Way Down

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 06 Jun 2003 17:45:35 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
        "Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
        "Email List: Cryptography" <cryptography@xxxxxxxx>

At 04:24 PM 6/6/2003 -0700, James A. Donald wrote:
I don't think so.

??? public key registered in place of shared-secret?

NACHA debit trials using digitally signed transactions did it with both software keys as well as hardware tokens.
http://internetcouncil.nacha.org/News/news.html
in the above scroll down to July 23, 2001 ... has pointer to detailed report?

X9.59 straight forward establishes it as standard .... with some activity moving on to ISO
http://www.garlic.com/~lynn/x959.html#x959

pk-init draft for kerberos specifies that public key can be registered in place of shared-secret.

various radius implementations have been done be a number of people.

in all of these cases, there is no change in the business process and/or business relationship .... doesn't introduce totally unrelated parties to the business activities. there is digital signing on the senders side (actually a subset of existing PKI technology) and digital signature verification on the receivers side (again a subset of existing PKI technology). To the extent that there is impact on existing business process ... it is like in the case of introducing x9.59 authentication for credit transactions that have relatively little authentication currently .... and as a result would eliminate major portion of the existing credit card transaction related fraud.

The big issue isn't the availability of the technology ... although there is a slight nit in the asuretee case being FIPS186-2, ecdsa .... and having support in CAPI and related infrastructures. It not working (easily) is like when my wife and I were doing the original payment gateway .... with this little client/server startup in menlo park (later moved to mountain view and have since been bought by AOL) and people saying that SSL didn't exist ... misc ref from the past
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

An attack on paypal

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

Date: Sun, 08 Jun 2003 18:12:34 -0600
To: "Dave Howe" <DaveHowe@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: "James A. Donald" <jamesd@xxxxxxxx>,
    "Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
    "Email List: Cryptography" <cryptography@xxxxxxxx>

At 11:43 PM 6/8/2003 +0100, Dave Howe wrote:
HTTPS works just fine. The problem is - people are broken. At the very least, verisign should say "ok so '..go1d..' is a valid server address, but doesn't it look suspiously similar to this '..gold..' site over here?" for https://pseudo-gold-site/ - but really, if users are going to fill in random webforms sent by email, they aren't going to be safe under any circumstances; the thing could send by unsecured http to any site on the planet, then redirect to the real gold site for a generic "transaction completed" or even "failed" screen A world where a random paypal hack like this one doesn't work is the same as the world where there is no point sending out a Nigerian as you will never make a penny on it - and yet, Nigerian is still profitable for the con artists.

in a world where there are repeated human mistakes/failures .... at some point it is recognized that people aren't perfect and the design is changed to accommodate peoples foibles. in some respects that is what helmets, seat belts, and air bags have been about.

in the past systems have designed long, complicated passwords that are hard to remember and must be changed every month. that almost worked when i person had to deal with a single shared-secret. when it became a fact of life that a person might have tens of such different interfaces it became impossible. It wasn't the fault of any specific institution, it was a failure of humans being able to deal with large numbers of extremely complex, frequently changing passwords. Because of known human foibles, it might be a good idea to start shifting from an infrastructure with large numbers of shared-secrets to a non-shared-secret paradigm.

at a recent cybersecurity conference, somebody made the statement that (of the current outsider, internet exploits, approximately 1/3rd are buffer overflows, 1/3rd are network traffic containing virus that infects a machine because of automatic scripting, and 1/3 are social engineering (convince somebody to divulge information). As far as I know, evesdropping on network traffic doesn't even show as a blip on the radar screen.

In the following thread on a financial authentication white paper:
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper

there is point made that X9.59 standard doesn't directly address the Privacy aspect of security (i.e. no encryption or hiding of data). However, the point is made that it changes the paradigm so that the financial account number no longer represents a shared-secret and that it can be supported with two-factor authentication i.e. something you have token and something you know PIN. The something you know PIN is used to enable the token, but is not a shared-secret. Furthermore, strong authentication can be justification for eliminating the need for name or other identification information in the transaction.

However, if X9.59 strong authentication is used with two-factor authentication and no identification information is necessary .... then it would make people more suspicious if privacy information was requested. Also, since privacy information is no longer sufficient for performing a fraudulent transaction, it might mitigate that kind of social engineering attack.

The types of social engineering attacks then become convincing people to insert their hardware token and do really questionable things or mailing somebody their existing hardware token along with the valid pin (possibly as part of an exchange for replacement). The cost/benefit ratio does start to change since there is now much more work on the crooks part for the same or less gain. One could also claim that such activities are just part of child-proofing the environment (even for adults). On the other hand, it could be taken as analogous to designing systems to handle observed failure modes (even when the failures are human and not hardware or software). Misc. identify theft and credit card fraud reference:
http://web.archive.org/web/20021017091112/http://www.consumer.gov/idtheft/cases.htm
http://www.usdoj.gov/criminal/fraud/idtheft.html
http://www.garlic.com/~lynn/aadsm14.htm#22 Identity Theft Losses Expect to hit $2 trillion
http://www.garlic.com/~lynn/subintegrity.html#fraud

Slightly related in recent thread that brought up buffer overflow exploits
http://www.garlic.com/~lynn/2003j.html#4 A Dark Day

and the report that multics hasn't ever had a buffer overflow exploit
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation

somebody (else) commented (in the thread) that anybody that currently (still) writes code resulting in buffer overflow exploit maybe should be thrown in jail.

An attack on paypal

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

Date: Sun, 08 Jun 2003 20:00:40 -0600
To: "Dave Howe" <DaveHowe@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: "Anne & Lynn Wheeler" <lynn@xxxxxxxx>,
    "James A. Donald" <jamesd@xxxxxxxx>,
    "Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
    "Email List: Cryptography" <cryptography@xxxxxxxx>

At 02:09 AM 6/9/2003 +0100, Dave Howe wrote:
The problem is here, we are blaming the protective device for not being able to protect against the deliberate use of an attack that bypasses, not challenges it - by exploiting the gullibility or tendency to take the path of least resistance of the user. The real weakness in HTTPS is the tendency of certificates signed by Big Name CAs to be automagically trusted - even if you have never visited that site before. yes, you can fix this almost immediately by untrusting the root certificate - but then you have to manually verify each and every site at least once, and possibly every time if you don't mark the cert as "trusted" for future reference.

that is why we coined the term merchant "comfort" certificates some time ago. my wife and I having done early work for payment gateway with small client/server startup in menlo park ... that had this thing called SSL/HTTPS ... and then having to perform due diligence on the major issuers of certificates .... we recognized 1) vulnerabilities in the certificate process and 2) information hiding of transaction in flight only addressed a very small portion of the vulnerabilities and exploits.

lots of past discussions related to our use of merchant comfort certificate term:
http://www.garlic.com/~lynn/subpubkey.html#sslcert

we concluded that a real issue is that way too much of the infrastructure is based on shared-secrets and there was no realistic way of providing blanket protection to all the exposures and vulnerabilities of such shared-secret infrastructures. somewhat related discussion in the security proportional to risk posting:
http://www.garlic.com/~lynn/2001h.html#61

so rather than trying to create a very thick blanket of encryption covering the whole planet .... a synergistic approach was attempting to provide alternatives to as much of the shared-secret paradigm as possible. As in the referenced post:
http://www.garlic.com/~lynn/aepay11.htm#53 authentication white paper

strong encryption of identification and privacy (and shared-secret) information is good ... but not having identification, privacy and shared-secret information is even better.

there are all sorts of ways of obtaining shared-secret information (and/or privacy and identification information prelude to identity theft) .... including various kinds of social engineering.

as previously mentioned requirement for X9.59 standard was to preserve the integrity of the financial infrastructure for ALL electronic retail payments. As per previous notes, X9.59 with strong authentication eliminates the account number as a shared-secret as well as eliminating requirements for name, address, zip-code, etc as part of any credit card authentication process (strong encryption of vulnerable information is good, not having vulnerable information at all is even better).

ALL in addition to referring to things like credit cards, debit cards, atm transactions, stored-value transaction, over the internet, at point-of-sale, face-to-face, automated machines, etc .... also refers to ACH transactions. ACH information allows for unauthenticated push or pull transactions. Social engineering requesting bank account information so somebody can push tens of millions into your account also allows for them to generate a pull transaction removing all the money from your account. Part of the above posting on the authentication white paper .... makes references to securing ACH transactions:
http://web.archive.org/web/20030816180523/http://www.asuretee.com/company/releases/030513_hagenuk.shtm

virus attack on banks (was attack on paypal)

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 10 Jun 2003 09:19:19 -0600
To: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: virus attack on banks (was attack on paypal)
Cc: "Dave Howe" <DaveHowe@xxxxxxxx>,
        "James A. Donald" <jamesd@xxxxxxxx>,
        "Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
        "Email List: Cryptography" <cryptography@xxxxxxxx>

At 06:12 PM 6/8/2003 -0600, Anne & Lynn Wheeler wrote:
at a recent cybersecurity conference, somebody made the statement that (of the current outsider, internet exploits, approximately 1/3rd are buffer overflows, 1/3rd are network traffic containing virus that infects a machine because of automatic scripting, and 1/3 are social engineering (convince somebody to divulge information). As far as I know, evesdropping on network traffic doesn't even show as a blip on the radar screen.

virus attempting to harvest (shared-secret, single-factor) passwords at financial institutions
http://www.smh.com.au/articles/2003/06/10/1055010959747.html

and somewhat related:
http://www.garlic.com/~lynn/aepay11.htm#53 authentication white paper

The real problem that https has conspicuously failed to fix

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