X9.59 mailing list

x959 Postings and Posting Index, next, previous - home



identity, fingerprint, from comp.risks
Sun releases Liberty-enabled software
Sun releases Liberty-enabled software
Ministers to Act on Rise in Identity Theft
misc. IETF e-commerce announcements (from IOTP working group)
Self-Regulating SSL Certificate Authority
A Look into Banking Trends for 2003
FTC says incidence of ID theft jumped in 2002
Internet Consumer Fraud Continues to Rise
Bank of America ATMs Disrupted by Virus
E-Commerce Standard Plans Made Public
Bank of America ATMs Disrupted by Virus
Star study: Identity Theft In The United States: An Update
Microsoft Fixes Passport to Meet EU Privacy Rules
More Identity Theft ... Security Stands in Line Behind Other Priorities
NIST recommends dual biometrics for visas
E-Authentication gateway draws interest outside of e-gov projects
Criminals using high-tech methods for old-style crimes
Hacker accesses 2.2 million credit cards
Japan seeks smarter ideas for smart cards
XACML Access Control Markup Language Ratified as OASIS Open Standard
Solving the problem of micropayments
FBI Probing Theft of 8 Million Credit Card Numbers
DOD Prepares for biometric embedded smart card pilot
Motorola goes with USB On-the-Go
CMS sets health care e-payment standards
CMS sets health care e-payment standards
Solving the problem of micropayments
Solving the problem of micropayments
CIOs Must Be Involved In Controlling Risk In Financial Services
Iris recognition helps to prevent ID fraud
Privacy again a hot-button issue for legistlators
Don't-Ask-Don't-Tell E-commerce
Spam's Being Used For Identity Theft And Blackmail, Symantec Says
Recent IOTP and ECML publications
X9/03 LB#8 - Formation of a New Subcommittee - X9C
Amazon/Bezos: web advertising patent
Who's afraid of Mallory Wolf?
Card Technology Forecast: 2004-2009
related to electronic contracting (new X9C group)
ID theft costs banks $1 billion a year
Be Prepared: Gartner Outlines Top Security Risks
Bank Float May Sink
Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)
First Data buying Concord EFS
Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)
Bank of America's Trade Finance Strategy
Actual Losses To Identity Fraud Top $1 Billion
Blackboard Gets Gag Order Against Smart-Card Hackers
A More Anonymous Internet
Concern Grows About ID Theft
Nokia, MasterCard test wireless payment
Visa, Philips team to promote 'contactless' credit card
Authentication white paper
FINREAD was. Authentication white paper
FINREAD ... and as an aside
FINREAD was. Authentication white paper
US warns banks about virus
PKI's not working
US warns banks about virus ... another ref:
PKI's not working
HIPAA, privacy, identity theft
HIPAA, privacy, identity theft (addenda)
E-merchants Turn Fraud-busters
EFTA to Adaopt ATM Ant-Fraud Measures
E-merchants Turn Fraud-busters (somewhat related)
Confusing Authentication and Identiification?
Confusing Authentication and Identiification?
Confusing Authentication and Identiification?
Confusing Authentication and Identiification?
Confusing Authentication and Identiification? (addenda)
Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
Account Numbers. Was: Confusing Authentication and Identiification? (addenda)


identity, fingerprint, from comp.risks

From: Lynn Wheeler
Date: 01/06/2003 07:32 PM
To: epay@xxxxxxxx
Subject: identity, fingerprint, from comp.risks
Date: Sun, 05 Jan 2003 01:09:40 +0000
From: Markus Kuhn <Markus.Kuhn@xxxxxxxx>
Subject: Risks of diverse identification documents

The Home Office is currently running a consultation exercise on the introduction of an identity infrastructure for Britain. This would consist of a biometric database with basic records of the entire population. Anyone in the database would be able to get an identity card, which would essentially enable the holder to grant easily read access to his or her record to any peer who needs some form of assurance about one's identity. Details on the consultation are on

http://www.homeoffice.gov.uk/dob/ecu.htm

The system proposed is nothing unusual and quite similar to what most European and many Asian countries have used successfully for several decades.

Such identity infrastructures are generally widely accepted in these countries, where most people consider them today to be a desirable and effective protection against what has become known in some countries that still lack them as "identity theft".

Nevertheless, there is fierce opposition to the proposals from various British privacy advocacy groups. Similar discussions can be observed at the moment in the US and Japan.

While much of the opposition is of a somewhat religious/tinfoil-hat nature and therefore difficult to address, some of it has been voiced by notable computer-security experts and therefore deserves some serious response.

The probably most commonly recurring theme is that the introduction of a national identity card would lead to over-reliance on a single document. The need to corrupt only the issuing procedures of a single mechanism -- so the often expressed concern -- would ultimately make identity theft easier rather than harder. This is probably based on the implicit assumption that independent identity systems perform independent checks with statistically independent failure probabilities. Therefore their security should increase exponentially with the number of verification systems and more would be better.

Defense-in-depth and its use of multiple diverse security mechanisms is in general a feature of sound security engineering. However, applying this general idea in the context of government infrastructures against identity theft this way is in my opinion horribly wrong and naive for a number of reasons, which I'd like to address very briefly.

The most obvious problem is that the UK's present alternative -- identification based on multiple documents and issuing procedures -- adds very little as none of the currently widely available documents is protected by controls of desirable strength. This is just illustrated again by recent media demonstrations on how easily it is to abuse UK birth certificates:

http://news.bbc.co.uk/1/hi/programmes/kenyon_confronts/2625395.stm

In practice, anyone wishing to verify an identity gets only the minimal protection of all the ID schemes in common use, because as soon as you break one of them, you can quite easily proliferate your fake identity into several other systems. Get a fake UK birth certificate (fairly easy) and apply with it for a fake UK drivers license (therefore also not much more difficult), use both to get a fake UK passport and all three to comfortably get fake account access, education degrees, travel documents, security clearances, etc. etc. Most of the existing systems depend on each other, which leads easily to circular verification (A thinks B knows I and B thinks A knows I). They all lack the somewhat more expensive direct checks of non-document evidence that for example a properly protected distributed add-only database of the biometric long-term history of those registered could support economically and effectively.

Multiple documents? Unfortunately, the world of fake ID documents currently works more like "Buy one, get three more free!" The number of systems doesn't count much after all.

But this is not the only reason why it is so crucial to have at least one identification scheme that is seriously difficult to break, while having more than one of these is unlikely to be worth the cost and hassle.

There is first of all also the problem that within a single infrastructure, it is far easier for those in charge of its integrity to verify and ensure that the overall policies such as the separation of duties for critical checks really leads to checks that are independent by design, and not by chance.

Another reason is that the costs for the training/equipment/time/etc. necessary for the adequate verification of security documents increases at least linearly with the number of different document types accepted. And the risk of fraudsters finding by brute-force search one accepted type of identification for which a particular verifier is not well prepared to recognize comparatively simple fakes increases even exponentially with the overall number of different identification forms accepted.

Hence I am not surprised by the desire in the UK government to finally also offer its tax payers one single simple cheap properly engineered and run identity infrastructure. It is needed to replace all the existing often ridiculously weak alternatives (including old birth certificates, old driving licenses, magstripe-cards, knowing mother's maiden name or showing a laser-printed utility bill) that are all currently used by especially the UK financial industry as acceptable means for gaining access to critical personal information and property.

Perhaps the discussion should first of all be driven by comparing actual practical identity-theft versus privacy-violation statistics in countries with and without proper government-provided identification infrastructures, instead of naively applying generic security recipes such as more-mechanisms-are-better to an application area with far more specific properties.

Markus Kuhn, Computer Lab, Univ of Cambridge, GB
http://www.cl.cam.ac.uk/~mgk25/


Sun releases Liberty-enabled software

From: Lynn Wheeler
Date: 01/13/2003 08:58 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Sun releases Liberty-enabled software
http://news.com.com/2100-1001-980266.html?tag=fd_top
... snip ...
Wells Fargo has been using the test version to handle authentication on several parts of its online banking site, Barco said. Liberty makes sure a customer signed on to the online banking system, for example, can get to the bill payment system or the brokerage system without having to log in to each one.

.. snip ...
==============

above article references liberty
http://www.projectliberty.org/home.html

being based on the security assertion markup language
http://www.oasis-open.org/committees/security/

last week i ran across somebody using SAML ... to effectively re-implement Kerberos ... but in place of kerberos tickets there were these packets of SAML formated information.

Somewhat related is the Security Services TC glossary ... which includes references to the federated/merged security glossary on the garlic web pages:
http://www.oasis-open.org/committees/security/docs/draft-sstc-hodges-glossary-01.html

slightly related Kerberos reference:
http://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos

the SAML webpage also references the AAA series of RFCs. Click on
http://www.garlic.com/~lynn/rfcietff.htm

and in the RFCs listed by section, click on Term (term->RFC#). and scroll down to:

Authentication, Authorization and Accounting
see also accounting , authentication , authorization
3127 2989 2977 2906 2905 2904 2903

Sun releases Liberty-enabled software

From: Lynn Wheeler
Date: 01/14/2003 08:00 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Sun releases Liberty-enabled software
additional articles:
http://www.computerworld.com/hardwaretopics/hardware/server/story/0,10801,77522,00.html
http://itmanagement.earthweb.com/entdev/article.php/1568391

Ministers to Act on Rise in Identity Theft

From: Lynn Wheeler
Date: 01/15/2003 06:12 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Ministers to Act on Rise in Identity Theft
http://www.timesonline.co.uk/article/0,,2087-532826,00.html
The Sunday Times - Britain

January 05, 2003
Ministers to act on huge rise in stolen identities
Jon Ungoed-Thomas and Edin Hamzic

THE identity of David Blunkett has been "stolen" by a reporter who was able to use a copy of the home secretary's birth certificate to obtain a provisional driving licence. Blunkett's name and date of birth appear on the licence.

The use of the certificate, legally obtained, to get a licence in Blunkett's name has highlighted the growing threat posed by identity fraud. The government is now planning new laws to curb the practice.

Last night, Beverley Hughes, the Home Office minister, said measures could include tighter checks on the identity of those seeking copies of birth certificates and other documents.

"If we are to protect people better from this growing threat, we would need to make more stringent checks," said Hughes.

The hijacking by conmen of victims' details, usually to obtain fake documents or steal money, has tripled in the past two years, according to new figures. Banks, building societies and financial institutions reported more than 40,000 cases of identity fraud in 2002 compared with fewer than 13,000 cases in 2000.

Conmen often create new identities by trawling through bins, collecting bills and bank statements that can be used to build up the false identity.

A birth certificate can be obtained with no requirement to prove identity. The name on the certificate can be entered on the electoral roll with no checks. Utility bills and a driving licence can then be obtained.

Henri Cash, 45, a West Sussex businessman, fell victim to a conman who ran up 30,000 pounds of debts in his name after "stealing" his identity.

"This person was allowed to use my credit history without any proper checks," said Cash.

In a BBC1 investigation to be shown on Wednesday, the journalist

Paul Kenyon, who obtained the Blunkett driving licence, also managed to get a licence and bank account in the name of Frederick Forsyth.

The Day of the Jackal, Forsyth's novel that was made into a film in 1973, featured an assassin who assumed the identity of a dead child.


misc. IETF e-commerce announcements (from IOTP working group)

From: Lynn Wheeler
Date: 01/21/2003 01:15 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: misc. IETF e-commerce announcements (from IOTP working group)
From: The IESG <iesg-secretary@xxxxxxxx>
Subject: Document Action Electronic Commerce Modeling Language (ECML) Version 2 Requirements to Informational
Date: Tue, 21 Jan 2003 133520 -0500

The IESG has approved the Internet-Draft 'Electronic Commerce Modeling Language (ECML)Version 2 Requirements' <draft-ietf-trade-ecml2-req-05.txt> as an Informational RFC. This document is the product of the Internet Open Trading Protocol Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom.

From: The IESG <iesg-secretary@xxxxxxxx>
Subject Document Action Internet Open Trading Protocol (IOTP) Version 1, Errata to Informational
Date: Tue, 21 Jan 2003 133547 -0500

The IESG has approved the Internet-Draft 'Internet Open Trading Protocol (IOTP) Version 1, Errata' <draft-ietf-trade-iotp-v1-errata-01.txt> as an Informational RFC. This document is the product of the Internet Open Trading Protocol Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom.

From: The IESG <iesg-secretary@xxxxxxxx>
Subject: Document Action Requirements and Design for Voucher Trading System (VTS) to Informational
Date: Tue, 21 Jan 2003 133421 -0500

The IESG has approved the Internet-Draft 'Requirements and Design for Voucher Trading System (VTS)' <draft-ietf-trade-drt-requirements-04.txt> as an Informational RFC. This document is the product of the Internet Open Trading Protocol Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom.


Self-Regulating SSL Certificate Authority

From: Lynn Wheeler
Date: 01/22/2003 07:13 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Self-Regulating SSL Certificate Authority
somewhat related to SSL certificate threads from last month:
http://www.garlic.com/~lynn/aepay10.htm#78
http://www.garlic.com/~lynn/aepay10.htm#79
http://www.garlic.com/~lynn/aepay10.htm#81
http://www.garlic.com/~lynn/aepay10.htm#82
http://www.garlic.com/~lynn/aepay10.htm#83

http://ask.slashdot.org/askslashdot/03/01/21/207244.shtml?tid=93
Posted by Cliff on Tuesday January 21, @05:05PM from the doing-it-on-our-own dept.

bcg asks: "It has come that time again to renew some of my SSL certificates and part with substantial amounts of cash. This has got me thinking - why should we pay large amounts of cash for authorized certs when so little is done by the companies issuing them? Sure they get you to send them a copy of a business certificate but how does this prove the character of those running the SSL server? What ideas can we come up with for a self-regulating certification authority? Could we set something up along the lines of the many free DNS servers around but use it to authenticate SSL certs?" We last touched on this subject in October, when someone was searching for cheap SSL certs. We've also discussed why certs are so expensive. Why not take it one step further and discuss ways of making and authenticating our own certs for free...or as close to free as possible?


A Look into Banking Trends for 2003

From: Lynn Wheeler
Date: 01/22/2003 08:30 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: A Look into Banking Trends for 2003

http://www.banktech.com/story/BSTeNews/BNK20030117S0002
A Look into Banking Trends for 2003
Alenka Grealish, Celent Communications
Jan 17, 2003

Heightened competition from non-banks, a persistent bearish market, and a general erosion of consumer confidence will continue to influence banks' IT decisions in 2003. In particular, Celent expects banks to step up their privacy, security, and risk management efforts. In addition, banks will tackle two daunting areas in need of an overhaul: check processing and core processing. Within retail banking, we predict that investment in multi-channel integration and customer knowledge will continue to expand and that these projects will come to fruition within the next three years. In wholesale banking, banks will further harness Internet-enabled technologies to improve customer offerings and service.

Banks will pay more attention to privacy and identity theft concerns


... snip ...

FTC says incidence of ID theft jumped in 2002

Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/22/2003 09:00 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: FTC says incidence of ID theft jumped in 2002
http://www.computerworld.com/securitytopics/security/privacy/story/0,10801,77792,00.html

FTC says incidence of ID theft jumped in 2002

By PATRICK THIBODEAU JANUARY 22, 2003

Content Type: Story Source: Computerworld

WASHINGTON -- The Federal Trade Commission today said that reported cases of identity theft increased nearly 88% last year. But some experts say the numbers may only be disclosing a fraction of the overall problem.

The FTC last year received 161,800 identity theft complaints, up from 86,200 in 2001, according to its annual report on consumer fraud.

ID theft accounted for 43% of all fraud complaints the FTC received last year, the agency said in a statement. The number of fraud complaints overall increased by nearly 73%, from 220,000 to 380,000. The cost for all fraud reached $343 million.

FTC officials said the increase may be due in part to agency efforts to encourage victims to file complaints, as well as increased participation from public and private agencies that report fraud. Those agencies include the Social Security Administration's Office of Inspector General and many Better Business Bureaus in the U.S.

But one private survey released earlier this month by Maitland, Fla.-based Star Systems, a Concord EFS Inc. subsidiary, found that one in 20 adults, or about 11.8 million people in the U.S., have been victims of identity theft. Those results came from an independent, third-party telephone survey.


... snip ...

Internet Consumer Fraud Continues to Rise

From: Lynn Wheeler
Date: 01/23/2003 05:20 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Internet Consumer Fraud Continues to Rise
http://itmanagement.earthweb.com/ecom/article.php/1573071
Internet Consumer Fraud Continues to Rise
January 22, 2003
By Roy Mark

The Internet tops the list of the Federal Trade Commission's (FTC) annual report detailing consumer complaints about identity theft and listing the top 10 fraud complaint categories reported by consumers. According to the FTC, 47 percent of non-identity theft complaints were Internet-related, a 31 percent increase since 2000.

As in 2000 and 2001, identity theft topped the list, accounting for 43 percent of the complaints lodged in the FTC's Consumer Sentinel database. The number of fraud complaints jumped from 220,000 in 2001 to 380,000 in 2002, and the dollar loss consumers attributed to the fraud they reported grew from $160 million in 2001 to $343 million in 2002.


Bank of America ATMs Disrupted by Virus

From: Lynn Wheeler
Date: 01/25/2003 06:11 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Bank of America ATMs Disrupted by Virus

http://www.washingtonpost.com/wp-dyn/articles/A43267-2003Jan25.html
Bank of America ATMs Disrupted by Virus

Saturday, January 25, 2003; 5:33 PM

SEATTLE (Reuters) - Bank of America Corp. said on Saturday that customers at a majority of its 13,000 automatic teller machines were unable to process customer transactions after a malicious computer worm nearly froze Internet traffic worldwide.

Bank of America spokeswoman Lisa Gagnon said by phone from the company's headquarters in Charlotte, North Carolina, that many, if not a majority of the No. 3 U.S. bank's ATMs were back online and that their automated banking network would recover by late Saturday.


.. snip ...

E-Commerce Standard Plans Made Public

From: Lynn Wheeler
Date: 01/28/2003 12:15 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: E-Commerce Standard Plans Made Public
http://itmanagement.earthweb.com/ecom/article.php/1575471

E-Commerce Standard Plans Made Public
January 28, 2003
By Thor Olavsrud

E-business interoperability consortium OASIS Tuesday said the first draft of a royalty-free data method for international electronic commerce has been released by one of its technical groups.

The new OASIS schemas encompass the Universal Business Language (UBL). UBL is a standard for XML (define) document formats that encode business messages, such as purchase orders and invoices. UBL treats business-to-business (B2B) communication across all industry sectors and domains for all types of organizations, including small- and medium-sized enterprises.


..snip..

Bank of America ATMs Disrupted by Virus

From: Lynn Wheeler
Date: 01/29/2003 11:21 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Bank of America ATMs Disrupted by Virus
aka
http://www.garlic.com/~lynn/aepay11.htm#9
http://www.washingtonpost.com/wp-dyn/articles/A43267-2003Jan25.html

somewhat related thread in comp.security.misc thread
http://www.garlic.com/~lynn/2003b.html#53 Microsoft worm affecting Automatic Teller Machines
http://www.garlic.com/~lynn/2003b.html#54 Microsoft worm affecting Automatic Teller Machines
http://www.garlic.com/~lynn/2003b.html#55 Microsoft worm affecting Automatic Teller Machines

Star study: Identity Theft In The United States: An Update

From: Lynn Wheeler
Date: 01/29/2003 04:46 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Star study: Identity Theft In The United States: An Update

http://www.star-systems.com/news-industryresearch.html

Microsoft Fixes Passport to Meet EU Privacy Rules

From: Lynn Wheeler
Date: 01/30/2003 08:36 AM
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Microsoft Fixes Passport to Meet EU Privacy Rules

http://story.news.yahoo.com/news?tmpl=story2&cid=569&ncid=738&e=1&u=/nm/20030130/tc_nm/tech_microsoft_eu_dc

Microsoft Fixes Passport to Meet EU Privacy Rules
1 hour, 2 minutes ago
By Lisa Jucca and Tom Miles

BRUSSELS (Reuters) - The European Commission (news - web sites) said on Thursday that software giant Microsoft had agreed to make "radical" changes to its .NET Passport system to ease concerns about data privacy posed by Internet identity systems.

The agreement settles a half-year long examination by European Union (news - web sites) privacy watchdogs into on-line authentication systems such as Passport.

"Microsoft has agreed to implement a comprehensive package of data protection measures, which will mean making substantial changes to the existing .NET passport system," the Commission said in a statement. No details were given.

Jonathan Todd, a spokesman for the European Union's executive body, said it was now unlikely that the Passport system, used to identify Internet users, would fall foul of government data protection rules in the 15-country bloc.


..snip..

More Identity Theft ... Security Stands in Line Behind Other Priorities

From: Lynn Wheeler
Date: 02/03/2003 11:09 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: More Identity Theft ... Security Stands in Line Behind Other Priorities

http://www.informationweek.com/story/IWK20030131S0001
Security Stands In Line Behind Other Priorities
Feb. 3, 2003
By George V. Hulme

What's a company to do? The Federal Trade Commission reports that identity theft is skyrocketing, and the 2002 CSI/FBI Computer Crime and Security survey places the average loss to financial fraud at $4.6 million and the average cost of a virus attack at $283,000. For the most part, short-sighted priorities get in the way of effective security efforts.

Half of the business-technology executives in Gartner's U.S. Security Services 2002 survey report that other projects take precedence over IT security. When IT security is a low priority, those charged with establishing and enforcing its policies lose leverage, and security managers aren't able to convince budget holders to pay for the cost of security products.


..snip..

NIST recommends dual biometrics for visas

From: Lynn Wheeler
Date: 02/12/2003 03:14 PM
To: epay@xxxxxxxx
Subject: NIST recommends dual biometrics for visas

http://www.washingtontechnology.com/news/1_1/daily_news/20069-1.html
http://www.gcn.com/vol1_no1/daily-updates/21141-1.html

02/12/03
NIST recommends dual biometrics for visas
By Kevin McCaney
GCN Staff

The National Institute of Standards and Technology is recommending a dual biometric system of fingerprint and facial recognition, possibly stored on smart cards, to identify visa holders at the nation’s borders.

"With two fingerprints and a face, you’d have quite a secure system," said Charles Wilson, manager of the Imaging Group in NIST’s Information Technology Laboratory.

NIST delivered its recommendations in a report to Congress after conducting a study last year as mandated by the USA Patriot Act of 2001 and the Enhanced Border Security and Visa Entry Reform Act of 2002.

The report recommended placing two fingerprints on each card "noting that thumbs produce the highest accuracy rates, followed by the index and middle fingers" combined with facial scanning. NIST said each image, whether of a fingerprint or face, would take up 10K or less of storage, for a total within the capacity of many smart cards.


... snip ...

E-Authentication gateway draws interest outside of e-gov projects

From: Lynn Wheeler
Date: 02/12/2003 03:17 PM
To: epay@xxxxxxxx
Subject: E-Authentication gateway draws interest outside of e-gov projects

http://www.gcn.com/vol1_no1/daily-updates/21143-1.html

2/12/03
E-Authentication gateway draws interest outside of e-gov projects
By Jason Miller
GCN Staff

While the E-Authentication project, considered a main cog in the e-government wheel, is having trouble getting funds from partner agencies, IT leaders outside of the 24 Quicksilver projects are clamoring to use the gateway. But those project leaders might have to wait because funding problems have pushed back the timetable for a full launch of the system.

Adrian Fish, deputy project manager for E-Authentication, yesterday said agency partners have been slow to pony up funding for the gateway because some agencies haven’t realized the benefits.

"We have been working with our partner agencies so they see the value of the gateway. But I think as they see applications come on and the money [the gateway] is saving them, the value is being demonstrated," she said. "We are going back to drawing board to try to get more money from partner agencies."

Agencies requested $8.1 million for E-Authentication in the fiscal 2004 budget the administration submitted to Capitol Hill last week. That is down from the $12.1 million agencies requested in 2003.

While some E-Authentication partners are reticent, other government project leaders have been keeping her phone busy with interest in the gateway, Fish said.


.. snip ...

Criminals using high-tech methods for old-style crimes

From: Lynn Wheeler
Date: 02/14/2003 08:56 AM
To: epay@xxxxxxxx
Subject: Criminals using high-tech methods for old-style crimes
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,78531,00.html

Criminals using high-tech methods for old-style crimes

By DAN VERTON
FEBRUARY 13, 2003

MASHANTUCKET, Conn. -- Organized crime rings that employ people with violent criminal records are increasingly trading their automatic weapons for automatic software tools that enable them to conduct a wide array of white-collar crimes such as identity theft and fraud.

As many as 700,000 people fall victim to identity theft and other forms of Internet fraud every year, but vast differences among the methods and perpetrators of such crimes can make investigating them difficult, said James Doyle, president of Madison, Conn.-based Internet Crimes Inc. Doyle, a co-founder of the New York Police Department's Computer Investigation and Technology Unit, spoke at the Cybercrime 2003 conference here this week.


.. snip ...

Hacker accesses 2.2 million credit cards

From: Lynn Wheeler
Date: 02/17/2003 09:59 PM
To: epay@xxxxxxxx
Subject: Hacker accesses 2.2 million credit cards

http://www.cnn.com/2003/TECH/02/17/creditcard.hack/index.html

Japan seeks smarter ideas for smart cards

From: Lynn Wheeler
Date: 02/17/2003 10:00 PM
To: epay@xxxxxxxx
Subject: Japan seeks smarter ideas for smart cards

http://www.cnn.com/2003/TECH/ptech/02/17/japan.smart.cards.ap/index.html

XACML Access Control Markup Language Ratified as OASIS Open Standard

From: Lynn Wheeler
Date: 02/18/2003 03:36 PM
To: epay@xxxxxxxx
Subject: XACML Access Control Markup Language Ratified as OASIS Open Standard
Universal Language for Authorization Policy Enables Secure Web Services

http://www.oasis-open.org/news/oasis_news_02_18_03.shtml

Solving the problem of micropayments

From: Lynn Wheeler
Date: 02/19/2003 12:05 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Solving the problem of micropayments
http://www.peppercoin.com/


http://www.boston.com/dailyglobe2/048/business/Solving_the_problem_of_micropayments+.shtml

Solving the problem of micropayments
By Hiawatha Bray, Globe Staff, 2/17/2003

IT professor Ron Rivest has come up with a new way to throw away money on the Internet. With luck, it'll make him a fortune. Rivest is one of the three people who devised the encryption system that allows us to transmit our credit- card information safely over the Internet. The company that grew out of this work, Bedford-based RSA Security Inc., is one of the leaders in the field. He's a fellow of the American Academy of Arts and Sciences and the Association of Computing Machinery. Put it this way: Rivest knows what he's doing. So what's all this about throwing away money?


... snip ...

FBI Probing Theft of 8 Million Credit Card Numbers

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 02/20/2003 08:17 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: FBI Probing Theft of 8 Million Credit Card Numbers
... up from earlier reports of 2.2 million


http://story.news.yahoo.com/news?tmpl=story&u=/nm/20030220/wr_nm/crime_creditcards_dc_3

general vulnerability threads
http://www.garlic.com/~lynn/subintegrity.html#fraud

threads specific mention of harvesting credit card numbers
http://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror8 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aepay6.htm#harvest harvesting of credit card numbers
http://www.garlic.com/~lynn/aepay6.htm#harvest2 shared-secrets, CC#, & harvesting CC#
http://www.garlic.com/~lynn/aepay6.htm#erictalk Announce: Eric Hughes giving Stanford EE380 talk this
http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#ssexploit Shared-Secret exploit
http://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#bio5 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm12.htm#51 Frist Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#57 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aadsm12.htm#60 signing & authentication (was Credit Card Scam)
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#19 [Newbie] Authentication vs. Authorisation?
http://www.garlic.com/~lynn/2001f.html#24 Question about credit card number
http://www.garlic.com/~lynn/2001f.html#25 Question about credit card number
http://www.garlic.com/~lynn/2001f.html#52 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#54 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#55 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001g.html#0 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001g.html#63 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#66 UUCP email
http://www.garlic.com/~lynn/2001h.html#68 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#70 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
http://www.garlic.com/~lynn/2002h.html#40 [survey] Possestional Security
http://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002q.html#52 Big Brother -- Re: National IDs

DOD Prepares for biometric embedded smart card pilot

From: Lynn Wheeler
Date: 02/20/2003 08:20 AM
To: epay@xxxxxxxx
Subject: DOD Prepares for biometric embedded smart card pilot
a href="http://www.gcn.com/vol1_no1/daily-updates/21180-1.html">http://www.gcn.com/vol1_no1/daily-updates/21180-1.html

02/20/03
DOD prepares for biometric- embedded smart card pilot
By Dipka Bhambhani
GCN Staff

The Defense Department’s Biometrics Management Office plans to complete its last proof of concept for a biometric- enabled Common Access Card by the end of April and start a pilot as early as this summer.

Late last month, the BMO awarded BearingPoint Inc., a systems integration consultant of McLean, Va., a $1.2 million contract to develop a proof of concept for a biometric-enabled contactless smart card which includes systems and uses for the cards.

BearingPoint, the prime contractor, awarded SAFLINK Corp. of Bellevue, Wash., developer of biometric application software $137,000 to help it find uses for biometrics for wireless physical access control.


.. snip ...

Motorola goes with USB On-the-Go

From: Lynn Wheeler
Date: 02/20/2003 08:22 AM
To: epay@xxxxxxxx
Subject: Motorola goes with USB On-the-Go
http://news.com.com/2100-1033-985217.html?tag=fd_top

Motorola goes with USB On-the-Go
By Richard Shim
Staff Writer, CNET News.com
February 19, 2003, 5:35 PM PT

Emerging connectivity technology USB On-the-Go is gradually becoming the de facto wired standard, gaining more momentum from a licensing deal with chipmaker Motorola.

More than 1.3 billion devices in the market have ports for USB, which became a widely used connectivity technology when Intel integrated it into its chipsets in 1998. TransDimension is looking to make USB On-the-Go as prevalent in mobile devices as USB is in PCs and PC peripherals by striking licensing deals with manufacturers whose chipsets are used in portable devices.


.. snip ...

CMS sets health care e-payment standards

From: Lynn Wheeler
Date: 02/22/2003 05:53 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: CMS sets health care e-payment standards
http://www.computerworld.com/governmenttopics/government/policy/story/0,10801,78722,00.html

CMS sets health care e-payment standards
By Bob Brewin
FEBRUARY 21, 2003
Source: Computerworld

The Centers for Medicare & Medicaid Services (CMS) yesterday published its final rules for electronic health care payment transactions (download PDF), adding what vendors and consultants see as yet another burden to an industry scrambling to meet new privacy and electronic security requirements (see story).


.. snip ...

CMS sets health care e-payment standards

From: Lynn Wheeler
Date: 02/23/2003 08:52 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: CMS sets health care e-payment standards
related ....

10) HIPAA Final Security Rule Summarized

Steve Weil has just completed summarizing 289 pages of HIPAA legislation in a 6.5 page word document that we have posted at:
http://www.sans.org/projects/hipaa.php

He did a fantastic job of laying out the issues; it could serve as an outline for a community consensus research document. If you are interested in contributing to a short book on Implementing HIPAA Step by Step, drop me a note, stephen@xxxxxxxx.


Solving the problem of micropayments

Refed: **, - **, - **
From: Lynn Wheeler
Date: 02/23/2003 10:12 AM
To: Alanslater@xxxxxxxx
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx,
rah@xxxxxxxx, tboyle@xxxxxxxx
Subject: Re: Solving the problem of micropayments
note that the industry has somewhat addressed that with the stored value cards (that you find at video stores, coffee houses, department stores, book stores, grocery stores, drug stores, etc). The same POS terminals now process debit cards, credit cards, and stored value cards .... effectively all going to the same backend merchant processor .... and the backend merchant processor routing the transaction as appropriate.

as previously noted .... to some extent europe went with stored-value chip cards doing offline transactions because of the telco infrastructure barrier in the 80s & 90s (availability and costs). there wasn't a similar telco barrier in the US .... and effectively the same stored-value facility was provided by online transactions thru the existing POS infrastructure.

at 100,000 feet, the credit, debit and stored-value transaction processing is nearly the same .... modulo various regulatory issues.

and of course ... x9.59 was designed to provided authenticated, secure transactions .... regardless of the kind of transactions. x9.59 ref:
http://www.garlic.com/~lynn/x959.html#x959

misc. past stored-value refs:
http://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
http://www.garlic.com/~lynn/aadsm9.htm#cfppki12 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#smallpay Small/Secure Payment Business Models
http://www.garlic.com/~lynn/aadsm11.htm#29 Proposal: A replacement for 3D Secure
http://www.garlic.com/~lynn/aadsm12.htm#31 The Bank-model Was: Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#51 Frist Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aepay10.htm#10 InfoSpace Buys ECash Technologies
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#24 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#36 economic trade off in a pure reader system
http://www.garlic.com/~lynn/2002d.html#41 Why?
http://www.garlic.com/~lynn/2002e.html#14 EMV cards
http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#22 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#23 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002f.html#34 Security and e-commerce
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002f.html#40 e-commerce future
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#19 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#14 So how does it work... (public/private key)

alanslater@xxxxxxxx on 2/23/2003 7:29 am wrote:
Unfortunately, those nice things that banks have come with a significant cost infrastructure. It is that infrastructure that makes micropayments cost prohibitive. For example, suppose someone decided to compile a CD of the tunes he likes. He downloads several hundred songs. He would have to pay for each song (post Napster) and each song would generate a transaction. Consider what would be required to post each micropoayment (think of lines of print on a checking account statement -- required, the additional number of pages, additional postage, additional disk space to support online lookups, etc.). Then consider that the bank has to have the infrastructure to support investigations of each of the charges. The cost adds up quickly.

The solutions we had worked on always involved aggregating transactions to minimize the number of transactions posted to a bank account. A nonbank company has the legal ability to do this, a bank does not.

Alan


Solving the problem of micropayments

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 02/23/2003 07:58 PM
To: Todd Boyle <tboyle@xxxxxxxx>
cc: Alanslater@xxxxxxxx, epay@xxxxxxxx, internet-payments@xxxxxxxx,
    rah@xxxxxxxx
Subject: Re: Solving the problem of micropayments
online magstripe stored-value cards in the US use financial institution to load/purchase the card .... but the actual uses of the card at the merchant don't involved financial institution transactions.

echeck/ach x9.59-like transactions with the entity receiving the funds being identified with something like their public key could be done. The receiving entity then has an account at their financial institution with their registered public key. The transaction is "deposited" by signing it again ... and then the financial institution can settle thru standard ACH network like a normal check.

something like the NACHA aads trials
http://www.garlic.com/~lynn/x959.html#aads

related
http://internetcouncil.nacha.org/
http://pubs.nacha.org/internet.html

also internet-payments mailing list is hosted by FSTC that originated the echeck project

http://www.echeck.org/

note in above that echeck/fstc have patents now on digitally signed payment authorization

also:
http://www.fstc.org/projects/echeck/pressrelease.cfm

fstc web site:
http://www.fstc.org/

universal value exchange launched 2/15/2003 of possibly some interest:
http://fstc-uvx.org/

tboyle@xxxxxxxx on 2/23/2003 5:43 pm wrote:
I have great respect for those accomplishments but note that they invariably, provide no capability for their owners to pay anything to anybody other than thru banks.

Where is there a stored value system that has a P2P interface, even if it relies on physical presence?

Where is there even a stored value system that allows a merchant to aggregate balances, without posting each one to transaction logs at the bank?

Perhaps they exist and I am ignorant,

Thanks
Todd


CIOs Must Be Involved In Controlling Risk In Financial Services

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 02/27/2003 07:14 PM
To: epay@xxxxxxxx
Subject: CIOs Must Be Involved In Controlling Risk In Financial Services

http://www.informationweek.com/story/IWK20030227S0017
Moved:
http://www.informationweek.com/news/global-cio/showArticle.jhtml?articleID=8700491

CIOs Must Be Involved In Controlling Risk In Financial Services
Feb. 27, 2003
Fed vice chairman says Basel II accord is moving the international financial community in the right direction.
By Eileen Colkin Cuneo

The international financial-services community must continue to work together to come up with standards for mitigating operational risk, and the Basel II accord is moving the industry in that direction. So said Federal Reserve vice chairman Roger Ferguson Jr. in testimony Thursday given before the House Subcommittee on Domestic and International Monetary Policy, Trade, and Technology, Committee on Financial Services.

After five years of discussion and revision, Basel II, an international accord that will improve operational-risk standards for all financial institutions, is about ready for the last rounds of comment, which Ferguson expects will happen this spring and summer, with implementation beginning in late 2006.

The core driver behind Basel II has been that banks have consolidated internationally and therefore placed fewer large institutions in control of more money while still operating in heterogeneous environments. That could spell trouble in the future, Ferguson says. "Significant weakness in one of these entities, let alone failure, has the potential for severely adverse macroeconomic consequences. It seems clear that the regulatory framework should encourage these banks to adopt the best possible risk-measurement and -management techniques while allowing for the considerable differences in their business strategies," Ferguson says. "Basel II presents an opportunity for supervisors to encourage these banks to push their management frontier forward."


.. snip ...

Iris recognition helps to prevent ID fraud

From: Lynn Wheeler
Date: 02/28/2003 10:39 AM
To: epay@xxxxxxxx
Subject: Iris recognition helps to prevent ID fraud
http://www.smh.com.au/articles/2003/02/27/1046064145169.html

http://slashdot.org/articles/03/02/28/1330249.shtml?tid=158

ATM Iris Recognition Coming Soon ... every ATM in Australia will have iris recognition technology.

Privacy again a hot-button issue for legistlators

From: Lynn Wheeler
Date: 02/28/2003 11:33 AM
To: epay@xxxxxxxx
Subject: Privacy again a hot-button issue for legistlators
http://www.computerworld.com/securitytopics/security/privacy/story/0,10801,78887,00.html?SKC=security-78887

Privacy again a hot-button issue for legislators
By PATRICK THIBODEAU
FEBRUARY 27, 2003
WASHINGTON

-- Top federal and state privacy enforcement officials are promising aggressive action against companies that, through theft or accident, allow customer data to leak out. But there are divergent views on whether tougher privacy legislation is actually needed to protect customer data.

U.S. Rep. Clifford Stearns (R-Fla.), the leading advocate of privacy legislation in the House of Representatives, said he plans to reintroduce within a few days privacy legislation that would set an "opt-out" standard for consumers. That would give consumers some way to limit the sharing of data, but it would also protect businesses from private lawsuits and leave enforcement to federal and state authorities.


... snip ...

Don't-Ask-Don't-Tell E-commerce

From: Lynn Wheeler
Date: 03/14/2003 07:59 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Don't-Ask-Don't-Tell E-commerce
http://www.computerworld.com/securitytopics/security/story/0,10801,78873,00.html?SKC=security-78873

Don't-Ask-Don't-Tell E-Commerce

By ROBERT L. MITCHELL
MARCH 03, 2003
Content Type: Opinion
Source: Computerworld

Dealing With Credit Card Fraud
If e-commerce is to flourish, policies need to change now.

When it comes to IT security, good technology can't protect an organization against bad policy. Judging from the way the banking industry handled the recent theft of more than 8 million credit card account numbers [QuickLink 36530], that's a lesson that major U.S. credit card associations and issuers have yet to learn.

The situation is unlikely to improve in the near term because the financial services firms that control most credit cards see little economic incentive to change their ways. Those most at risk of incurring losses include consumers (through identity theft), and merchants that accept "card-not-present" transactions.


... snip ...

Spam's Being Used For Identity Theft And Blackmail, Symantec Says

From: Lynn Wheeler
Date: 03/14/2003 08:02 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Spam's Being Used For Identity Theft And Blackmail, Symantec Says

http://www.internetweek.com/security02/showArticle.jhtml?articleID=7800052

Spam's Being Used For Identity Theft And Blackmail, Symantec Says

By Mitch Wagner

Crooks are sending spam using the Symantec Corp. name to sell counterfeit software, engage in identity theft, steal credit card numbers, and even blackmail victims through the use of pornography, Symantec officials said.


... snip ...

Recent IOTP and ECML publications

From: Lynn Wheeler
Date: 03/14/2003 01:56 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Recent IOTP and ECML publications
3506 I
Requirements and Design for Voucher Trading System (VTS), Eastlake D., Fujimura K., 3/132003 (15pp) (.txt=30945) (was draft-ietf-trade-drt-requirements-04.txt)

3505 I
Electronic Commerce Modeling Language (ECML): Version 2 Requirements, Eastlake D., 3/132003 (8pp) (.txt=13915) (was draft-ietf-trade-ecml2-req-05.txt)

3504 I
Internet Open Trading Protocol (IOTP) Version 1, Errata, Eastlake D., 3/3132003 (6pp) (.txt=8655) (See Also 2801, 2802, 2803) (was draft-ietf-trade-iotp-v1-errata-01.txt)


reference URL at rfcindex:
http://www.garlic.com/~lynn/rfcidx11.htm#3504
http://www.garlic.com/~lynn/rfcidx11.htm#3505
http://www.garlic.com/~lynn/rfcidx11.htm#3506

X9/03 LB#8 - Formation of a New Subcommittee - X9C

From: Lynn Wheeler
Date: 03/21/2003 02:25 PM
To: epay@xxxxxxxx
Subject: X9/03 LB#8 - Formation of a New Subcommittee - X9C
possibly of some interest, fyi .... note that some of the ietf iotp working group is slight overlap

new X9 working group:
New Work Item: Consumer Credit: Electronic contracting, chattel paper and promissory notes - X9C1

misc. from ietf rfc index ... aka http://www.garlic.com/~lynn/rfcietff.htm
3506 I
Requirements and Design for Voucher Trading System (VTS), Eastlake D., Fujimura K., 2003/03/13 (15pp) (.txt=30945) (was draft-ietf-trade-drt-requirements-04.txt)
3505 I
Electronic Commerce Modeling Language (ECML): Version 2 Requirements, Eastlake D., 2003/03/13 (8pp) (.txt=13915) (was draft-ietf-trade-ecml2-req-05.txt)
3504 I
Internet Open Trading Protocol (IOTP) Version 1, Errata, Eastlake D., 2003/03/13 (6pp) (.txt=8655) (See Also 2801, 2802, 2803) (was draft-ietf-trade-iotp-v1-errata-01.txt)


Amazon/Bezos: web advertising patent

From: Lynn Wheeler
Date: 03/21/2003 02:56 PM
To: epay@xxxxxxxx
Subject: Amazon/Bezos  web advertizing patent
Patent application for adding advertisements to web pages

http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&s1='20030055729'.PGNR.&OS=DN/20030055729&RS=DN/20030055729

Who's afraid of Mallory Wolf?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/24/2003 10:42 AM
To: epay@xxxxxxxx
Subject: Re: Who's afraid of Mallory Wolf?
forwarded from thread on crypto mailing list .... Mallory Wolf is colloquialism for man-in-the-middle attack. discussion is why are some hundred thousand merchants paying $100 (or more) for SSL certificates as a MITM countermeasure ... when they haven't actually been any reported in the wild ... and would self-signed certificates be sufficient.

a similar question about self-signed certificates in same mailing list:
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?

----- Forwarded by Lynn Wheeler on 03/24/2003 10:15 AM -----
lynn@xxxxxxxx on 3/24/2003 10:10 am wrote:

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)

Card Technology Forecast: 2004-2009

From: Lynn Wheeler
Date: 03/24/2003 01:57 PM
To: epay@xxxxxxxx
Subject: Card Technology Forecast: 2004-2009
fyi ....
http://www.efta.org/

----- Forwarded by Lynn Wheeler on 03/24/2003 01:52 PM -----
March 24, 2003

Dear Colleague:

I am pleased to invite you to an upcoming conference entitled "Card Technology Forecast: 2004-2009." This event, sponsored by the Electronic Funds Transfer Association and its EBT Industry Council, will take place May 6, 2003 at the Hilton Crystal City near Washington, DC. 

The purpose of the one-day summit meeting is to analyze the future of electronic card technology for the delivery of government services or payments. The conference will bridge the gap between where card technology is headed over the next 5 years and where government needs that technology to be for such applications as security, defense and human services.

The all-day program will feature presentations designed to drill down to the issues that card technologists are working on now for future enhancements. These include standards and practices, infrastructure trends and constraints, and program expansion.

Expect senior-level presenters, including keynote, speaker George Wallner, chief strategist and founder of Hypercom Corporation, from such companies as VeriFone, Inc. Citicorp EFS, Visa U.S.A., Fujitsu and Hypercom. They will be joined in an interactive format by veteran program managers from a variety of federal agencies.


related to electronic contracting (new X9C group)

From: Lynn Wheeler
Date: 03/25/2003 08:28 AM
To: epay@xxxxxxxx
Subject: related to electronic contracting (new X9C group)
Microsoft breaks with standards effort
http://news.com.com/2100-1008-993949.html?tag=fd_lede1_hed

previous ...
http://news.com.com/2100-1013-992521.html?tag=nl
W3C seeks standards accord

By Martin LaMonica
Staff Writer, CNET News.com
March 13, 2003, 1:59 PM PT

A World Wide Web Consortium committee began meetings on Thursday to sort out an array of confusing, yet critical, Web services standards.

The WS-Choreography Working Group at the World Wide Web Consortium (W3C) will spend the next two days considering several proposals on how to automate business processes using Web services.

The capability, called choreography or orchestration, means that businesses can use XML (Extensible Markup Language)-based Web services to build software for sharing data and processes in complicated business scenarios. For example, a business could use the choreography specifications to model and execute a financial transaction that spans several companies and computing systems. Web services allow developers to build software applications that can easily communicate with one another.


... snip ...

ID theft costs banks $1 billion a year

From: Lynn Wheeler
Date: 03/27/2003 04:23 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: ID theft costs banks $1 billion a year
ID theft costs banks $1 billion a year
Report: There's no way to positively identify new customers
By Bob Sullivan
MSNBC

March 26: Banks lost at least $1 billion to identity thieves last year, according to a report issued Tuesday by TowerGroup Inc. While only an estimate, it is one of the first attempts to put a detailed price tag on what has been called the nation's fastest growing crime. What's more, the report asserts, banks have no way of telling whether new customers applying for a loan or credit card are actually who they say they are.


... snip ...

Be Prepared: Gartner Outlines Top Security Risks

From: Lynn Wheeler
Date: 03/29/2003 09:12 AM
To: epay@xxxxxxxx
Subject: Be Prepared: Gartner Outlines Top Security Risks

http://www.informationweek.com/story/IWK20030328S0022
Be Prepared: Gartner Outlines Top Security Risks March 28, 2003
The research firm says companies must cut through the hype to develop a coherent security plan
By Gregg Keizer, TechWeb News

With the war in Iraq now in its second week and with security a global worry, what better time to delve into the defensive and protection issues enterprises will face through the end of the year?

Market research firm Gartner obviously thinks so. It released a report that leverages the news to put corporate security front and center. At the just-concluded Gartner Symposium/ITxpo in San Diego, where Gartner brought together thousands of IT professionals from companies both in the United States and overseas, analyst Victor Wheatman outlined a top-10-plus-one list of security issues businesses will confront during 2003.


... snip ...

- Wireless LAN security: Although progress is being made to secure wireless networks, rushing to deploy wireless poses a major threat of information theft, Wheatman said. In addition, he noted the ongoing underground movement to tap into hot spots, including those maintained by businesses, opening up the potential for service and bandwidth shoplifting.

- Identity management: Identity theft is rampant, and is mostly accomplished by mundane means such as "dumpster diving." It's crucial that companies have identity management and provisioning plans in place to prevent workplace identity theft, and educate workers on the dangers of the crime, Wheatman said. And although some vulnerabilities exposed by poor identity management are rarely hyped, they've simply been around too long and remain potent threats.


... snip ...

Bank Float May Sink

From: Lynn Wheeler
Date: 03/29/2003 11:30 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Bank Float May Sink
one of the implementation issues in fstc e-check had to do with float.

http://dc.internet.com/news/article.php/2171621
March 28, 2003
Bank Float May Sink
By Roy Mark

The traditional consumer "float" -- the time between writing a check and when it actually clears the bank -- will be shrinking if Congress approves legislation introduced Thursday that would permit banks to exchange checks by electronic image.

The banking industry says the bill will benefit consumers by speeding up check clearing and making the electronic images -- front and back -- quickly available to customers. Most banks currently physically move the paper checks through intermediaries before actually drawing on the funds, a process that can take several days or longer.


... snip ...

Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/02/2003 07:33 AM
To: epay@xxxxxxxx
Subject: Re: Mockapetris agrees w/ Lynn on DNS security - (April Fool's day??)
and some topic drift .... the other co-inventer was the rfc-editor, jon postel ... who was located at ISI.

For a number of years, I provided Jon with section 6.10 in the regularly issued internet standard STD1 .... as well as misc. other consistency checking about the rfc standards process. It was part of the process that I also used for generating the RFC index at:
http://www.garlic.com/~lynn/rfcietff.htm

example of what section 6.10 used to look like:
http://www.garlic.com/~lynn/rfcietf.htm#obsol

one of the tribute's to Jon is at:
http://wwwvms.utexas.edu/~glen/postel/

There is a hallowed Internet standard RFC tradition for April 1st .... reference
http://www.garlic.com/~lynn/rfcietff.htm
and select Term (term->RFC#), and then scroll down to:
April1
3252 3251 3093 3092 3091 2795 2551 2550 2549 2325 2324 2323 2322 2321 2100 1927 1926 1925 1924 1776 1607 1606 1605 1437 1313 1217 1149 1097 852 748

clicking on any of the RFC numbers will bring up a summary of that RFC in the lower frame. Clicking on the ".txt=nnnn" field in the RFC summary, will fetch the actual RFC.

raise one for Jon ... and one for April 1st.

As an aside ... during the X9 meeting at the Marina Del Rey Ritz in Oct '97, we walked down to ISI and talk to the RFC editor people.

Also the first presentation on AADS was at ISI to a USC graduate student seminar of about 60 people:
http://www.garlic.com/~lynn/x959.html#aads

also at:
http://www.isi.edu/

This past Monday (3/31), Paul is named Visiting Scholar
http://www.usc.edu/isinews/stories/89.html

and another dedication to Jon:
http://www.isi.edu/div7/people/postel.home/

t.c.jones@xxxxxxxx on 4/1/2003 4:44 pm wrote:
Tuesday, April 1, 2003
DNS pioneer warns of Internet security
(6:01 p.m. EST, 04/01/03)

The Internet community can ill afford to rest on its laurels as far as DNS security is concerned. When it comes to the Domain Name System, the database architecture at the heart of the Internet infrastructure for the last 20 years, "the majority of the work to be done still lies ahead of us," said Paul V. Mockapetris who co-invented DNS.

http://www.commsdesign.com/story/OEG20030401S0048

First Data buying Concord EFS

From: Lynn Wheeler
Date: 04/02/2003 08:27 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: First Data buying Concord EFS

http://cbs.marketwatch.com/news/story.asp?guid=%7BEFFF452F-37D9-489C-BC85-DAB5EC729B4C%7D&siteid=google&dist=google
First Data buying Concord EFS
$7 billion stock deal will combine transaction firms

By CBS.MarketWatch.com
Last Update: 8:33 AM ET April 2, 2003

NEW YORK (CBS.MW) - Shares of Concord

EFS rallied in pre-market trades Wednesday after First Data said it'll buy the Memphis, Tenn. transaction specialist in a $7 billion stock deal.


... snip ...

Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/02/2003 11:19 AM
To: epay@xxxxxxxx
Subject: Re: Mockapetris agrees w/ Lynn on DNS security - (April Fool's day??)
and a little cross-over:
http://www.garlic.com/~lynn/2003f.html#24 New RFC 3514 addresses malicious network traffic
http://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic

Bank of America's Trade Finance Strategy

From: Lynn Wheeler
Date: 04/08/2003 03:40 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Bank of America's Trade Finance Strategy

http://www.financetech.com/story/enews/BNK20030407S0003
Date: Apr 7, 2003
Publication: BankTech
By: Ivan Schneider

Bank of America's Trade Finance Strategy

If transforming paper checks into electronic documents seems tricky, just consider the problem of foreign trade.

Trade finance includes not just the buyer and the seller, but also the insurance companies, freight forwarders, shipping companies, consolidators, inspection companies, and government bureaus involved with each shipment. Also, recent homeland security initiatives in the U.S. have made timely access to information about a shipment more important than ever before.


.. snip ...

Actual Losses To Identity Fraud Top $1 Billion

From: Lynn Wheeler
Date: 04/16/2003 10:11 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Actual Losses To Identity Fraud Top $1 Billion

http://www.banktech.com/story/BNK20030416S0001 Annual Losses To Identity Fraud Top $1 billion Paul Doocey Apr 16, 2003

United States-based lending institutions are losing more than $1 billion each year to identity theft, a figure that is likely to grow short-term, according to a report recently released by TowerGroup.

... snip ...

Blackboard Gets Gag Order Against Smart-Card Hackers

From: Lynn Wheeler
Date: 04/18/2003 09:15 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Blackboard Gets Gag Order Against Smart-Card Hackers

http://www.washingtonpost.com/wp-dyn/articles/A48214-2003Apr17.html
Blackboard Gets Gag Order Against Smart-Card Hackers

Georgia Tech computer science student Billy Hoffman has spoken about flaws in Blackboard's card system at several hacker conventions in the past two years. (Tim Cailloux -- Technique Via AP)

By Anitha Reddy

Washington Post Staff Writer
Friday, April 18, 2003; Page E01

A D.C.-based company that sells a "smart card" network used on more than 200 college campuses has blocked two students from publicly describing how to override the system to circumvent building security, obtain free soft drinks and avoid paying for laundry.

Blackboard Inc. obtained a court order last weekend preventing Billy Hoffman, a computer science major at Georgia Tech, and Virgil Griffith, a student at the University of Alabama, from discussing vulnerabilities in the card system at a hacker convention in Atlanta.


.. snip ...

A More Anonymous Internet

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/18/2003 09:42 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: A More Anonymous Internet
Note, the other approach by X9.59 ... was to remove account numbers from the category of shared-secrets and therefor usable in fraud situations. It is the use of account numbers of fraudulent transactions that gets them lumped into the overall identity theft category.

The issue addressed by X9.59 is that account numbers can be only used in authenticated transactions, that just having knowledge of the account number is not sufficient to perform fraud. Parts of the problem is that account numbers tend to be used in a number of business processes, not just the initial authorization transaction. I'm not aware of evesdropping and/or man-in-the-middle exploits related to payment card transactions flowing over the internet (either with or w/o SSL). The major exploits that make the press is when a merchant account file with tens or hundreds of thousands of transactions get snarfed by some process.

It fraud issue isn't directly that credit card number has to be revealed ... it is that currently with just knowledge of the credit card number, it is possible to perform fraud. The X9.59 solution is to allow knowledge of the credit card number (since it is required in a number of business processes), and to eliminate the ability to perform fraud given just given the knowledge of the number with the use of authenticated transactions.

misc. privacy, identity, authentication & x9.59
http://www.garlic.com/~lynn/subpubkey.html#privacy

http://www.technologyreview.com/articles/innovation40503.asp
A More Anonymous Internet

By Tracy Staedter
Innovation
May 2003

Identity theft and credit card fraud are surging international problems, fueled partly by the need to reveal credit card and Social Security numbers in the course of common Internet transactions. Although most businesses immediately encrypt such numbers, researchers at IBMs Zurich Research Laboratory and elsewhere are devising ways to avoid having to submit the numbers in the first place.


Concern Grows About ID Theft

Refed: **, - **
From: lynn.weeler@xxxxxxxx
Date: 04/18/2003 01:08 PM
To: epay@xxxxxxxx
cc: internet-payments@xxxxxxxx
Subject: Re: Concern Grows About ID Theft
from the article ... there isn't any real indication what words were used in the meeting and what, if any translation was provided by the reporter.

as in the x9.59 discussions ... one might observe that there have been a lot of parties working on hiding shared-secrets .... requiring ever increasing amounts of cryptography. the x9.59 observation is that the existing paradigm with the existing account number being a shared-secret ... and sufficient for fradulent transactions .... is also used in a number of transaction processing business processes ... requiring direct availability of the account number. millions of dollars of cryptography hiding the account number would still not be sufficient to close all the loop-holes.

the x9.59 approach was to change the paradigm and eliminate the account number as a direct fraud vulnerability.

somewhat related discussion as to security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe?

egerck@xxxxxxxx wrote:
;-) in an attorney's meeting, the word should be "impersonation" -- there is no such thing as an "identity theft". Using such awe-inspiring expression as "identity theft" may help get public attention but is, IMO, not productive in terms of understanding what is happening and how to solve it. Perhaps, it is this dumbed down choice of words that is making the solutions so elusive -- and so "justifiably" hard to provide.

Cheers,
Ed Gerck


Nokia, MasterCard test wireless payment

From: Lynn Wheeler
Date: 05/17/2003 04:00 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Nokia, MasterCard test wireless payment
http://www.infoworld.com/article/03/05/14/HNmasternokia_1.html
Nokia, MasterCard test wireless payment
PayPass technology puts credit card info on mobile phones

ByJohnBlau
May 14, 2003

Imagine waving your mobile phone at a filling pump to pay for gas or tapping it on some tiny gadget to buy a bag of doughnuts. That's the vision of Nokia and MasterCard International. The two companies have teamed to test technology that they hope will someday give mobile phones new wireless credit card capabilities.


... snip ...

Visa, Philips team to promote 'contactless' credit card

From: Lynn Wheeler
Date: 05/29/2003 02:37 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Visa, Philips team to promote 'contactless' credit card
http://www.eetimes.com/sys/news/OEG20030528S0030
Visa, Philips team to promote 'contactless' credit card

by Junko Yoshida
EE Times
May 28, 2003 (5:03 p.m. ET)

PARIS - Visa International and Royal Philips Electronics have unveiled an exclusive partnership agreement under which the two companies will jointly develop and promote the application of contactless chip technology for payment transactions.


... snip ...

Authentication white paper

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/08/2003 01:23 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Authentication white paper
I'm in the process of finishing up an authentication white paper for an international financial "best practices" security book. Much of it reflects the various deliberations that went on in the x9a10 committee for the x9.59 standard (requirement given the x9a10 committee to preserve the integrity of the financial infrastructure for ALL electronic retail payments; aka ALL as in not just internet, not just point-of-sale, not just credit, not just ACH, etc). Some specific issues related to the X9A10 committee work:

A taxonomy for security is PAIN
P ... privacy
A ... authentication
I ... identification
N ... non-repudiation


A taxonomy for authentication is 3-factor authentication:
something you have (aka hardware token)
* something you know (either shared-secret or non-shared-secret)
* something you are (biometrics, again either shared-secret or non-shared-secret)


While x9.59 primarily deals with strong authentication for financial transactions, the original chair (Tom Jones) of X9A10, put a lot of early work into non-repudiation for financial transactions. This effectively took the form of cosigning .... the early X9.59 work went on contemporary with the fstc/echeck work on people authentication cosigning (and FSML encoding, a lot of which has been folded into XML digital signature work). While neither kind of cosigning actually show up in the x9.59 standard, the standard was carefully written in such a way as to not preclude either form of cosigning.

The concept behind Tom's work on consigning is synergistic with the EU FINREAD (financial reader) standard. In the past, there had been quite a bit of confusion generated somewhat assuming that non-repudiation and authentication could possibly be equivalent. This was possibly something of semantic confusion with the term "digital signature" somehow taken to be the equivalent of a human physical signature and all that it implies with respect to intention, agreement and non-repudiation.

The FINREAD standard has a token acceptor device that is certified to display the value of the financial transactions followed by the entry of the hardware token PIN/Password (prior to the token performing authentication; as well as guaranteeing the value displayed is what is sent to the token for authentication).

The simple design of a two-factor authentication system involves a PIN/Password that activates a hardware token performing a digital signature for authentication. The hardware token has been certified to not perform a signature unless the correct PIN has been entered. The existence of a digital signature then demonstrates possession of something you have token and implies that the correct something you know PIN was entered.

However, just because two-factor authentication was demonstrated, it hasn't demonstrated that a person has read and agreed with something. Intention and non-repudiation becomes a process that includes some human interaction. The EU FINREAD standard certifies a token acceptor device that implements a process that provides some degree of assurance that the process for non-repudiation/intention has been met, aka the correct amount was presented on the display, followed by explicit human interaction (typing the correct PIN on the pad immediately below the display), and that the value presented to the token for signing matched what was on the display.

In the case of a certified token, two-factor authentication can be inferred because the token will not have been performed correctly w/o the correct PIN having been entered. In the case of certified FINREAD terminal, non-repudiation process can be inferred because the FINREAD terminal requires the PIN (human physical action) to be entered after the transaction has been displayed, and the FINREAD terminal guarantees what was sent to the token for signing is what is displayed and is sent after then PIN has been entered.

The big difference between the current EU FINREAD standard (certified terminal attempting to establish the basis for inferring intention and/or non-repudiation) and the early X9A10 work by Tom Jones, was that Tom wanted the certified terminal/environment to cosign the transaction .... thereby proving that the signing actually took place using a certified terminal/environment. The existing FINREAD standard establishes the criteria for a certified signing environment/terminal (required for inferring intention/non-repudiation) but doesn't (yet) require proof that the signature actually occurred using such a certified terminal/environment.

The cosigning for X9.59 transactions was different than the FSTC e-check cosigning. The FSTC e-check cosigning wanted two (or more) entities authenticating the transaction. The X9.59 cosigning work wanted proof that a certified signing environment (process required for inferring intention and/or non-repudiation) was used (by the environment/terminal cosigning the transaction).


aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

regarding trusted token acceptor device for ACH transactions:
http://www.asuretee.com/company/releases/030513_hagenuk.shtm

.... and as an aside the merged security taxonomy and glossary is at
http://www.garlic.com/~lynn/index.html#glossary

Note that otherwise similar tokens may come with three different types of personalities:

1) no PIN required .... frequently found in low-value, high traffic transit locations. Single factor (something you have) authentication is sufficient

2) PIN required after power up ..... frequently found in two-factor authentication access applications, the token is powered up, the correct PIN entered, and the token may digitally sign an arbitrary number of authentication messages while powered up. The operation of the hardware token implies correct something you know PIN as part of two-factor authentication.

3) PIN required for every message .... found in financial transaction applications and typically assumed to be used in an authentication environment that allows intention and/or non-repudiation to be inferred. The PIN, in addition to implying something you know authentication also implies some human physical event (entering the PIN) occurred as part of a non-repudiation process.

Note that there is a significant difference in the shared-secret paradigm and the non-shared-secret paradigm. In the shared-secret paradigm, the something you know is recorded at some central location and used to establish authentication. In the non-shared-secret paradigm, the secret can be recorded in a private hardware token, and the knowledge of the secret can be inferred from the operation of the token; w/o actually requiring the secret to ever be divulged.

As a footnote, X9.59 doesn't (directly) address the privacy part of security. There is current situation where credit-card transaction have encrypted transmission on the internet using SSL; in part because the account numbers are a form of shared-secret (divulging the account number can result in fraudulent transactions). X9.59 as part of the original requirement preserve the integrity of the financial infrastructure for all retail payments, specifies 1) authenticated transactions and 2) account numbers that can only be used in authenticated transactions. As a result, X9.59 account numbers by themselves can't be used in fraudulent transactions and therefor no longer have to be treated as shared-secrets. It was observed, that in any transition, financial institutions could use existing business processes that map multiple different account numbers to the same account.

Furthermore, the claim is that with strong two-factor authentication (something you have and something you know) operation, it would be possible to remove names from tokens and as part of transactions. While X9.59 doesn't directly address financial privacy issues (via specifying mechanisms like encryption), it indirectly aids privacy by eliminating account numbers as shared-secrets and significantly minimizing any requirement for identification information as part of transactions (aka even better than protecting the information is the information not being there at all).

FINREAD was. Authentication white paper

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/08/2003 03:03 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: FINREAD was. Authentication white paper
anders rundgren on 6/8/2003 1:54 pm wrote:
regarding the references to FINREAD I believe the vision as represented by the following document
http://www.finread.com/pages/finread_initiatives/ec_funded_projects/02_embedded.html
has little foundation in reality. I.e. reading current "king-sized" smart credit cards in mobile phones or PDAs seems like a rather complex idea taking in consideration the proliferation in the card sector.


makes reference to a finread compliant terminal ...
http://www.hagenukscs.com/

FINREAD ... and as an aside

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn.wheeeler@xxxxxxxx
Date: 06/08/2003 03:48 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: FINREAD ... and as an aside
with regard to finread operation for inferring intention and/or non-repudiation from previous posts:
http://www.garlic.com/~lynn/aepay11.htm#53
http://www.garlic.com/~lynn/aepay11.htm#54

is a characteristic of the disconnect between the something you have token and the technology needed for secure display and input.

there has been quite a bit of work translating the requirements for inferring intention and/or non-repudiation into a something you have device that integrates the attributes of personal token with secure display and input (aka some form of PDA or cellphone).

This somewhat reflects the claim that (7816) smartcards went thru a period where there was some thought that they would be the PDAs of the 1980s i.e. the technology didn't yet exist to integrate portable computing that fit in a pocket along with portable display and input. The solution was to have ubiquitous input/output stations with people carrying the portable computer (smartcard) in their pocket. In the early 90s, there was advances in technology that allowed that the portable computing devices (aka smartcards) and input/output capability to be integrated into a single device (evidence PDAs and cellphones). This effectively began the obsoleting of that target market for smartcards.

embedding an aads chip in a personal portable computing device with integrated input/output (aka PDA/cellphone) can provide both the indication of something you have authentication along with proof of a business process that supports intention and/or non-repudiation. Of course the specific personal, portable computing device with integrated input/output will need to be appropriately certified as meeting the (equivalent finread) security requirements in support of demonstrating intention and/or non-repudiation. This requires a high level of assurance that the value of the transaction that is displayed, is in fact the value that a digital signature is applied to ... and that there is some sort of human input in conjunction with the value displayed that can be taken as representing human intention and agreement.

this is similar to past threads relating to the asuretee chip being the equivalent of the trusted computing platform module. Depending on the business process followed and the exact certification, an embedded asuretee chip could be taken as

1) authenticating a hardware device,
2) authentication as part of something you have paradigm,
3) authentication in conjunction with other inferred events supporting two/three factor authentication and/or intention and non-repudiation.

The original references to FINREAD wasn't whether or not it was applicable to PDAs and cellphones, but what were the characteristics of the requirements in the FINREAD standard necessary for establishing intention and/or non-repudiation. Using the implementation details of a FINREAD terminal as an example along with the original requirements, it is then possible to translate the requirements to other implementations. I relatize that the specifics of the FINREAD terminal represent the 80s disconnect between technology available for a personal, pocket-sized portable computing device and the 1980s input/output technology needed to support a pocket-sized portable computing device. However, it is also possible to translate requirements for supporting "intention" into 1990s technology where the personal pocket-sized portable computing device has its own integrated input/output technology.

lots of past threads related to FINREAD and/or intention.
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
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/aadsm12.htm#30 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures"
http://www.garlic.com/~lynn/aepay10.htm#53 First International Conference On Trust Management
http://www.garlic.com/~lynn/2000f.html#79 Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#51 future of e-commerce
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#46 Big black helicopters
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001n.html#70 CM-5 Thinking Machines, Supercomputers
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002l.html#28 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
http://www.garlic.com/~lynn/2002p.html#52 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
http://www.garlic.com/~lynn/2003h.html#29 application of unique signature
http://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation

FINREAD was. Authentication white paper

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/08/2003 05:13 PM
To: "Scott Guthery" <sguthery@xxxxxxxx>
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: RE: FINREAD was. Authentication white paper
scott guthery on 6/8/2003 4:29 pm wrote:
Yep, everybody's going to instantly stop doing business on the Internet until they can rent a $150 card reader from a bank that uses the device to block transactions with businesses that won't pay it PIN handling fee and use their network and clearing services.

there seems to be a little exaggeration. none of the finread terminals i've seen come anywhere close to $150/terminal.

also, in most cases, the issue is security/integrity proportional to the risk. the specific example quoted in the original posting was a terminal for secure ACH transactions, not something that you currently find being done on the internet. the original posting also gave the example of single-factor something you have authentication (as in transit, not requiring two-factor authentication) .... aka internet-payments doesn't necessarily limit things to consideration for only existing consumer/merchant e-commerce operations.

the existing consumer internet based infrastructure is heavily based on the original work that my wife and I were involved with for payment gateway with a small client/server startup (originally in menlo park, subsequently moved to mountain view and since been bought by AOL):
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the current, existing infrastructure is oriented to shared-secrets and single-factor something you know authentication that has been heavily exploited for fraud. One case would be to look at the various cost/benefit trade-offs for improving the existing fraud situation (past postings to these mailing lists have it at 30-50 times higher than similar transactions not done on the internet). Also the existing scenario makes little or no attempt at non-repudiation .... it is assumed that the consumer can readily and easily repudiate all internet-originated transactions. Non-repudiation may not be a requirement for internet transactions; something you have and something you know, two-factor authentication may be sufficient.

Presumably, the PIN handling fee refers to the transition from shared-secret based infrastructure (aka PIN) to non-shared-secret digital signature based infrastructure ... where the public key is registered in lieu of the PIN and a digital signature authentication is done in lieu of a PIN comparison. A possible X9.59 cost/benefit then potentially is the possible significantly reduced fraud-related fees to the merchant being significantly larger than the PIN (or digital signature) handling fee.

Somewhat as a total aside .... in the case of X9.59 standard, the protocol specification is the same regardless of whether or not a token is used. Any requirement for a token becomes a business process assurance issue, not a protocol issue. The requirement for signing environment that supports intention also is a business process assurance issue, not a protocol issue. It is possible to use the same x9.59 protocol standard across a broad range of varying business process assurance and integrity implementations.

US warns banks about virus

From: Lynn Wheeler
Date: 06/10/2003 09:10 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: US warns banks about virus
http://www.smh.com.au/articles/2003/06/10/1055010959747.html
Washington
June 10 2003

The US government is warning financial institutions about a virus-like infection that has targeted computers at roughly 1200 banks worldwide, trying to steal corporate passwords.

The FBI is investigating what private security experts believe to be the first internet attack aimed primarily at a single economic sector.


... snip ...

PKI's not working

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/12/2003 01:57 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: PKI's not working
note in this cross posting from ietf pkix, cross-posted from bar association mailing list ... mentions banks being able to attest to some assertion.
http://www.garlic.com/~lynn/aadsm14.htm#43 PKI's not working

that effectively what an x9.59 transaction is ... the financial institution providing real-time confirmation about some assertion regarding payment.

this was generalized quite a bit in the FSTC FAST project .... which effectively took the 8583 payment transaction model and extended it to other types of assertions; aka zip-code, >21 years old, <16years old, etc. Some generalized assertion was made (not just about payment) and the financial institution either affirmed it or didn't affirm it. it wasn't a case somewhat outlined in
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view

where huge amounts of identity and privacy information could be overloaded into a certificate ... which then could be sprayed all around the world.

x9.59 refs:
http://www.garlic.com/~lynn/x959.html#x959
http://www.ca0.net/

some past FSTC FAST discussions:
http://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
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
http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government

US warns banks about virus ... another ref:

From: Lynn Wheeler
Date: 06/12/2003 04:33 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: US warns banks about virus ... another ref:
http://itmanagement.earthweb.com/secu/article.php/2221131
Feds Investigate Virus Attack on Financial Industry
June 12, 2003
By Sharon Gaudin

The security community and the federal government are on alert for what could be another evolution in computer viruses. The newest variant of the Bugbear virus -- W32.Bugbear.B@mm -- is designed to specifically target financial institutions. When it infects a computer in the financial community, the virus logs keystrokes, steals passwords and sets up backdoor Trojans.
... snip ...

PKI's not working

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 06/12/2003 04:48 PM
To: Todd Boyle <tboyle@xxxxxxxx>
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: PKI's not working
careful, somebody might think you are playing ringer for aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

slight quibble .... establish authentication with public key cryptography ... mixing up identification and authentication can get really messy.

todd boyle on 6/12/2003 4:26 pm wrote:
Public key cryptography is quite usable for the problem of enabling competent, willful individuals to prove their identity and other assertions over networks. Of course there are no secure devices in common use that can't be hacked in seconds by hackers of sufficient skill. But that is another problem.

Public key cryptography is much less useful in addressing the problem of organizations and governments to positively identify unwilling, recalcitrant citizens at the other end of a network connection.

PKI's not working for that, and neither will anything else ever work for that. You cannot control what is at the other end of an electric wire. Only the other person can control that.

Oh, you can win their cooperation in some interaction they decide to participate in. And you can even make them "an offer they cannot refuse." But you're never really going to achieve net gain with a machine with a network, with customers tethered to the network.

Organizations are accustomed to earning long term, recurring cash flows from physical buildings, physical employees watched over by managers, and procedures of internal control, that's not going to happen when the "organization" is a supreme computer with no employees. There is no magic protocol, no crypto, that will achieve this. Accordingly banks should put in hands of their customers, an honest signing device and forget their dreams of pki empire,

Todd


HIPAA, privacy, identity theft

From: Lynn Wheeler
Date: 06/16/2003 09:52 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: HIPAA, privacy, identity theft
some past studies have found that driving factors behind privacy regulation & legislation are 1) denial of service (by institutions) and 2) identity theft

http://www.computerworld.com/securitytopics/security/privacy/story/0,10801,82051,00.html
By Marne Gordan
JUNE 12, 2003
Computerworld

With the Health Insurance Portability and Accountability Act (HIPAA) privacy deadline recently passed, most health care providers and plan companies are preparing to implement the final rule for security. While many of these organizations are focused on the lack of budgetary and staff resources necessary to fulfill another unfunded federal mandate, most have lost sight of why this level of protection is necessary.

As organizations (known in the legal jargon as "covered entities") begin their risk assessments and risk management planning, it's important to remember one of the key principles of the regulations, and that is patient protection. The standard clearly states that the organization must ensure the confidentiality, integrity and availability of protected health information (PHI) and safeguard it from threats, hazards and unauthorized disclosure, but the act neglects to underscore why it's important to do so.


... snip ...

HIPAA, privacy, identity theft (addenda)

From: Lynn Wheeler
Date: 06/16/2003 12:05 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: HIPAA, privacy, identity theft (addenda)
further down in the computerworld HIPAA article they have an example (examples seem to be everywhere) of some master file harvesting that includes credit card numbers ... and the resulting fraud and identity theft.

one of the issues is that if privacy related vulnerabilities continue to occur, there will continue to be additional regulatory and legislative actions.

and from some other report:

"ID theft is growing at 300% per year. The Aberdeen Group estimates that the Global Economy will sustain $221 Billion in losses related to Identity Theft by the end of 2003."

and of course, some x9.59 standards objectives: 1) authenticated transactions, 2) cc# by itself is no longer sufficient for fraud and therefor doesn't have to be treated as a shared-secret or privacy issue, and 3) with strongly authentication transactions .... weaker authentication forms involving indentity information (like name, address, zip-code, etc) can be eliminated as part of the financial transaction.

past postings related to x9.59 &/or privacy:
http://www.garlic.com/~lynn/subpubkey.html#privacy
past postings related to vulnerabilities, exploits, and/or fraud:
http://www.garlic.com/~lynn/subintegrity.html#fraud

E-merchants Turn Fraud-busters

From: Lynn Wheeler
Date: 06/16/2003 02:59 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: E-merchants Turn Fraud-busters
related:
http://www.computerworld.com/managementtopics/ebusiness/story/0,10801,82072,00.html
http://www.computerworld.com/managementtopics/ebusiness/story/0,10801,82079,00.html

http://www.computerworld.com/managementtopics/ebusiness/story/0,10801,82073,00.html?SKC=home82073
E-merchants Turn Fraud-busters

Web retailers are teaming up to fight online credit card fraud and take back the e-neighborhood.

By Alan R. Earls
JUNE 16, 2003

Nobody likes being ripped off. But for online retailers, the pain of being ripped off by unethical consumers, identity thieves and bogus-card gangs has been magnified by what they consider to be the not-my-problem attitude of credit card issuers and card associations like Visa and MasterCard.

Tom Mahoney, a network administrator at Franklin & Marshall College in Lancaster, Pa., recalls vividly the shock he and his wife felt shortly after they launched their own mom-and-pop e-business in 1997 and discovered not only the threat of fraud but also the double whammy from the credit card companies.


... snip ...

EFTA to Adaopt ATM Ant-Fraud Measures

From: Lynn Wheeler
Date: 06/18/2003 12:16 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: EFTA to Adaopt ATM Ant-Fraud Measures
In Brief: EFTA to Adopt ATM Anti-Fraud Measures
American Banker Wednesday, June 18, 2003
By David Breitkopf

The Electronic Funds Transfer Association's board of directors voted unanimously on June 11 to adopt a set of recommendations to combat fraud using automated teller machines.

The recommendations were written by the Washington group's ATM Integrity Task Force, which was formed last year to come up with ways to thwart the skimming of financial data from debit cards at teller machines.

Suggested measures included improving PIN security and upgrading older machines to modern encryption standards and having ATM deployers check the credentials of the company operating the machines on their behalf.

The EFTA seems poised to make the ATM Integrity Task Force a permanent council. An August meeting will probably address point of sale security, executives of the association said.


E-merchants Turn Fraud-busters (somewhat related)

Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/18/2003 02:20 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: E-merchants Turn Fraud-busters (somewhat related)
An earlier NACHA report may bear repeat ref from Feb:
http://web.archive.org/web/20070706004855/http://internetcouncil.nacha.org/News/news.html

as an aside, the above URL also contains pointer to the results of the NACHA AADS trials
http://www.garlic.com/~lynn/x959.html#aads

Internet Payments Fraud: A Primer for Merchants and Financial Institutions
http://internetcouncil.nacha.org/docs/Fraud%20Paper%20Final%20%20Jan%20%2703.pdf

table of contents for above:
INTERNET PAYMENTS FRAUD: A PRIMER FOR MERCHANTS AND FINANCIAL INSTITUTIONS

1.0 INTRODUCTION
1.1 OVERVIEW OF INTERNET FRAUD
1.2 SCOPE
1.3 ORGANIZATION AND USE OF THIS DOCUMENT
2.0 ACH-SPECIFIC FRAUD..
2.1 INTRODUCTION
2.2 ACH FRAUD CATEGORIES
2.2.1 Unauthorized
2.2.2 Returns/60-day Right of Recredit
2.2.3 Real-time Online Account Number Verification
2.2.4 Account Numbers
2.2.5 Non-Sufficient Funds
2.3 CASE STUDIES/EXAMPLES
2.3.1 Case 1 - Fraudulent Use of Stolen Bank Account
2.3.2 Case 2 - Buyer Beware Fraud
2.3.3 Case 3 - Fraudulent Use of a Corporate Account
3.0 TRANSACTION-LEVEL FRAUD
3.1 INTRODUCTION
3.2 TRANSACTION-LEVEL FRAUD CATEGORIES
3.2.1 Transport Vuln
3.2.2 Price Changing
3.2.3 Login ID, Username and Password Crackers
3.2.1 Case 1 - Insecure File Transmission
3.3.2 Case 2 - Price Changing
4.0 IDENTITY THEFT
4.1 DESCRIPTION
4.2 IDENTITY THEFT CATEGORIES
4.2.1 Types
4.2.2 Methods
4.3 CASE STUDIES/EXAMPLES
4.3.1 Case One - GAO Identity Theft Case
4.3.2 Case Two - Corporate Executives as ID Theft Victims
4.3.3 Case Three - Internet ID Theft
4.3.4 Case Four - Establishment of New Accounts
4.3.5 Case Five - Systematic Theft of Social Security Numbers
5.0 MERCHANT-LEVEL FRAUD
5.1 INTRODUCTION
5.2 MERCHANT-LEVEL FRAUD CATEGORIES
5.2.1 Employee-Initiated Fraud
5.2.2 Fraudulent Auction Sellers
5.2.3 Spoofing
5.2.4 Merchant Non-Delivery/Bankruptcy-Related Fraud
5.2.5 Hacking into a Legitimate Merchant Site
5.3 CASE STUDIES/EXAMPLES
5.3.1 Case 1 - Triangulation
5.3.2 Case 2 - Corporate Payroll Check Number
5.3.3 Case 3 - PayPal Website Spoof
5.3.4 Case 4 - Last Minute Address Changes
6.0 STAKEHOLDER IMPACT
6.1 CONSUMERS
6.2 MERCHANTS
6.3 FINANCIAL INSTITUTIONS
6.3.1 Merchant Financial Institutions
6.3.2 Consumer Financial Institutions
6.4 PAYMENT SYSTEMS
7.0 TIPS FOR MANAGING FRAUD RISK
7.1 FINANCIAL INSTITUTIONS
7.1.1 Verification and Authentication Procedures
7.1.2. Secure Data Management
7.1.3 Real-time Fraud Detection Capabilities
7.1.4 Internal Audit and Control Procedures
7.1.5 Remediation Activities
7.2 MERCHANTS
7.2.1 Verification and Authentication Procedures
7.2.2 Internal Data Security
7.2.3 Order Screening...
7.2.4 Fraud Detection Capabilities
7.2.5 Internal Audit/Control Policies
7.2.6 Non-Sufficient Funds (NSFs)
7.3 CONSUMERS
7.3.1 Information Protection
7.3.2 Fraud Detection..
7.3.3 Fraud Remediation
8.0 CONCLUSION
9.0 FRAUD MANAGEMENT REFERENCES
9.1 U.S. GOVERNMENT RESOURCES
9.2 INDUSTRY RESOURCES...
9.3 PRIVATE RESOURCES
9.4 OTHER RESOURCES
10.0 APPENDICES
10.1 GLOSSARY
10.2 APPENDIX - GENERAL SECURITY CHALLENGES
10.2.1 Generalized Hacking
10.2.2 DOS- Denial of Service
10.2.3 Trojan Horse Attacks (And Worms and Viruses)
10.2.4 Transport Vulnuerabilities
10.2.5 Many to One Logins
10.2.6 Buffer Overflows
10.2.7 Cross-site Scripting
10.2.8 Outsourcing
10.2.9 Script-Based Attacks
10.2.10 Incorrect Coding
10.2.11 Authentication-only
10.2.12 HTTP Secure Form Post
10.2.13 Credit Balance Refund


Confusing Authentication and Identiification?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/21/2003 11:31 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Confusing Authentication and Identiification?
Does identity management clash with privacy
http://www.infoworld.com/reports/SRidmgmtandprivacy.html

Frequently it seems that it isn't an identity management issue, but confusing identification and authentication.

One of the things in X9.59 was rather than trying to blanket the world with deep layers of encryption (in order to protect credit card numbers, which still had to appear in the clear because of numerous business process issues) was to convert the information from shared-secret (needing hiding, privacy, confidentiality and encryption) to a non-shared-secret with authentication.

In the existing process with non-authenticated transactions, just learning a credit card number is sufficient for somebody to generate a fraudulent transaction (effectively making the credit card number a shared-secret and classified as one of the identity theft items). x9.59 changes the transactions from non-authenticated to authenticated and eliminates the ability to use an (x9.59) account number in fraudulent transactions. Not being able to use the account number for fraudulent transactions eliminates it as being classified as shared-secret or target of identity theft. In the non-authenticatted paradigm, it was not possible to bury the earth under deep enough layer of encryption to really protect it, since it was required to be in the clear as part of so many business processes.

Part of the issue is being able to strongly characterize and differentiate authentication from identification. Changing a paradigm from identification-basd to authentication-based goes much further to protecting individuals, aka extermely strong encryption for protecting shared-secret, sensitive, and confidential information may be good, but not having shared-secret, sensitive, and confidential information is even better.

Electronic transactions tend to involve authentication and permissions (or authorizations). Permissions and authorizations may also be considered as class of sensitive and confidential information (say like printing the current credit limit). Good protocols might be considered to be some simple authenticated request or assertion with simple yes/no response. This was the paradigm followed in X9.59 protocol work as well in the FSTC FAST work (effectively a debit-like transactions but instead of making an assertion about payment that was approved or not, the FAST assertions were about other facts like age limit, local liqueur/gambling regulations, etc). In the FAST scenario, it wasn't necessary to divulge a person's birth date, it was sufficient to assert that they were over 21 (or 18) and validate the assertion.

misc past authentication/identification threads:
http://www.garlic.com/~lynn/aepay10.htm#5 I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#58 PKI's not working
http://www.garlic.com/~lynn/aepay11.htm#60 PKI's not working
http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
http://www.garlic.com/~lynn/aadsm10.htm#anonpay Crypto Winter (Re: Looking back ten years: Another Cypherpunks failure)
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
http://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm13.htm#12 Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#13 A Trial Balloon to Ban Email?
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
http://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week
http://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow
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/2002f.html#22 Biometric Encryption: the solution for network intruders?
http://www.garlic.com/~lynn/2002g.html#66 Formal Classification for Security Topics
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#53 Authentication of others is a privilege, not a right
http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
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
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003f.html#35 Public Encryption Key
http://www.garlic.com/~lynn/2003f.html#37 unix
http://www.garlic.com/~lynn/2003h.html#18 Authentication protocol
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation

Confusing Authentication and Identiification?

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/21/2003 02:29 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Confusing Authentication and Identiification?
Early in the x9.59 process there were a number of blatently erroneous assertions that account-based represented a closed infrastructure while certificate-based repesented an open infrastructure.

Basically, in both account-based and certificate-based infrastructures ... there can be public key owners, relying parties, and certification bodies. An account-based infrastructure tends to provide online certification while a certificate-based infrastructure tends to create stale, static copies of information (kept in accounts by the certification authority) that can be used in offline scenarios.

In both account-based and certificate-based operations, you could have the same exact information being certified, the same exact public key owners, the same exact relying parties and the same exact certifying authorities.

An account-based and certificate-based operation can be equally closed or open based on the type of information being authenticated and the degree of trust that the certifying bodies have among the population of relying parties. The blatently erroneuous statement about account/certificate operations differing by being closed/opened wasn't the differentiator; the differentiator between account/certificate operations tends to be whether it is an online operation vis-a-vis offline operation.

The other scenario, was that some x.509 identity certiificate operations fell into the trap of thinking that they could grossly overload certificates with large amounts of identity and privacy information and widely publish and distribute the information all over the world. As it began to dawn on them that this probably wasn't a good thing, there was a significant reduction in the types of information that might be published in a certificate (many financial institutions retreating to a relying-party-only certificate containing a public key and a customer account number). As the types of identity and privacy information that might be globally published became more & more restricted, effectively certificates became more and more of a closed environment. In that sense, the FSTC FAST paradigm actually represents more of an open infrastructure than any of the privacy tainted certificate paradigms, since it is possible for FSTC FAST to provide online response to an "over 21" assertion w/o divulging the birth date, or to provide an online response to "pay $100" assertion w/o divulging the account balance or the person's name or address.

The issue regarding account-based vis-a-vis certificate-based is one of online vis-a-vis offline. However, a online infrastructure has some degree additional latitude in validating various kinds of authenticated assertions w/o unnecessarily divulging identity and/or privacy information which would typically be found in a certificate-based implementation.

In that sense, given any concern over not wanting wide-spread publication and distribution of large amounts of identity and privacy information, an online certification operation might be considered to be somewhat more open than a certificate based information .... since it could perform more types of (online) validations w/o unnecessarily widely publishing identity and privacy information. The online paradigm tends to also deal with much more dynamic data (like current account balance) which can be of much more value compared to the offline paradigm (like whether or not a person did or didn't have a specific bank account at some time in the past).

somewhat related, the IETF AAA working group just published a new RFC
3539 PS
Authentication, Authorization and Accounting (AAA) Transport Profile, Aboba B., Wood J., 2003/06/20 (41pp) (.txt=93110) (was draft-ietf-aaa-transport-12.txt)


for a complete list of AAA working group RFCs go to
http://www.garlic.com/~lynn/rfcietff.htm
and select Term (term->RFC#) and then scroll down to "Authentication, Authorization, and Accounting"

Authentication, Authorization and Accounting
see also accounting , authentication , authorization
3539 3127 2989 2977 2906 2905 2904 2903


past discussions of relying-party-only certificates:
http://www.garlic.com/~lynn/subpubkey.html#rpo

misc. past threads with open/closed & aads/cads:
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#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
http://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
http://www.garlic.com/~lynn/aepay4.htm#privis privacy issues
http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#16 Payments as an answer to spam
http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001g.html#55 Using a self-signed certificate on a private network
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security

Confusing Authentication and Identiification?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/23/2003 12:04 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Confusing Authentication and Identiification?
anders.rundgren@xxxxxxxx on 6/22/2003 1:01 pm wrote:
Lynn,
May I interrupt your crusade against X.509?

I would like to know what you consider redundant in an X.509 certificate.

Is it the account number (Subject DN)?
Is it the public key?
Is it the extension pointing to an OCSP responder?
Or is is rather the CA signature and associated path-validation (and build) that you consider a problem?

Anyway, disregarding the fact that account-based infrastructures have little support in current SW platforms, how would an account-based infrastructure be implemented for an e-government scenario where several millions of citizens (having a state- defined "account number") are served by thousands of independent "e-services"? The X.509 version of this is running in Sweden and uses a number of independent TTP CAs (mostly banks) to provide certificates with the proper "account number".

Anders


============================================================

In the relying-party-only certificates that the financial institutions went to in the mid '90s after the retreat from the forey into identify certificates from the early 90s .... the certificate contained an account number and a public key. In the business process analysis, a relying-party-only certificate is appended to a digitally signed transaction that is sent back to the relying party. Doing an end-to-end business process analysis:

1) the relying-party had the original copy of the relying-party-only certificate stored in the account record

2) for 8583 financial transactions, it was realized that the payload of a typically certificate was 10 to 100 times larger than the transaction itself (aka a certificate containing only an account number and a public key was ten to one hundred times larger than the base transaction payload) 3) the typical signed transaction already contained the account number, making the account number also in the relying-party-only certificate redundant and superfluous

4) since this was a relying-party-only certificate, and only the account number was present, it was was necessary to retrieve the actual account record in order to perform any processing (the certificate just contained a redundant index, i.e. the account number, to retrieve the actual information that was either a) a serious privacy violation to include in the certificate and/or real-time and/or aggregated information that could be loaded into a stale, static certificate built at some point in the past

5) the account record contained the original copy of the certificate, including the public key. so the only other piece of information in a relying-party-only certificate was the public key .... but for relying-party-only transactions with relying-party-only certificates, it was necessary to read the account record that contains the original of the relying-party-only certificate, including the public key. That made transmitting the other piece of information in the certificate, the public key also redundant and superfluous (since it could be found in the account record).

So tt was trivial to show that for relying-party-only certificate that is was possoble to either

1) compress the relying-party-only certificate to zero bytes since it only contained redundant and superfluous information that was easily found elsewhere

or

2) recognized that the relying-party had the original copy of the relying-party-only certificate that would be read with the account record. sending a copy of the relying-party-only certificate to the public key owner so the public key onwer could return the copy of the relying-party-only certificate to the relying-party on every transactions (especially in cases where the size of the relying-party-only certificate was ten to hundred times larger than the size of the base transaction) when the relying-party had the original of the relying-party-only certificate. This could be treated that the relying-party always had the original of the relying-party-only certificate (if you will, effectively cached) .... so it was redundant and superfluous for the public key owner to return a copy of the relying-party-only certificate to the relying-party which had the original of the relying-party-only certificate.

so the issue is that the vast majority of electronic transactions that occur in the financial infrastructure (well over 90%) have SW support for account-based infrastrcutre. There is some amount of internet related SW that aren't well integrated into the fundamental core-infrastructure that tend to be offline PKI oriented rather than online, account, core-business process oriented; possibly since a lot of the internet related SW have been produced by PKI oriented vendors that are interested in pushing their products.

lots of past descriptions of the relying-party-only certificate end-to-end business process scenario
http://www.garlic.com/~lynn/subtopic.html#rpo

specific past threads regarding relying-party-only certificate end-to-end business process description which you participated in:
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#19 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#21 IBM alternative to PKI?
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#26 I-D ACTION:draft-ietf-pkix-usergroup-01.txt
http://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#28 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
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories

Confusing Authentication and Identiification?

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/23/2003 01:51 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Confusing Authentication and Identiification?
anders.rundgren@xxxxxxxx on 6/23/2003 1:15 pm wrote:
Lynn,
Relying-party certificates applied to the described scenario would add a $5-$20 RA cost per user and add extreme user-inconvenience in the [very likely] case a user would need to go to multiple e-government portals. That is, relying-party-only PK schemes, be it account or certificate-based, are not candidates for e-governments communicating with citizens.

In your earlier posting you claimed that account-based schemes could do the same thing as certificate-based dittos; Could you please provide some more data to support this view by applying your thinking to the described TTP-based scenario?
Anders


ok, the previous reference was to three business entities:

1) public key owner ... that sends a self-signed message off to a registration authority

2) a certification authority (CA) that includes a registration authority (RA) that certifies something about the public-key owner's public key (the public-key is basically some form of authentication material that is certified by the CA as being associated with the public key owner). This information is recorded by a CA in some account record

3) the relying party which relies on the CA for validating some assertion by the public key owner.

My assertion is that the above description applies to all of the business models .... whether it is certificate-based or certificate-less based or online or offline.

An example of an online version of the above (modulo the issue of whether public key is the authentication material) is the world-wide debit and credit networks. Another example is the Kerberos which is the basic authentication infrastructure for a multitiude of platforms. Another example is RADIUS which is the majority of the ISPs in the world today.

Modulo the issue of public key issue, the X9.59 standard provides the definition for switching to public key based authentication infrastructure for all electronic retail payments (debit, credit, stored-value, ach, internet, non-internet, point-of-sale, etc)

Modulo the issue of public key issue, the PK-INIT draft for Kerberos defines initial public key authorization for Kerberos.

Modulo the issue of public key issue, there have been several RADIUS implementations that add account-based digital signature authentication to the suite of authentication protocols supported by RADIUS infrastructure.

So the assertion is that the majority of authentication events (even internet) that occur in the world today are fundamentally account-based (modulo some SSL that are primarily certificate manufacturing based, not PKI).

Now back to the original description, even for PKI infrastructures that choose to issue stale, static certificates for situations where the relying-party can't directly contact the certification authority ... as happens in credit transactions, debit transactions, kerberos login and authorization transactions as well as ISP login RADIUS transactions. Fundamentally, a certificate represents some stale, static subset of information that is recorded at the certification authority account record. The purpose of issueing the certificate is to support relying parties that would have no direct or online access to certification authority (as per credit network, debit network, kerberos implementations, radius implementations, etc).

So the fundamental assertion is the reason for the existance of stale, static certificate is to cover situation where the relying party hasn't online and/or realtime connectivity.

A possible issue is that lots of PKI documentation grossly confuse the issue of certifications with certificates. For at least 30 years with online systems, there have been certifications w/o certificates because of the availability of online, realtime connectivity between the relying party and the certification body. Certificates are purely a representation of the certification for use in offline environment.

So a dozen e-government websites could be totally implemented using an account-based, online infrastructure supporting digital signature RADIUS. A RADIUS-based implementation then opens up for selective support of authentication, authorization, permissions, and accounting on a website by website basis.

Confusing Authentication and Identiification? (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/24/2003 11:10 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
Subject: Re: Confusing Authentication and Identiification? (addenda)
slightly related reference to the discussion about differentiating certification from certificates .... where certification can be either online or offline ... it is the business process .... and certificates is a specific delivery mechanism for an offline environment/paradigm.
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"

so an extremely widely deployed internet online authentication mechanism ... that is sort of a subset of online credit/debit is the age verification mechanism in use by the adult entertainment business. Baiscally, having a valid credit card is assumed to be equivalent to a being of age to sign a valid contract. So the online age authentication asks for sign-up/registration by filling in credit card information .... with a disclaimer that nothing shows up on your bill. Basically, they take the credit card information and do whats called a one dollar auth. If there is a positive response from the credit card transaction, the online age authentication service then creates its own account record as to the validity of the entity. In the future, when visiting an adult website, there is a request to do an online transaction with one of the age authentication services .... which then does an online lookup and provides a response to the adult website. FSTC's FAST would have been able to provide something similar directly from the financial institution rather than going through a two-level authentication infrastructure.

note that intrinsicly the 8583 network isn't necessarily a high-overhead transaction. There is wide deployment in the US of magstripe online stored-value mechanism that use the same point-of-sale terminal & network as the credit & debit card transactions; modulo the issue of fraud management, an internet 8583 payment gateway could also handle internet debit and stored-value transactions as easily as it handles internet credit transactions (it isn't a technology issue, it is a business management issue).

another one of the examples is RADIUS authentication server for a multitude of widely deployed relying-parties. An example is some of the large US ISPs that have either their own POPs (point of present); local telephone numbers or contract with other vendors for POPs. This can involve hundreds, if not thousands of routers distributed thru-out the US (and the world). ISP customers may have on the order of a thousand local telephone numbers around the world that they can call and connect to their ISP. Each one of these POPs tends to have local ROUTERs that performs the initial authentication of the incoming call before allowing connection to the ISP services. As mentioned, the numerous POPs may actually belong to the ISP, or belong to some other organization that the ISP has a contractual relationship with. Basically these thousands of routers around the world have direct connection to the ISP's RADIUS server in order to obtain the authentication information as well as various authorization and accounting information. While the extensive use of RADIUS as the fundamental authentication mechanism on the internet is used by PPP for client to ISP connection, the RADIUS service is a generalized facility that can be called by a large number of different operations. For instance, there are typically RADIUS plugins for many of the available webservers that support client authentication via RADIUS service. The use by ISPs of RADIUS for account-based authentication, authorization, and accounting control spanning the world and thousands of servers .... easily exceeds the requirements and demands of any existing e-gov webserver infrastructures.

In fact, given that ISPs supported account-based digital signature RADIUS authentication, and some contractual relationship between a collection of e-gov servers .... it would be possible for e-gov server to directly rely on the ISPs' authentication process w/o requiring a separate e-gov portal authentication service.

Many of the existing e-gov authentication portals basically implement the KERBEROS model with proprietary technology. An e-gov authentication portal could implement a PK-INIT Kerberos digital signature authentication and provide KERBEROS authentication for all the other webservers in a particular e-gov infrastructure. This basically allows for adoptation of standard distributed authentication infrastructure using existing factilities already available on the base platforms that any of the e-gov initiatives are deployed on.

Not only is account-based authentication the dominant and most widely used authentication paradigm in the world today .... but some flavor is built into most of the base platforms.

misc. past descriptions of the one dollar auth scenario
http://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt
http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/2003h.html#18 Authentication protocol
http://www.garlic.com/~lynn/2003h.html#23 Authentication protocol

misc. past RADIUS threads:
http://www.garlic.com/~lynn/subpubkey.html#radius

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

Account Numbers. Was: Confusing Authentication and Identiification? (addenda)

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/25/2003 08:53 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: Account Numbers.  Was: Confusing Authentication and Identiification? (addenda)
this is grossly confusing, dynamic, realtime paradigm with the stale, static, certificate offline paradigm. the credit/debit 8583 online network has worked with multiple "handles" for 30 years or so. You can have dozen of cards ... and each card can actually have one or more account numbers .... you do a transaction and the handle/account number gets filled in appropriately in real time. RADIUS works for corporate accounts and all the ISP accounts. I have multiple accounts and all the appropriate handle/account information is filled in dynamically, its gets correctly routed and processed w/o anybody worrying that it can't work unless I have the same username on my corporate login as well as every last one of my multiple ISP accounts.

The problem with stale, static, certificates that were manufactured at some point way in the past with no real good idea what future purposes that the certificate might be used for. The problem isn't so much that the same certificate wants to be used with huge number of different relying parties .... it was at the time that the certificate was manufactured that a one and only one stale, static account number/handle had to be selected. The issue in the certificate business ... is that certification is somewhat expensive .... and to work with stale, static information ... that can be globally used .... you have to convert the whole-world to a single handle/account number .... or have multiple relying-party-only certificates, one for each environment.

There are at least tens of thousands of financial institutions all issuing account numbers and all getting routed accordingly. It turns out the account numbers are partly routing code and partly individual unique

Extended outside of the financial infrastructure .... to all the ISPs in the world .... frequently you have to configure your TCP/IP client to have a prefix like:
XXXX/username

this in part directs the routers by 3rd party POP operators to deal with the appropriate RADIUS server for the authentication information. So not only does it work for 99.999999999 percent of the online financial trransactions ... but it also works for 99.9999999 percent of the people accessing the internet around the world.

The issue of a globally unique identifier is not a requirement of an online authentication infrastructure. The issue of a globally unique identifier is a requirement for stale, static certificate paradigm with regards to not needing to issue a unique relying-party-only certificate (for every environment) and allowing a single stale, static certificate to used in multiple environments.

Now, for an online environment ... there is context in the type of authorization and the type of message. Now, if i was inventing a single transaction protocol and message interface ... where the same exact message format was used for all contexts .... i.e. a x9.59/iso8583 financial message had the same format as a radius connect to the internet message; then i could hypothosize overloading the entity handle with type of message, type of transaction, type of entity, routing information, and personal information. That way ... I could use the same account number and same message format and same network interface for logging in via RADIUS as I used for performing a credit operation. The network interface could figure out what i intended to do.

anders.rundgren@xxxxxxxx on 6/25/2003 12:53 am wrote:
A problem in this area is the all-over-the-map representation of entities when you go outside of the original (bank) account number. Well, even these show some variances, don't they?

So when Lynn claims that the account number is redudant in for example certificates as it is already in the transaction payload, this is by no means a universal truth if you extend transactions outside of the financial area.

In order to actually eliminate certficates or just be able to match the "account number" (the entity's identity) as expressed in a certificate with transaction payloads we need to have a universal naming method. Currently we don't have that. Even major B2B efforts like ebXML still have not solved this in an non-ambigous way. I.e, it is hard for many people to leave (or rather reduce the importance of) the attribute style of describing an entity's identity like: Locality, Common Name, Phone number etc. That hardly any business system in the world uses anything but a customer ID (account number) is still not generally recognized.

I'm am plotting with an Internet Draft which defines a universal globally unique "account number" consisting of a 2-dimensional structure like the following:

NameSpace : LocalID

NameSpace is a Universal Resource Identifier (URI) that identifies the owner of the "namespace". Samples:
urn:visa:cc
http://xmlns.ibm.com/employees

LocalID is just a string that is guaranteed to uniquely identify the entity in the associated NameSpace. Samples matching the previous sample:
46566777555556766
35467

For X.509 certificates there is a specific extension in preparation that enables the inclusion of such account numbers without disrupting the current use of Subject DN:
             ____
/    \
|  CA  | Naming Domain: http://sample-registry.org/members
\____/  PI Attribute: serialNumber
             /  \
/    \
           /     _\__
|     /    \
|    |  EE  | Subject: CN=John Doe, serialNumber=43155, C=US
|     \____/
         _|__
/    \
       |  EE  | Subject: CN=Marion Anderson, serialNumber=43566, C=US
\____/

That is, Marion's ID could using PI be expressed like:

"http://sample-registry.org/members" : "43566"

As an option the permanent identifier descriptor MAY declare a
separate PI naming domain.


Account Numbers. Was: Confusing Authentication and Identiification? (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/26/2003 10:28 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
As previously outlined, the process used in the financial infrastructure is exactly what the ISPs do for user login. The POPs typically either:

1) a specific phone number select specific router that have a static binding to a specific RADIUS server (this is like walking into your local branch). the selection of the RADIUS server (and the userid selects the appropriate account record) is basically performed by what phone number the client dialed. The phone number used for dialing the ISP service has effectively done the routing specific selection.

2) the client has their PPP software configured with a prefix in front of the userid, something of the form: XXXX/userid. The router then selects the appropriate RADIUS server based on the XXXX prefix. The XXXX prefix has then the equivalent of the routing number part of a financial account number.

In the financial industry, the account number contains both the institutional context (routing number) and account specific information in a single number.

In the ISP industry, the routing context (how to get to the correct RADIUS server account record) is either determined statically by the (initial) physical connection or the routing value for the correct context (XXXX prefix) is supplied as part of the connection transaction.

So we have instance examples of both the financial industry and the world-wide-internet-service-provider industry working exactly the same.

In some past descriptions regarding bilaterial business contracts, a company may do a background check with credit bureau, D&B, and the other company's bank. They then set up an account with various pieces of information regarding the agreed upon business relationship, T&Cs, etc. That account information traditionally shows up on things like purchase orders, etc. Even in the case of past descriptions of SSL domain name certificates, the TTPs are doing D&B checks.

The purpose of a certificate is to carry stale, static subset of information from some account record someplace so that a relying-party can complete a transaction without recourse to the real copy of the information (since if they had recourse to the master account record, the stale, static subset of the information obviously becomes redundant and superfluous).

So lets look at the relying-party-only certificate scenario for performing a transaction w/o recourse to the real, online information:

A transaction is created with the financial account number or ISP login userid (aka some sort of business context specific handle, specific to that environment and transaction). It is digitally signed The relying-party-only certificate is appended and all three pieces (triple) are transmitted. The relying-party receives the transmission and first tries to figure out if they can perform the business process based on only having the triple (again the whole point of a stale, static certificate as a subset/copy of the account information when there isn't recourse to the real information). Lets keep it simple and say that it is only ISP login. The relying-party (ISP) validates the certificate, and then validates that the digital signature with the public key. Everything works. The vulnerability/exploit is that the userid in the LOGIN transaction and some "handle" in the certificate have to match. If the process doesn't require that the two items have some matching value, then theoritically I could sign up for a any random userid at that ISP, get a certificate, and use a valid certificate to login into every userid at the ISP.

This is the traditional chain of trust scenario that is described in almost every description of a certificate-based TTP operation. The relying-party has a table (or set of account records) of trusted TTP public keys. It uses the approprirate TTP public key to verify a presented certificate, it then uses the public key in the certificate to verify the digital signature on some transaction. It then typically uses some information in the certificate (that is bound to the public key) to connect the certificate to the contents of the transaction. This is how financial relying-parties make sure that a person only does withdrawals from bank accounts that they are actually entitled to withdraw from. Just having some random valid certificate doesn't mean that you can perform operations on all accounts at that financial institution.

So the redundant and superfluous scenario is that any present day operation of almost any value typically has the relying-party resorting to real-time access to real-time and/or aggregated information in some account type record. As previously described, financial transactions started 30 some years ago having realtime access to the existing account balance. ISPs do it to have access to currently valid accounts. The transaction specifies necessary and sufficient information to specify the requested operation (including the handle or account number) and the account provides all the information necessary to correctly complete the transaction. Upgrading existing shared-secret based operations to non-shared-secret, replaces a password or PIN on the transaction with a digital signature and replaces the PIN/password in the account record with a public key. stale, static certificates are superfluous in online environment where the relying-party has direct access to the original of the information that provides the context for performing the business process (purchase order, credit card transaction, ISP login). The account record contains all the information necessary to do real-time operation on the business process, including things like authentication information, aggregated information (transactions done to date), real-time information (remaining balance, which could represent a sequence of aggregated operations). In the real-time chain-of-trust scenario, the account number or userid in the transaction indexes the account record, the digital signature on the transaction is validated with the public key in the account record, and the account record provides all the real-time information necessary for the relying-party to complete the transaction.

So, how do you translate that from a relying-party-only certificate operation to a single certificate operation? The traditional chain-of-trust scenario says the transaction contains some handle or identifier; that handle or identifier can be matched in the certificate which shows that the transaction and the certificate relate to the same operation. If it isn't a relying-party-only certificate, but some certificate that has a globally unique identifier ... then has does a single certificate with a globally unique identifier provide the necessary and sufficient trust for a broad range of business transactions from credit card transactions to ISP loging to business purchase order across a broad range of different entities.

The design point (purpose) of (stale, static) certificates was to provide chain-of-trust for performing operations when the relying-party didn't have real-time and/or direct access to the real information. The stale, static certificates were desgned as a sort of stand-in/substitute when the relying-party couldn't directly access the real information.

So instead of authentication, the single stale, static certificate with globally unique identifier would appear to be heading in the direction of identification in place of authentication. Rather than authenticating the public key owner as being authorized to perform a specific operation in a specific business operation .... it would appear that the single, stale, static certificate paradigm with a globally unique identifier is heading in the direction of identification of the public key owner as opposed to authentication of the public key owner (just the semantics of globally unique identifier seems to carry with it the conotation of identification).

Now it is difficult to see how a single, stale, static certificate with a globally unique identifier would provide the necessary business process context (and chain of trust) to indicate that a specific person is authorized to do arbritrary credit card transactions as well as arbritrary ISP logins (where the relying-party is performing this determination in an offline manner w/o access to the real account record).

One might imagine a world of where every valid citizen is authomatically authorized to do everything, once they are identified. All possible transactions only require identification. There are no individual business process that are relying-party specific as to whether a citizen is authorized or not. The global (government?) authority gets forwarded all citizen transactions that occured during the month for the aggregated activities of their identified citizens and reconciles each citizens monthly balance sheet.

Which somewhat gets back to the original subject line regarding is authentication and identification being confused.

anders.rundgren@xxxxxxxx on 6/26/2003 6:27 am wrote:
Global account numbers (entity IDs) are redundant?

Well, that means that business entities must use their partners' unique local account ID when they send for instance a purchase order. It also means that you must keep records of all your business parties local ID of _your_ entity. Having global account numbers you can safely ignore your business partners' account IDs of your business except when you get something in return like an invoice. In those situations it is nice to have the partner's local ID of you, as call- centers usually look on local IDs which are the index in the databases as well.

Only in a relying party PK-model global account numbers become redudant. In such systems you not only need to have the unique local ID but also unique private keys depending on the verifiers policy.

Further advantages with global account IDs is that TTPs can provide services like credit status. This is one of the reasons D U N S is often required in the states. But are D U N S globally unique? In fact they are, it is just that you currently have to _know_ that it is a D&B-assigned number and not some other registry. The described IETF-draft in preparation is designed to solve this by adding a universal "account authority" solution.

My conclusion is that the mechanisms used in the financial industry does not perfectly match the needs of non-payment "transactions".

For list-usage reasons I will though refrain from further discussions on this particular subject.

/ar


Account Numbers. Was: Confusing Authentication and Identiification? (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/26/2003 06:54 PM
To: Todd Boyle <tboyle@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
 internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
the repeated claim in this (and other threads) is that X9.59 eliminates secrecy as requirement to guarantee the integrity of the financial infrastructure (the requirement given the X9A10 working group for the X9.59 standard for all electronic retail payments).

the authentication requirement with x9.59 turns all retail payments into authenticated transactions, eliminates any requirement for any identification information and removes the characteristics of the account number from being a shared-secret (i.e. the account number is currently has the status of a shared-secret, since just by learning the account-number it is possible to execute fraudulent transactions).

The business process issues are

1) is authentication or identification required (as per the original subject line). this can be carefully considered. using the same basic technology, it is fundamentally possible to implement either. it is not an either/or possibility. the government could choose to reliably make your digital signature equivalent to your identity. that is a government and business process choice. however, it is not intrinsicly part of digital signatures. It is possible to create a digital signature infrastructure and protocols that are agnostic to whether the government has created an infrastructure making digital signatures and identity equivalent. The issue that the original subject line highlighted is that frequently the technology of authentication and the implementation choice regarding authentication vis-a-vis identification can be grossly confused and lead to inappropriate implementations. This is one of the reasons that most institutions backed away from the original x.509 identification certificate paradigm, the inclusion of huge amounts of privacy information and indescrimently spraying it all over the world was concluded to not be a good thing.

2) certification is basically a business process that is independent of whether it is deployed as a online process (with online transactions) or manufacturing a stale, static certificate at some time in the past as part of an offline paradigm. The certification body and business reliance can be exactly the same in both cases. The difference is whether the relying-party relies on a stale, static certificate or relies on a real-time, online transaction. It can be trivially shown that in almost all cases the online, realtime responses is both higher quality and more valuable than reliance on stale, static certificates. The absolutely worst case scenario is that the high quality, realtime response is the same as stale, static certificates. So one issue, is does the business justificy the cost of the higher quality operation with an online, realtime response vis-a-vis the possibly lower cost of the stale, static certificate information. Certificates were original targeted in the early '80s when there was not ubiquitous, inexpensive, easily available online infrastructure. As the alternative to having no certification (having NOTHING), certificates were better than NOTHING. However, the trade-off has significantly changed with the technologies of the later 90s with the penetration of inexpensive, ubiquitous, pervasive online infrastructure. This is essentially the transition that the online financial infrastructure made in the '70s (offline to online).

In numerous past discussions, it turned out that many of the issues with a global infrastructure didn't truely require identification, but it for a specific business processes that strong authentication was sufficient and identification was mostly unrelated. For instance, it isn't necessary for all parties even remotely involved in a financial transaction to absolutely know who you are (aka identification) if strong authentication is sufficient to establish that you are the entity entitled to withdraw funds from a specific account (authentication). In fact, one of the additional inducements for financial institutions to retrench to relying-party-only certificates with absolutely no identification information was an EU directive that said that retail electronic transactions should be as anonymous as cash; specifically that at the point of sale, the retail financial transaction needed to be agnostic with respect to identity. That didn't preclude the government from creating some identification procedure but it did direct that the actual financial transaction was agnostic with respect to identity.

As per the original subject line, authentication is about determining is the entity entitled to perform the operation .... without necessarily requiring that the entity also be identified. It doesn't necessarily preclude there being some process for establishing identification, the authentication process can be agnostic with respect to identification.

There are large groups of people on both sides of the argument with regard to having authentication processes that absolutely prevent any identification vis-a-vis the authentication process doesn't preclude establishing identification under specific guidelines. When given a requirement to guarantee transaction integrity, strong authentication is sufficient and KISS to meet the requirement. Again that is the original subject line; confusing authentication and identification.

However, the issue of offline, stale, static certificates as a certification business process mechanism vis-a-vis online realtime (account-based) certification is totally orthogonal to authentication vis-a-vis identification issues.

The business issue for authorizing a transaction in conjunction with an authentication mechanism does come into play a little. I've frequently facetiously referred to an authentication retail store; you walk in authenticate (or even possibly identify) yourself and walk out. The purpose of the retail store is not to actual sell anything, it solely does authentication (possibly identification) operations. This is opposed to retail stores that are there to sell some item, authentication only comes into play when performing a financial transaction (as part of paying for an item to buy). There is nothing that is intrinsicly part of the run-of-the-mill financial retail transaction that mandates identification (there may be other aspects of some retail transactions that mandate identification, but with regard to integrity of the financial transaction, strong authentication is sufficient).

Now, each one of these environments tend to have a specific business context which can be taken into account with regard to an online, realtime certification. The certification authority can examine what is the context of the business process and make the appropriate authentication with respect to that context; aka rights regarding logging as a specific userid, rights to doing financial transactions on a specific account, etc. There could be possibly hundreds of contexts that an online, realtime certification authority could be agile enough to adapt to.

The issue with a stale, static certificates that are manufactured at some time in the past with little or no fore-knowledge as to the business contexts is quite a bit more problematic. There are basically three choices

1) relying-party specific certificates, one for each possible business context, each one providing the specific authentication context (i.e. is the entity entitled to perform that specific operation).

2) we periodically run across things jokingly referred to as GBD ... Great Big Database in the sky ... the mother of all databases that contains all possible pieces of information. This is a certificate that contains the necessary authentication information for every possible business context (is the entity entitled to do the specific operation in every individual business context).

3) switch from an authentication (whether or not the entity is entitled to perform the operation) paradigm to an identification paradigm. The assumption is that all validly identified individuals are entitled to do everything, possibly a log is made of their activities and there is some settlement made by the government at the end of the month (or at some other interval). It then isn't necessary to provide all possible authentications for every possible business context. Everybody, once identified, are automatically entitled. The stale, static certificate is then reduced from having to serve any authentication purpose and is just relegated to only having to perform an identification role.

Trying to establish the value of a PKI stale, static certificate-based operation gets into this muddle. Huge numbers of certificates, one for each context means that the individual value of any specific certificate is significantly depreciated. A single stale, static humongous GBC (great big certificate) gets to become unwieldily having all necessary information for authentication in all possible business contexts (aka whether the entity is entitled to perform the operation). The GBC is also likely to represent more in business costs than can ever be recovered in certificate pricing. So it quickly comes down to that any sort of major PKI infrastructure is pretty much stuck with an identification paradigm. It isn't so much a business characteristic of certification (which i've repeatedly asserted is totally independent of whether it operates as offline, stale, static certificate, or a realtime, online, certificate-less operation). Any major effort at PKI with stale, static certificates pretty much concludes in the identification model (aka #3 above). It is basically what the x.509 identification certificate scenario arrived at in the '80s and the early '90s (effectively because of the considerations outlined above). It is also what was rejected in the mid to late '90s because of the serious privacy issues involved in making a ubiquitous transition from predominately authentication paradigms to a identification only paradigm.

The identification only scenario then still faces the serious business quandary of whether an entity is actually entitled to perform the specific operations in the specific context (independent of identification). GLB, HIPAA and other privacy-related legislation is also turning identification into more and more of a business expense (because of the similar serious privacy issues).

Finally, in normal business, there is a relationship between the provider of something and the purchaser of something. The typical PKI business model is almost a total violation of any existing business infrastructure. In all of the online models, the relying party directly pays the certification agency for the online, realtime certification response. There is a valid, direct business relationship between the relying party and the online certification agency. Tbis gets to be really horrible in the traditional, stale, static certificate scenario. The business relationship is between the PKI and the public key owner that purchases the certificate. There is no exchange of value between the certification authority and the relying-party which would be the basis for a normal accepted business process. In the normal accepted business model today involving a public key owner purchased certificate, there is no exchange of value between the relying party and the certification body, and therefor there would normally be absolutely no recourse for the relying party (based on anything the certification body did or didn't do).

So the traditional PKI paradigm with stale, static certificates left over from the offline paradigm is faced with:

1) significant transition throughout the world from an offline environment to a nearly ubiquitous online environment

2) the whole rejection of x.509 identity oriented stale, static certificates in the mid 90s because of serious privacy concerns.

3) difficult to create any value proposition for a stale, static certificate since there is no business relationship between the relying party and the certification body (the certificate isn't for the benefit of the certificate owner, it is for the benefit of the relying party .... however the relying party that would benefit, isn't paying and therefor under normal business relationships has no recourse to whether the certified information is valid or not).

So the next muddle is since that it really is difficult to establish a viable business model .... turn it into a governement provided identification service. In some sense this isn't an authentication requirement, which can be handled perfectly validly with an online paradigm and suffers none of the shortcomings of a stale, static certificate paradigm.

In some sense, it is a extension of the line of thought that (stale, static) "Certificates Are The Answer" and the government provided identification service might appear to be the only viable way to create a role for certificates. 1) Governments can mandate things and totally ignore issues like the world transitioning to an ubiquitous online environment. 2) Governments can madate things and totally rewrite what are acceptable privacy guidelines and what are not. 3) Governments can mandate things and totally dictate what relying parties will accept.

So lets say we have a government mandated provided identification service based on stale, static certificates. As outlined in the previous post:
http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identification? (addenda)

we have the case of doing ISP login using digital signatures. With the stale, static certificate model, the router on receving the triple (login transaction, digital signature, certificate) should have all the necessary and sufficient information to establish the login operation. The certificate gets validated as a valid, government identification certificate and the public key from the certificate validates the digital sginature; voila the person is connected w/o needing to find out if the entity is entitiled or not (authentication). There is absolutely no requirement for authentication since the government identification certificate is sufficient in establishing the right for service.

So we are led into this muddle that now has both 1) giveronment identification stale, static certificates, and 2) a government identification stale, static certificate is sufficient for authorizing all operations w/o requiring any additional effort.

Now, unless we have created a totally government supplied world for all possible services; there typically are business entities and they establish some sort of business operation for services or products. Today these business relationships are represented by account records. People having contracted for ISP internet service have a RADIUS account record. The logical account record (which may be partitioned into several physical records) typically contains the T&Cs of the business relationship as well as the necessary information to authenticate the entity that is entitiled to use the contracted for service. In the traditional business authentication-based scenario, the entity creates a login transaction with the appropriate authentication information (which I assert can be a digital signature) and the double (aka transaction plus digital signature; not the triple as in the stale, static certificate based scenario) is transmitted. The receiving router gets the username (or other) handle and retrieves the corresponding RADIUS record. The transaction is authenticated with the information in the RADIUS record and then the rest of the information from the RADIUS record indicates the entitled to service. Lack of the appropriate RADIUS record or lack of authentication is an indication that the requesting entity has not contracted for the requested service.

In the offline, stale, static identification certificate scenario, it is sufficient to identify the requesting entity, it isn't actually necessary to establishing that the requesting entity is entitled to the requested service (or is entitled to the explicit or implicit permissions).

so back to the original subject line about confusing authentication and identification:
http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#67 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#69 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#70 Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#71 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)

tboyle@xxxxxxxx on 6/26/2003 12:31 pm wrote:
In the purest sense, an individual is a discrete entity and why should their identifier be a topic of discussion? In every advanced country we already have a name and a government-maintained UID.

The financial industry (and others) needs to end their reliance on secrecy of the UID and associated information per se.

I am uneasy with Lynn's criticism of "stale" digital credentials, since, how else is the individual ever to achieve the capability to identify ourselves over networks?

At times I feel the internet may be truly, fundamentally useless until there is a global and publicly accessible registry of individuals and their public keys. As parties are not strongly identified then, communication about things of consequence is proving to be impractical. Everywhere I look, I see large efforts and investments at the server side, to garner some profit for (increasingly larger) central hosts. I see nothing intended to give the economic benefits of the global internet to individuals or endpoints on the internet.

With great reluctance I am beginning to agree with the European governments' notions of providing a PKI for their citizens. In the US, I believe it would be a good thing if the federal government maintained a network interface where anybody could submit a SSN, and receive in return, the name, address, and public key of the individual.

Todd


x959 Postings and Posting Index, next, previous - home