Is cryptography where security took the wrong branch?
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 10 Sep 2003 08:14:14 -0600
To: bmanning@xxxxxxxx
Subject: Re: Is cryptography where security took the wrong branch?
Cc: lynn@xxxxxxxx (Anne & Lynn Wheeler), cryptography@xxxxxxxx
At 03:39 AM 9/10/2003 -0700, bmanning@xxxxxxxx wrote:
There are some other problems w/ using the DNS.
No revolkation process.
DNS caching
third-party trust (DNS admins != delegation holder)
Since DNS is a online positive list .... you change the database
... and voila it is updated.
This is the scenario for credit cards going from pre-70s technology
with plastic cards and the monthly revokation booklet mailed out to
all merchants. The credit card industry transitioned to online
infrastructure where it transactions are denied by updating the online
database. It eliminates the revokation process, since there aren't an
unknown number of copies of stale, static credentials/certificates
floating around the world potentially being presented to an unknown
variety of relying parties.
DNS caching is the closest equivalent of the certificate paradigm of
stale, static copies floating around the world. The two slight
differences are that cached stale, static entries tend to have very
short lifetimes ... they come into creation by activities by the
relying-party (not the entity being authenticated) and tend to have
very short lifetimes .... of a few hours to at most a day. However,
relying-parties have the choice of going directly to the root and
obtaining the current copy .... a function somewhat filled in the PKI
world by OCSP .... although OCSP is just a check about whether the
current, stale, static copy in a relying-party's possession is current
... not what the current entry is..
From information theory standpoint, stale, static certificates are
logically a form of long-lived, distributed, replicated, r/o, cache
entries. Cache entry semantics have been studied in some detail in
areas like distributed file systems and multiprocessor consistent
shared memory caches, etc. With short-lived r/o, distributed cache
entires (like DNS) ... there is a trade-off involving 1) entry
life-time, 2) frequency of change, 3) impact of dealing with stale
entry. We ran into a problem with doing consistent database updates
over NFS (network filesystem) because while NFS advertises itself as
idempotent, most client implementations have this 8k cache that can
be stale.
Given high value &/or low trust ... relying parties still have option
of directly contacting root authority. And as outline, the root
authority is also the root authority for the CA/PKIs. If you attack
the root trust authority with false information .... then all
subsequent trust operations flowing from that false information is
suspect. Domain name system still has some exploits against the root
database resulting in false information .... but since that is the
root for both DNS as well as CA/PKIs generating SSL domain name
certificates .... it is a common failure point for both
infrastructures. It needs to be fixed, in order to improve trust on
either the DNS side or the CA/PKI side (doesn't matter how thick you
make the vault door .... if somebody forgot to complete the back wall
on the vault).
random, unrelated refs to past life working on processor cache design,
distributed filesystems, and distributed databases
https://www.garlic.com/~lynn/subtopic.html#smp
https://www.garlic.com/~lynn/subtopic.html#hacmp
Is cryptography where security took the wrong branch?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 10 Sep 2003 12:56:05 -0600
To: bmanning@xxxxxxxx
Subject: Re: Is cryptography where security took the wrong branch?
Cc: cryptography@xxxxxxxx
At 09:57 AM 9/10/2003 -0700, bmanning@xxxxxxxx wrote:
ok... does anyone else want to "touch" a secured DNS system
that has some parts fo the tree fully signed? Its a way to
get some emperical understanding of how interesting/hard
it is to hammer the DNS into a PKI-like thing.
www.rs.net has some information.
a normal cache-based system attempts to make everything appear as if
it is online and dynamic .... with the characteristics of information
caching as close as possibly transparent to the relying-parties.
one might claim that PKIs have tried to turn long-lived
certificate-based "cache-entries" into a cult (aka from a information
theory standpoint, certificates are a form of free-standing, somewhat
self-describing, stale, static, long-lived cache entries) .... in part
to create an independent revenue flow based on these cult
objects. standard cache infrastructures usually attempt to go out of
their way to try and make caching operation transparent to
relying-parties (and can dynamically change/eliminate caching details
to meet specific business requirement).
domain name infrastructure needs to support 1) trusted information
distribution and may implement 2) cached entries. DNS has never been
restricted to just trusted information distribution of IP-addresses.
CA/PKI SSL domain name certificates were deployed, in part because of
integrity concerns about the domain name infrastructure. However, the
"trust root" for CA/PKI SSL domain name certificates is still the
domain name infrastructure (as to the authoritative owner of a domain
name).
Turning DNS into a PKI-like thing happens only in the sense that
CA/PKIs have only been a trusted distribution of public keys ... while
DNS has always been a (somewhat) trusted distribution of any
information (that happens to be registered with them). Adding public
keys to DNS distribution is only turning it into a PKI-like thing from
the standpoint that DNS hasn't in the past ben used as a trusted
distribution for public key specific information (and the issue about
the level of trust you can actually have in DNS).
My assertion is 1) DNS integrity issues have to be addressed as part
of generalized DNS trust issues .... regardless of any use for trusted
distribution of information that may include public keys. 2) because
domain name infrastructure is the root authority for CA/PKI SSL domain
name certificates, there is a suggestion that public keys be
registered as part of domain name registration (to fix trust issues in
domain infrastructure on behalf of the CA/PKI industry). Being able to
trust DNS ... and having registered public keys .... means that
existing DNS information distribution operation can turn into trusted
distribution of public keys (aka existing DNS infrastructure supports
distribution of any information that happens to be registered).
some past threads about transition steps for DNS trust .... which
could include having cache entries that instead of being naked public
keys could be digitally signed cache entries (sharing some
characteristics in common to stale, static, long-lived, free-standing
digitally signed certificate objects):
https://www.garlic.com/~lynn/aadsm12.htm#58 Time to ID Identity-Theft Solutions
https://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#36 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm14.htm#17 Payments as an answer to spam (addenda)
https://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
https://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
https://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
https://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow to broadly catch on (addenda)
Resolving an identifier into a meaning
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/11/2003 10:55 AM
To: Todd Boyle <tboyle@xxxxxxxx>
cc: david.berlind@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Resolving an identifier into a meaning.
fyi
some recent discussion of domain name infrastructure in cryptography
mailing list
https://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#3 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#5 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#7 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#8 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#9 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#10 Is cryptography where security took the wrong branch?
and slightly related in sci.crypt newsgroup (some reference to IETF
process and somewhat use DNS references as example):
https://www.garlic.com/~lynn/2003m.html#9 OSI not quite dead yet
and site with some more perspective on DNS
http://www.rs.net/
Going into in more detail in the above postings, one of the issues is
the proposal to register public key at the same time as a domain name
is registered (suggestion somewhat by CA/PKI industry). The current
scenario for SSL domain name certificates .... is that there is some
information stored in the domain name infrastructure database about
the domain name owner and that the domain name infrastructure and the
CA/PKI industry have been totally different business operations. In
effect, a random person presents a request to a CA/PKI operation for a
SSL domain name certificate. The CA/PKI operation then has to check
with the domain name infrastructure as to the true owner of the domain
name, map that information to some sort of real-world identification
and then see if they can map the certificate requester's information
to the same real world identification.
Registering a public key with the domain name registration, then
reduces the problem for the CA/PKI industry to require digital
signature on SSL domain name certificate requests ... and then the
problem reduces to one of authentication ... which is much simpler
than current problem of attempting to match real world
identifications. The process for the CA/PKI industry becomes
enormously simpler if they just have to pull the public key out of the
domain name registration database for request authentication ....
rather than having to go through the significantly more difficult
process of matching up real world identifications.
The problem of real world identification in the domain name
infrastructure then is left to the litigation going on about domain
name squatters ... while requesting a SSL domain name certificate
then is just an authentication issue ... not an identification issue.
tboyle@xxxxxxxx on 9/11/2003 9:58 am wrote:
Regarding David Berlind's "DNS inventor says cure to net identity
problems is right under our nose",
https://web.archive.org/web/20030814211934/http://www.business-standard.com/ice/story.asp?Menu=119&story=20692
The DNS system is but one case of a HUGE class of problems, that
includes all directories, as well as product lists, etc. Resolving an
identifier into a meaning. Mockapetris should google around subjects
like EDI code lists. or recall the X.500 wars, and Microsoft's
campaign of over 10 years
to replace DNS with various directory schemes. Observe the
requirements documents that gave birth to UDDI or ebXML RegRep. And
observe how far THOSE have gotten. :-(
We all want convenience, robustness. But directory information is far too
valuable to trust a single address resolver or to publish in a single
monolithic form, accessible to all.
Clay Shirky writes about IM protocols, phone, fax, email, urls
etc: "people have noticed how valuable it is to own a namespace..."
http://www.shirky.com/writings/dns.html
We're already too dependent on the IP numbering scheme and DNS. DNS
is a POS. It is a single global namespace, yuck, what if there are 2
people named "Smith"? Go away Mockapetris, and all engineers of
top-down hierarchic control. DNS is great but is not the only game in
town.
We need a healthy diversity and competition in addressing schemes and
resolvers. We need more work on the applications layer of the stack,
to give users complete, sovereign control over their end-to-end
conversations. And we need work aligning the information vertically
within
the stack, so that the identity of the ULTIMATE owner of the
conversation is not repeated and reified and abstracted and
translated, fifty different times up and down the stack,
Todd Boyle http://www.ledgerism.net/P2Paxes.htm
contributor, ebXML Core Components Technical Specification
Resolving an identifier into a meaning
From: Lynn Wheeler
Date: 09/11/2003 01:43 PM
To: Todd Boyle <tboyle@xxxxxxxx>
cc: david.berlind@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Resolving an identifier into a meaning.
and to clear up a little confusion in the references in the previous
the OSI reference:
https://www.garlic.com/~lynn/2003m.html#9 OSI not quite dead yet
was in a thread about OSI/ISO vis-a-vis IETF ... using DNS activity as
example of IETF workings.
The thread started by claiming that two major differences between ISO
and IETF vis-a-vis OSI ... were
1) ISO disn't require actual implementation for something to become a
standard (you can get standards that are not actually implementable)
while IETF does
2) ISO attempted to cast OSI in concrete and make a cult of it for the
true bleievers by instructing ISO-chartered standards bodies that they
couldn't standardize networking protocols that violated the OSI model
https://www.garlic.com/~lynn/2003l.html#47 OSI not quite dead yet
Basically OSI model reflected 1960s era technology. To some extent the
ARPANET during the 70s reflected the OSI model. By the early '80s
(when OSI was finally passed, at least) two significant things had
happened:
1) arpanet on 1/1/83 converted to internet(working) protocol
... something that doesn't exist in the OSI model
2) LANs appeared that subsume levels 1, 2, and part of 3 (in the OSI
model) with a MAC interface that sits in the middle of layer 3.
Trying to get HSP (high-speed protocol) considered as standard in the
late '80s in x3s3.3 (iso chartered us body responsible for networking
protocols in OSI level 3&4) .... it had to be turned down. HSP would
go directly from level 4 interface directly to LAN/MAC
interface. Since LAN/MAC violated OSI ... and since ISO proscribed
work on standards that violated OSI model .... it was not possible to
standardize any network protocol that supported LAN/MAC interface.
Resolving an identifier into a meaning
From: Lynn Wheeler
Date: 09/11/2003 05:38 PM
To: Ed Gerck <egerck@xxxxxxxx>
cc: david.berlind@xxxxxxxx, internet-payments@xxxxxxxx,
Todd Boyle <tboyle@xxxxxxxx>
Subject: Re: Resolving an identifier into a meaning.
egerck@xxxxxxxx on 9/11/2003 5:05 pm wrote:
You can further look at IP addresses as being hierarchical, but only
for the purpose of routing on groups of addresses by virtue of their
being assigned to be reachable through some specific address that
looks like it is higher up in the "address tree".
minor note, ip addresses with respect to routing didn't become really
hierarchical until sometime in '95 (???). we had been doing high
availabilitity infrastructures with no single point of failure
.... with multiple attachments to various places in the internet. It
was still possible to advertise ability to get at the same ip-address
via multiple paths. Sometime in '95 ... the infrastructure was getting
to the point that full arbritrary routing tables were too big for most
hardware boxes and there was an infrastructure decision to migrate to
purely hierarchical routing.
At this point no single point of failure implementations were pretty
much left with DNS multiple-A records .... aka DNS having multiple
arbritrary ip-addresses (a-records) for a hostname. As an aside
.... "rotating a-records" came into popularity about that same time as
a partial solution for load-balancing (aka almost all client
implementations always try a-records in the same order ... starting
with the first).
while we had sign-off on the backend implementation part for what was
becoming to be called e-commerce .... i.e. between the merchant
servers and the payment gateway ... and so could require a number of
things .... we had much less influence on the front-end/browser part
of the infrastructure. Typical browser group response was "multiple
A-record support was way too advanced" .... even after we showed them
multiple A-record support from telnet client code in eight year old
BSD 4.3 release. random refs:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
convoluted thread between loosely-coupled, supercomputers,
high-availability, and electronic commerce
https://www.garlic.com/~lynn/2001i.html#52
lots of threads on the HA/CMP product we turned out
https://www.garlic.com/~lynn/subtopic.html#hacmp
Resolving an identifier into a meaning
Refed: **, - **, - **
From: Lynn Wheeler
Date: 09/12/2003 07:48 AM
To: internet-payments@xxxxxxxx
Subject: Re: Resolving an identifier into a meaning.
slight drift a new DNS RFC from Weds..
RFC 3597
Title Handling of Unknown DNS Resource Record (RR) Types
Author(s) A. Gustafsson
Status Standards Track
Date September 2003
Mailbox gson@xxxxxxxx
Pages 8
Characters 17559
Updates/Obsoletes/SeeAlso None
I-D Tag draft-ietf-dnsext-unknown-rrs-06.txt
URL ftp//ftp.rfc-editor.org/in-notes/rfc3597.txt
Extending the Domain Name System (DNS) with new Resource Record (RR)
types currently requires changes to name server software. This
document specifies the changes necessary to allow future DNS
implementations to handle new RR types transparently.
This document is a product of the DNS Extensions Working Group of the IETF.
..... for a more complete list
https://www.garlic.com/~lynn/rfcietff.htm
select Term (term->RFC#) under RFCs listed by
and then seelct "DNS" in the Acronym fastpath
Resolving an identifier into a meaning
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/12/2003 09:03 AM
To: Ed Gerck <egerck@xxxxxxxx>
cc: david.berlind@xxxxxxxx, Ed Gerck <egerck@xxxxxxxx>,
internet-payments@xxxxxxxx, Todd Boyle <tboyle@xxxxxxxx>
Subject: Re: Resolving an identifier into a meaning.
egerck@xxxxxxxx on 9/11/2003 5:05 pm wrote:
You need a better ref ;-)
and yet another sowa reference:
http://www.jfsowa.com/ontology/ontoshar.htm
about the time I was doing some of the system/r (original relational)
support infrastructure and tech. transfer to endicott for sql/ds
https://www.garlic.com/~lynn/submain.html#systemr
i was also helping with some of the support infrastructure for a
semantic network database done as part of a VLSI chip tools effort (at
VLSI lab several miles away). Some of it was influenced by Sowa who
worked for the company at the time.
in another lifetime ... did some work on NLM's UMLS
https://www.garlic.com/~lynn/94.html#26 Misc. more on bidirectional links
http://www.nlm.nih.gov/research/umls/
http://www.nlm.nih.gov/pubs/factsheets/umlssemn.html
Since then we re-created (privately) some of it from scratch and we
use it for the RFC index and the merged glossaries:
https://www.garlic.com/~lynn/
https://www.garlic.com/~lynn/rfcietff.htm
https://www.garlic.com/~lynn/index.html#glossary
total random trivia ... Mockapetris did some work for CSC at about the
same time that "G", "M", & "L" were creating "GML" (aka their
initials; which has since begot SGML, HTML, XML, FSML, SAML,
et. al. ("G", "M", & "L" were all at CSC, 4th floor, 545 tech sq).
https://www.garlic.com/~lynn/subtopic.html#545tech
http://www.oasis-open.org/cover/sgmlhist0.html
https://web.archive.org/web/20230804173255/http://www.sgmlsource.com/history/
http://www.sgmlsource.com/history/G320-2094/G320-2094.htm
Some of the "ML" history thread was that CERN was a large VM/CMS shop
(virtual machines and CMS ... originally cambridge monitor system and
now conversational monitor system ... also originating from 4th floor,
545 tech. sq).
End of the line for Ireland's dotcom star
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 23 Sep 2003 13:45:42 -0600
To: "R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: End of the line for Ireland's dotcom star
Cc: cryptography@xxxxxxxx
At 01:06 PM 9/23/2003 -0400, R. A. Hettinga wrote:
http://www.guardian.co.uk/print/0,3858,4759214-103676,00.html
so ignore for the moment the little indiscretion
https://www.garlic.com/~lynn/2003l.html#44 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#50 Proposal for a new PKI model (At least I hope it's new)
and the part of turning a simple authentication problem into a significantly harder and error prone (along with exploits and vulnerabilities ... not to say expensive) problem:
https://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#7 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#11 Resolving an identifier into a meaning
there has been some past discussions of what happens to long term CA
private key management over an extended period of time, possibly
involving several corporate identities. Checking latest release
browsers ... I find two CA certificates for GTE cybertrust ... one
issued in 1996 and good for 10 years and another issued in 1998 and
good for 20 years.
so lets say as part of some audit ... is it still possible to show
that there has been long term, continuous, non-stop, highest security
custodial care of the GTE cybertrust CA private keys. If there hasn't
... would anybody even know? ... and is there any institutional memory
as to who might be responsible for issuing a revokation for the keys?
or responsible for notifying anybody that the certificates no longer
need be included in future browsers?
New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 29 Sep 2003 08:45:38 -0600
To: Guus Sliepen <guus@xxxxxxxx>
Cc: Cryptography list <cryptography@xxxxxxxx>
Subject: Re: New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
On Mon, 2003-09-29 at 06:07, Guus Sliepen wrote:
TLS makes a distinction between a client and a server. If possible I
wish to avoid making that distinction. If possible, I would also
like to continue to be able to use an RSA public/private
keypair. This made me sketch the following _authentication_
protocol:
... snip ...
Some questions: - Some people keep saying that "you shouldn't send
the same kinds of messages". TLS sends different kinds of messages
depending on its role (client or server). Is there a reason behind
this? - Would it be nice to move all the cryptographic parameters
exchanged in step 1 into the encrypted message in step 2? That way
an attacker cannot see which encryption and digest algorithms will
be used, which might make an attack less feasible. - Did I miss
something?
- TLS both authenticates the server and establishes an encrypted
session in the server part of the transaction.
- The original SSL somewhat assumed that the business requirements
are different for server authentication (and encrypted session)
vis-a-vis client authentication. The original SSL requirement a) was
to give some level of confidence to the client that "the server that
the client thot it was talking to" was actually "the server it was
talking to" and b) provide an encrypted session. There wasn't actually
a threat model requiring proving who you are ... just a threat model
that the server prove that it was who the client supposedly thot it
was.
- SSL was being deployed with a requirement for encrypted session in
an environment where client authentication:
- might not be required
- was not required as part of the transport protocol
- was used to webize/tunnel an existing legacy application
where the client might use userid/password or other
authentication previously established
- wouldn't be public key based because the clients were not
expected to have public/private key pairs and certificates
Some web'ized legacy applications were adopted from a private network
environment ... where the client as part of making the connection
"knew" that it was talking to the correct server. The minimum required
to move that to the wide-open web ... was to provide server
authentication and encrypted session ... and then tunnel the legacy
app thru the encrypted session. The business requirement and threat
model wasn't to invent a brand new environment from scratch ... but to
adapt existing business operations to the wide-open web.
"Mutual" authentication was somewhat an add-on of client
authentication to the base infrastructure. In fact, I think that we
were the first to specify and required the first implementation as
part of the back-end of this thing that has come to be called
electronic commerce.
random electronic commerce refs:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
The trivial e-commerce is that the merchant server didn't really care
who the client was ... just that the client bought something and the
merchant was going to get paid. The merchant needed to provide some
assurance that the credit card transaction being passed thru to the
financial infrastructure was protected. The merchant relied on the
financial infrastructure authenticating the credit card transaction
... and, in fact, any mutual authentication that might be done as
part of the SSL transaction had no impact on the credit card
transaction.
To some extent, both VPN and SSL come into existence about the same
time to satisfy specific business requirement(s) (and in part because
it was taking so long to see any progress with ipsec).
how simple is SSL? (Re: Monoculture)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Adam Back <adam@xxxxxxxx>
Subject: Re: how simple is SSL? (Re: Monoculture)
Cc: Eric Rescorla <ekr@xxxxxxxx>, Don Davis <don@xxxxxxxx>,
"cryptography@xxxxxxxx" <cryptography@xxxxxxxx>,
Adam Back <adam@xxxxxxxx>
Date: Wed, 01 Oct 2003 16:18:10 -0600
At 02:21 PM 10/1/2003 -0700, Adam Back wrote:
Maybe but X.509 certificates, ASN.1 and X.500 naming, ASN.1 string
types ambiguities inherited from PKIX specs are hardly what one could
reasonably calls simple. There was no reason SSL couldn't have used
for example SSH key formats or something that is simple. If one reads
the SSL rfcs it's relatively clear what the formats are the state
stuff is a little funky, but ok, and then there's a big call out to a
for-pay ITU standard which references half a dozen other for-pay ITU
standards. Hardly compatible with IETF doctrines on open standards
you would think (though this is a side-track).
some related recent thread from comp.ssecurity.ssh n.g. (somewhat my
standard harping about confusing the technology of digital signatures
and the business issues of PKI and certificates):
https://www.garlic.com/~lynn/2003m.html#55 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003m.html#49 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003m.html#52 public key vs passwd authentication?
Simple SSL/TLS - Some Questions
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 07 Oct 2003 12:53:59 -0600
To: Jill Ramonsky <Jill.Ramonsky@xxxxxxxx>
Cc: cryptography@xxxxxxxx, ekr@xxxxxxxx
Subject: Re: Simple SSL/TLS - Some Questions
At 05:55 PM 10/3/2003 +0100, Jill Ramonsky wrote:
Having been greatly encouraged by people on this list to go ahead with
a new SSL implementation, it looks like I am going to go for it, but
I'd kinda like to not make any enemies in the process so I'll try to
keep this list up to date with progress and decisions and stuff
... and I will ask a lot of questions.
really KISS/simple SSL/TLS .... given the business requirements for
existing use (as opposed to existing technical specifications for
existing implementations) is to register server's public key and
crypto preferences in DNS .... when client calls DNS to get ip-address
... they can also request public key & crytpo preferences be returned
in the same transmission. for transition purposes, the public key,
crypto preferences, etc .... can exist in a authoritative signed
message by some generally recognized trusted party .... a
mini-certificate (if you will).
the client generates a random session key according to the crypto
preferences, encrypts a credit card number and misc. ancillary
transaction info with the session key, encrypts the session key with
the public key (if you really want to simplify to the business
requirements, directly encrypt with the public key and eliminate the
session key step) .... and use a XTP-like (or some of the emerging
real-time protocol) .... aka existing SSL is carried on top of TCP
.... TCP requires a minimum of 7 packet exchange .... and SSL on top
of that then requires all the negotiation chatter.
Having the public key (& possibly crypto preferences .... unless you
want to directly encrypt with the public key) piggy-back with the DNS
request .... then the actual transaction can be done in three-packet
exchange (i.e. XTP defines a minimum three-packet exchange for
reliable transaction).
This is about as simplified SSL/TLS as you can get based on business
requirements for the major existing applications using SSL/TLS
some past related comments
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
Simple SSL/TLS - Some Questions
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 07 Oct 2003 13:15:18 -0600
To: EKR <ekr@xxxxxxxx>
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
Jill Ramonsky <Jill.Ramonsky@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: Simple SSL/TLS - Some Questions
At 12:09 PM 10/7/2003 -0700, Eric Rescorla wrote:
This doesn't provide equivalent services to TLS--no anti-replay
service for the server.
KISS ... for the primary business requirement .... the application
already has anti-replay .... TLS ant-replay is then redundant and
superfluous.
yes, it isn't existing TLS .... it is KISS TLS based on primary
business requirement ... as mentioned in original, not on existing
specification for existing implementation
https://www.garlic.com/~lynn/aadsm15.htm#19
when doing the original deployment stuff
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
there was the idea in would be used for the whole online
experience. The subsequent comments was that it got cut back to the
current primary use .... because it imposed a five-fold overhead
increase (or reduced a server service capacity by 80 percent).
Making it significantly more simple and lightweight might encourage it
to be used more extensively.
Simple SSL/TLS - Some Questions
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 07 Oct 2003 21:53:32 -0600
Subject: Re: Simple SSL/TLS - Some Questions
To: iang@xxxxxxxx
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
EKR <ekr@xxxxxxxx>,
Jill Ramonsky <Jill.Ramonsky@xxxxxxxx>,
cryptography@xxxxxxxx
At 08:38 PM 10/7/2003 -0400, Ian Grigg wrote:
You are not being fair, Lynn, you are hijacking
the name of TLS, in order to promote a protocol
to protect credit cards.
What you described was practically nothing to do
with TLS/SSL...
Such a protocol would be quite useful no doubt,
but it has little to do with TLS' design goal of
being a full service channel security product.
what i said was that it was specifying a simplified SSL/TLS based on
the business requirements for the primary use of SSL/TLS .... as
opposed to a simplified SSL/TLS based on the existing technical
specifications and existing implementations.
I don't say it was technical TLS .... I claimed it met the business
requirements of the primary use of SSL/TLS.
I didn't preclude that there could be simplified SSL/TLS based on
existing technical specifications as opposed to implementation based
on business requirements for the primary use.
I thot I was very fair to distinguish between the business
requirements use of SSL/TLS as opposed to technical specifications for
SSL/TLS.
There are lots of really great implementations in this world .... many
of which have absolutely no relationship at all with a good business
reason to exist.
The real observation was that in the early deployments of SSL .... it
was thot it would be used for something entirely different ... and
therefor had a bunch of stuff that would meet those business
requirements. However, we come to find out that it was actually being
used for something quite a bit different with different business
requirements.
So a possible conjecture is that if there had been better
foreknowledge as to how SSL was going to be actually be used .... one
might conjecture that it would have looked more like something I
suggest (since that is a better match to the business requirements)
... as opposed to matching some business requirements for which it
turned out not to be used.q
As to usefulness .... I wasn't really trying to claim it would be
useful .... just that it would meet the business requirements of its
primary use.
I've repeatedly claimed that the credit card number in flight has
never been the major threat/vulnerability .... the major threat (even
before the internet) has always been the harvesting of the merchant
files with hundreds, thousands, tens of thousands, even millions of
numbers .... all neatly arranged.
The issue that we were asked to do in the X9A10 working group was to
preserve the integrity of the financial infrastructure for all
electronic retail payments. A major problem is that in the existing
infrastructure, the account number is effectively a shared-secret and
therefor has to be hidden. Given that there are dozens of business
processes that require it to be in the clear at potentially millions
of locations .... there is no practical way of addressing integrity of
such a shared-secret (you could burry the earth to the depth of a
couple miles with cryptography .... and it still wouldn't alleviate
the threat).
It turns out that once the account number is no longer a shared-secret
.... then it is no longer necessary to hide it in order to preserve
the integrity of the financial infrastructure. At that point, a
primary existing use of SSL/TLS goes away completely.
I wasn't really to hijack the protocol .... however, if you wanted to
simplify something based on the business requirements of its use
... then one might consider simplifying based on the business
requirements of its use (even if it became somewhat different). My
strong preference (by several orders of magnitude) is to not do
anything to contribute to delays of eliminating account numbers as
shared-secrets (that would include not contributing to an extreme KISS
TLS other than a hypothetical mental exercise related to business
justification as a reason for doing something)..
I would prefer the primary justification for SSL/TLS to totally
disappear. There then might remain some other uses that could benefit
from SSL/TLS .... and they might not have a need for simplification at
all.
Frequently when simplification is done to something .... you throw
away stuff that isn't needed (at least for the targeted business
purpose). The issue in extreme KISS TLS .... at what point has it
become so simple that it can no longer be TLS ... aka what is the
minimal simple set of things needed for something to still be TLS?
simple result of the x9a10 working group to preserve the integrity of
the financial infrastructure for all electronic retail payments
.... and eliminate account numbers as shared-secrets
https://www.garlic.com/~lynn/x959.html#x959
Trusting the Tools - was Re: Open Source
Date: Sun, 12 Oct 2003 08:25:21 -0600
To: tls@xxxxxxxx
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Trusting the Tools - was Re: Open Source ...
Cc: Bill Frantz <frantz@xxxxxxxx>, cryptography@xxxxxxxx
At 04:27 AM 10/12/2003 -0400, Thor Lancelot Simon wrote:
Not too good. If I knew what the target processor were, I think I could
arrange to do some damage to most general-purpose operating systems; they
all have to do some of the same fundamental things.
This is a bit more sophisticated than what Thompson's compiler did,
but it's the same basic idea. There are some basic operations (in
particular on the MMU) that you can recognize regardless of their
specific form and subvert in a progammatic manner such that it's
highly likely that you can exploit the resulting weakness at a later
date, I think.
remember
- that it is more straight-forward to check assembler generated code
since there is nearly a one-to-one correspondance between the
assembler statement and the generated machine code
- default assembly program generated listings shows assembler
statement and the corresponding generate machine instruction
- the assembler was widely used thru-out the world
- the source of the assembler was available
- there were things like the SLAC assembler enhancements (just
down/up the road)
- people available (like people that did SLAC mods) that had dealt
with the source of the assembler
- some organizations that extensively used such systems that did
study some of these issues in more detail
- people dealing with development and debugging assembler-based
systems normally are operating between the assembler listings (showing
one-to-one between assembler statement and generated machine
instruction) and what appears in memory.
- assembler program listing also summarizes code size .... and is
also frequently and commonly used in manual mapping to memory image.
It wouldn't have been impossible ... but quite unlikely. It is
somewhat easier in C-based programs since there are additional levels
of indirection and obfuscations between the statements in a C program
and the generated machine code.
NCipher Takes Hardware Security To Network Level
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: NCipher Takes Hardware Security To Network Level
To: pgut001@xxxxxxxx (Peter Gutmann)
Cc: astiglic@xxxxxxxx, cryptography@xxxxxxxx, pgut001@xxxxxxxx
Date: Mon, 13 Oct 2003 15:13:42 -0600
At 10:22 PM 10/13/2003 +1300, Peter Gutmann wrote:
So why is this stuff still present in the very latest certification
requirements? Because we're measuring what we know how to measure,
whether it makes sense to evaluate security in that way or not. This
is probably why penetrate-and-patch is still the most widely-used
approach to securing systems. Maybe the solution to the problem is to
figure out how to make penetrate-and-patch more rigorous and
effective...
I would contend that the penetrate-and-patch model is because the
original base was not designed for 7x24, fully interconnected
environment. some slightly related comments on the subject:
https://www.garlic.com/~lynn/2003n.html#14 Poor People's OS
The air force found none of the problems in the studied infrastructure:
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#43 another 30 year thing
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2003i.html#59 grey-haired assembler programmers (Ritchie's C)
https://www.garlic.com/~lynn/2003j.html#4 A Dark Day
the contention is that the system was designed to handle the
circumstances. The currently common distributed software was not
originally designed to handle this kind of situation .... and
repeatedly it has been demonstrated for assurance to work well .... it
has to be designed in from the start .... not added on afterward.
At various times, we had polite competition since the work
referenced in the air force study was done on the 5th floor of 545
tech. sq ... and I was on the 4th floor ... also working on what was
considered a secure (but totally different) system.
https://www.garlic.com/~lynn/subtopic.html#545tech
There were issues about unfair comparison since at the time of the
following .... the totally number of systems ever existing for the 5th
floor system was something over one hundred. The total number of just
internal corporate machines running the 4th floor system was in the
thousands and the number of customer machines were low tens of
thousands. So we just had light hearted competition with regard to
just code I wrote .... and the number of (internal) machines that I
directly provided systems for (something over a hundred ... comparable
to the total number of 5th floor systems).
The following reference was the system that the air force data center
in the pentagon was running was getting old ... and they were looking
at newer hardware, in this case initially twenty newer machines, each
with about the same MIP rate of the aging machine running the 5th
floor system. As referenced, this then turned into 210 such machines:
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
Homeland Security chief mulls SEC cybersecurity filings
From: InfoSec News <isn@xxxxxxxx>
To: isn@xxxxxxxx
Subject: [ISN] Homeland Security chief mulls SEC cybersecurity filings
Date: Tue, 14 Oct 2003 07:21:23 -0500 (CDT)
Forwarded from: Anne & Lynn Wheeler <lynn@xxxxxxxx>
https://www.garlic.com/~lynn/aepay3.htm#riskm Thread Between Risk Management and Information Security
<NOTE: inclusion of the above reference was because the
subject of cybersecurity in SEC fillings was discussed
in some detail at the meeting; also:
https://www.garlic.com/~lynn/aepay3.htm#riskaads AADS & Risk Management, and Information Security Risk Management (ISRM)
http://www.computerworld.com/securitytopics/security/story/0,10801,85888,00.html
Homeland Security chief mulls SEC cybersecurity filings
Companies could be required to detail cybersecurity efforts
Story by Andy Sullivan
OCTOBER 09, 2003
REUTERS
Publicly traded companies could be required to disclose whether they
are doing anything to secure information on their computer systems,
U.S. Department of Homeland Security Secretary Tom Ridge said today.
Ridge said he had met with William Donaldson, chairman of the U.S.
Securities and Exchange Commission, to discuss whether companies
should be required to disclose cybersecurity efforts in their SEC
filings.
[...]
WYTM?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: 10/17/2003 10:05 AM
To: "John S. Denker" <jsd@xxxxxxxx>
cc: David Honig <dahonig@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: WYTM?
On Fri, 2003-10-17 at 00:58, John S. Denker wrote:
Tangentially-related point about credentials:
In a previous thread the point was made that
anonymous or pseudonymous credentials can only
say positive things. That is, I cannot discredit
you by giving you a discredential. You'll just
throw it away. If I somehow discredit your
pseudonym, you'll just choose another and start
over.
This problem can be alleviated to some extent
if you can post a fiduciary bond. Then if you
do something bad, I can demand compensation from
the agency that issued your bond. If this
happens a lot, they may revoke your bond. That
is, you can be discredited by losing a credential.
This means I can do business with you without
knowing your name or how to find you. I just
need to trust the agency that issued your bond.
The agency presumably needs to know a lot about
you, but I don't.
One can claim this is what a credit card does for the consumer .... the
name on the card is somewhat tangential to it being a credential; it is
there so that the merchant can authenticate the credential by cross
checking the name on the card with names on other credentials that you
might be carrying. If you have enuf credentials with the same name ...
then it eventually satisfies the merchant that it is your credential.
Some number of places are taking the name off the card .... as part of
improving consumer privacy at point-of-sale. They can do this with debit
.... where the PIN is a substitution for otherwise proving it is your
credential. however, as previously posted there is a lot of skimming
going an with the information for making a counterfeit card as well as
skarfing up the corresponding PIN.
This is also being done with some kinds of chip cards .... where a PIN
is involved .... but since the infrastructure "trusts" the cards ....
the counterfeit cards are programmed to accept any PIN .... see the yes
card at the bottom of the following URL.
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
access problems, trying wayback machine
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
The issue is that technique used to skim static data for making
counterfeit magstripe cards also applies to skimming static data for
making counterfeit yes cards.
The claim in X9.59 is that the signature from something like an asuretee
card ... can both demonstrate two (or three) factor authentication as
well as proving that the transaction hasn't been tampered with since it
was signed.
In this case, while the card may still look like an (offline) credential
from pre-1970s (with printed credential revokation lists mailled out
every month to all merchants) .... it, in fact does an online
transaction. The digital signature proving 2/3-factor authentication
(and no transaction tampering during transit) is then accepted (or not)
by the financial institution which reports back real-time result to the
relying party (merchant).
This is a move from the ancient offline paradigm that has been going on
for hundreds of years (with credentials as substitute for real-time
interaction) to an online paradigm. While the form-factor may still
appear the same as the rapidly becoming obsolete offline credential; it
is actually operating as a long-distance 2/3-factor authentication
mechanism between the consumer and their financial institution .... with
the merchant/relying-party getting back a real-time response as to
whether the institution stands behind the request.
The difference between the x9.59/asuretee implementation and the "yes
card" implementation is that there is no static data to skim (and use
for creating counterfeit cards/transactions).
misc. x9.59 refs:
https://www.garlic.com/~lynn/x959.html#x959
misc. aads chip strawman & asuretee refs:
https://www.garlic.com/~lynn/x959.html#aads
The integrity of the chipcard and the integrity of the digital signature
substitutes for requiring the merchants to cross-check the name on the
card with the names on an arbitrary number of other "credentials" until
they are comfortable performing the transaction.
The current (non-PIN card) infrastructure is sort of half way between
the old style "everything is a credential" and the new "everything is
online" .... to a fully trusted online infrastructure. The magstripe
does an online transaction and the institution will approve the
transactions with some number of caveats regarding it not being a
counterfeit/fraudulent transaction. For the non-PIN transactions, the
merchant (can) uses the name on the card to cross check with as many
other credential names until the merchant becomes comfortable.
This is similar to the scenario with the existing SSL domain name
certificate issuing process (using names mapping to common/real-world
identities in order to achieve authentication). The domain name system
registers the owner's name. The CA SSL certificate issuer obtains a name
of the certificate requester .... and then the CA attempts to map the
two names into the same real world identities as a means of achieving
authentication. The drastically simpler solution is the domain name
system registers a public key at the same time as registering the domain
name. Then the SSL certificate issuer, instead of having to map real
world identities in order to achieve authentication .... can just use
the registered public key to achieve authentication. The catch-22 is that
if the SSL certificate issuer can use the registered public key for
authentication (instead of the much harder problem of trying to map
names into the same real word identities) ... then lots of other
entities can also use the registered public key for authentication ....
significantly decreasing the need for such a SSL certificate.
The integrity of the chipcard and the integrity of the digital signature
substitutes for requiring the merchants to cross-check the name on the
card with the names on an arbritrary number of other "credentials" until
they are confortable performing the transaction.
recent threads discussing identification when all that is needed is
authentication:
https://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#11 Resolving an identifier into a meaning
SSL, client certs, and MITM (was WYTM?)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: tom.otvos@xxxxxxxx
Cc: cryptography@xxxxxxxx
Date: Wed, 22 Oct 2003 14:27:30 -0600
Subject: Re: SSL, client certs, and MITM (was WYTM?)
On Wed, 2003-10-22 at 13:46, Tom Otvos wrote:
I read the "WYTM" thread with great interest because it dovetailed
nicely with some research I am currently involved in. But I would
like to branch this topic onto something specific, to see what
everyone here thinks.
As far as I can glean, the general consensus in WYTM is that MITM
attacks are very low (read: inconsequential) probability. Is this
*really* true? I came across this paper last year, at the SANS
reading room:
https://web.archive.org/web/20030217202811/www.sans.org/rr/threats/man_in_the_middle.php
I found it both fascinating and disturbing, and I have since
confirmed much of what it was describing. This leads me to think
that an MITM attack is not merely of academic interest but one that
can occur in practice. With sufficiently simplified tools this type
of attack can readily be launched by "script kiddies" or someone
only just slightly higher on the hacker evolutionary scale. Having
said that then, I would like to suggest that one of the really big
flaws in the way SSL is used for HTTP is that the server rarely, if
ever, requires client certs. We all seem to agree that convincing
server certs can be crafted with ease so that a significant portion
of the Web population can be fooled into communicating with a MITM,
especially when one takes into account Bruce Schneier's observations
of legitimate uses of server certs (as quoted by Bryce
O'Whielacronx). But as long as servers do *no* authentication on
client certs (to the point of not even asking for them), then the
essential handshaking built into SSL is wasted. I can think of
numerous online examples where requiring client certs would be a
good thing: online banking and stock trading are two examples that
immediately leap to mind. So the question is, why are client certs
not more prevalent? Is is simply an ease of use thing? Since the
Internet threat model upon which SSL is based makes the assumption
that the channel is *not* secure, why is MITM not taken more
seriously? Why, if SSL is designed to solve a problem that can be
solved, namely securing the channel (and people are content with
just that), are not more people jumping up and down yelling that it
is being used incorrectly? Am I missing something obvious here? I
look forward to any comments you might have.
in general SSL domain name certs address
- is the server I think I'm talking to really the server that I'm
talking to (is the URL I entered match the URL in the certificate)
- key exchange, for an encrypted session
So what purpose would client certificates address? Almost all of the
use of SSL domain name certs is to hide a credit card number when a
consumer is buying something. There is no requirement for the merchant
to identify and/or authenticate the client .... the payment
infrastructure authenticates the financial transaction and the server
is concerned primarily with getting paid (which comes from the
financial institution) not who the client is.
So, there are some infrastructures that have web servers that want to
authenticate clients (for instance online banking). They currently
establish the SSL session and then authenticate the user with
userid/password against an online database.
The fact is .... one contention is that possibly 99.9999 percent of the
client-based authentication that happens in the world today is done
against some database.
There was an instance of a bank issuing client certificates for use in
online banking. At one time they claimed to have the largest issued
PKI client certificates (aka real PKI as opposed to manufactured
certificates).
However, they discovered
- the certificates had to be reduced back to relying-party-only
certificates with nothing but an account number (because of numerous
privacy and liability concerns)
- the certificates quickly became stale
- they had to look up the account and went ahead and did a separate
password authentication .... in part because the certificates were
stale.
They somewhat concluded that the majority of client certificate
authentication aren't being done because they want the certificates
.... it is because the available COTS software implements it that way
(if you want to use public key) ... but not because certificates are
in anyway useful to them (in fact, it turns out that the certificates
are redundant and superfluous ... and because of the staleness issue
resulted in them also requiring passwords).
So a reasonable suggestion was to ship webservers .... with a radius
stub for the client authentication interface. The client registers
authentication material (in much the same way that nearly all of the
ISP authentication infrastructures operate).
If the desire is to have something better than passwords or
shared-secrets (aka trying to help the world address the huge
propagation of number of shared-secrets per person that is occuring in
the online world), then it would be possible to register a public key
in the radius database ... and authenticate with a digital signature
as opposed to a shared-secret.
A certificate is to address the trust propagation between two
entities that have had no prior relationship (and possibly may never
in the future have any sort of relationship) and there is not any
other kind of recourse .... it is purely possible to have digital
signature strong authentication when certificates aren't involved in
anyway what-so-ever.
If you eliminate all the scenarios where the entities have no prior
relationship and/or have no recourse to an online service then you are
pretty much done to a zero set. The scenario with a random customer at
a random merchant website ... never before visited ... the merchant is
interested in getting paid .... the customer contacts their bank
(prior business relationship), the customer bank contacts the merchant
bank (prior business relationship), and the merchant bank contacts the
merchant (prior business relationship) .... to tell the merchant that
they will get paid (aka the real-time response from the financial
infrastructure means a lot more to the merchant than anything that a
random, unknown consumer might claim ... regardless of any possible
redundant and superfluous certificate that might be involved).
SSL, client certs, and MITM (was WYTM?)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: <tom.otvos@xxxxxxxx>
Cc: <cryptography@xxxxxxxx>
Date: Wed, 22 Oct 2003 15:58:33 -0600
Subject: RE: SSL, client certs, and MITM (was WYTM?)
At 05:08 PM 10/22/2003 -0400, Tom Otvos wrote:
The CC number is clearly not hidden if there is a MITM. I think the
"I got my money so who cares where it came from" argument is not
entirely a fair representation. Someone ends up paying for abuses,
even if it is us in CC fees, otherwise why bother encrypting at all?
But that is besides the point.
the statement was SSL domain name certificate is
- am i really talking to who I think I'm talking to
- encrypted channel
obviously #1 addresses MITM (am i really talking to who I think I'm
talking to).
The issue for CC is that it really is a shared-secret and is
extremely vulnerable ... as I've commented before
- CC needs to be in the clear in a dozen or so business processes
- much simpler to harvest a whole merchant file with possibly
millions of CC numbers in about the same effort to evesdrop one off
the net (even if there was no SSL) return on investment .... for
approx. same amount of effort get one CC number or get millions
- all the instances in the press are in fact involved with
harvesting large files of numbers ... not one or two at a time off the
wire
- burying the earth in miles of crypto still wouldn't eliminate the
current shared-secret CC problem
slightly related .... security proportional to risk:
https://www.garlic.com/~lynn/2001h.html#61
so the requirement given the X9 financial standards working group
X9A10
http://www.x9.org/
was to preserve the integrity of the financial infrastructure for all
electronic retail payment (regardless of kind, origin, method,
etc). The result was X9.59 standard
https://www.garlic.com/~lynn/x959.html#x959
which effectively defines a digitally signed, authenticated
transaction .... no certificate required ... and the CC number used in
X9.59 authenticated transactions shouldn't be used in
non-authenticated transactions. Since the transaction is now digitally
signed transactions and the CC# can't be used in non-authenticated
transactions .... you can listen in on X9.59 transactions and harvest
all the CC# that you want to and it doesn't help with doing fraudulent
transactions. In effect, X9.59 changes the business rules so that CC#
no longer need to be treated as shared-secrets.
misc. past stuff about ssl domain name certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
misc. past stuff about relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
misc. past stuff about using certificate-less digital signatures in
radius authentication
https://www.garlic.com/~lynn/subpubkey.html#radius
misc. past stuff about using certificate-less digital signatures in
kerberos authentication
https://www.garlic.com/~lynn/subpubkey.html#kerberos
misc. fraud & exploits (including some number of cc related press
announcements)
https://www.garlic.com/~lynn/subintegrity.html#fraud
some discussion of early SSL deployment for what is now referred to as
electronic commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
SSL, client certs, and MITM (was WYTM?)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: <tom.otvos@xxxxxxxx>
Cc: <iang@xxxxxxxx>, <cryptography@xxxxxxxx>
Date: Wed, 22 Oct 2003 18:36:35 -0600
Subject: RE: SSL, client certs, and MITM (was WYTM?)
At 05:42 PM 10/22/2003 -0400, Tom Otvos wrote:
Absolutely true. If the "only" effect of a MITM is loss of privacy,
then that is certainly a lower-priority item to fix than some quick
cash scheme. So the threat model needs to clearly define who the
bad guys are, and what their motivations are. But then again, if I am
the victim of a MITM attack, even if the bad guy did not financially
gain directly from the attack (as in, getting my money or something
for free), I would consider "loss of privacy" a significant
thing. What if an attacker were paid by someone (indirect financial
gain) to ruin me by buying a bunch of stock on margin? Maybe not the
best example, but you get the idea. It is not an attack that affects
millions of people, but to the person involved, it is pretty serious.
Shouldn't the "server" in this case help mitigate this type of attack?
ok, the original SSL domain name certificate for what became
electronic commerce was
- am I really talking to the server that I think I'm talking to
- encrypted session.
so the attack in #1 was plausably some impersonation ... either MITM
or straight impersonation. The issue was that there was a perceived
vulnerability in the domain name infrastructure that somebody could
contaminate the domain name look up and get the ip-address for the
client redirected to the impersonater.
The SSL domain name certificates carry the original domain name
.... the client validates the domain name certificate with one of the
public keys in the browser CA table ... and then validates that the
server that it is communicating with can sign/encrypt something with
the private key that corresponds to the public key carried in the
certificate ... and then the client compares the domain name in the
certificate with the URL that the browser used. In theory, if all of
that works .... then it is highly unlikely that the client is talking
to the wrong ip-address (since it should be the ip-address of the
server that corresponds to the server).
So what are the subsequent problems:
- the original idea was that the whole shopping experience was
protected by the SSL domain name certificate .... preventing MITM
& impersonation attacks. However, it was found that SSL overhead
was way to expensive and so the servers dropped back to just using it
for encryption of purchase/payment. This means that the client
... does all their shopping ... with the real server or the imposter
... and then clicks on a button to check out that drops the client
into SSL for the credit card number. The problem is that if it is an
imposter ... the button likely carries a URL for which the imposter
has a valid certificate for.
- the original concern was possible ip-address hijacking in the
domain name infrastructure .... so the correct domain name maps to the
wrong ip address .... and the client goes to an imposter (whether or
not the imposter needs to do an actual MITM or not). The problem is
that when somebody approaches a CA for a certificate .... the CA has
to contact the domain name infrastructure as to the true owner of the
domain name. It turns out that integrity issues in the domain name
infrastructure not only can result in ip-address take-over .... but
also domain name take-over. The imposter exploits integrity flaws in
the domain name infrastructure and does a domain name take-over
.... approaches a CA for a SSL domain name certificate ... and the CA
issues it ... because the domain name infrastructure claims it is the
true owner.
So somewhat from the CA industry ... there is a proposal that people
register a public key in the domain name database when they obtain a
domain name. After that ... all communication is digitally signed and
validated with the database entry public key (notice this is
certificate-less). This has the attribute of improving the integrity
of the domain name infrastructure ... so the CA industry can trust the
domain name infrastructure integrity so the rest of the world can
trust the SSL comain name certificates?
This has the opportunity for simplifying the SSL domain name
certificate requesting process. The entity requesting the SSL domain
name certificate .... digitally signs the request
(certificate-less of course). The CA validates the SSL domain
name certificate request by retrieving the valid owner's public key
from the domain name infrastructure database to authenticate the
request. This is a lot more efficient and has less vulnerabilities
than the current infrastructure.
The current infrastructure has some identification of the domain name
owner recorded in the domain name infrastructure database. When an
entity requests a SSL domain name certificate ... they provide
additional identification to the CA. The CA now has to retrieve the
information from the domain name infrastructure database and map it to
some real world identification. They then have to take the requester's
information and also map it to some real world identification. They
then have to try and see if the two real word identifications
match. The recording of the public key for certificate-less
authentication ... not only improves the integrity of the domain name
infrastructure (so that it can be better trusted by the CA industry)
.... but it can also convert a very error prone identification process
for certificates into a simple authentication process.
So now we have the catch-22 clinker for the CA industry (since they
are somewhat sponsoring this whole idea)
- if the certificate-less public key process improves the
integrity of the domain name infrastructure, then one can claim that
the integrity concerns about the domain name infrastructure are
lessoned and therefor the perceived requirement for SSL domain name
certificates is lessoned
- if the CA industry can use the registered public key for
certificate-less authentication regarding domain name related
operations ... then presumably the rest of the world can also
... which would further eliminate justifications for SSL domain name
certificates (i don't need to get the server's public key from a
certificate .... I could get it from a dynamic, trusted, information
distribution utility ... the domain name infrastructure).
as before ... misc SSL domain name certificate related posts:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
the following also have some references to domain name hijacking
events (as opposed to ip-address hijacking):
https://www.garlic.com/~lynn/subintegrity.html#fraud
SSL, client certs, and MITM (was WYTM?)
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: <tom.otvos@xxxxxxxx>
Cc: <iang@xxxxxxxx>, <cryptography@xxxxxxxx>
Date: Thu, 23 Oct 2003 09:43:04 -0600
Subject: RE: SSL, client certs, and MITM (was WYTM?)
Internet group starts anit-hacker initiative
http://www.computerweekly.com/articles/article.asp?liArticleID=125823&liArticleTypeID=1&liCategoryID=2&liChannelID=22&liFlavourID=1&sSearch=&nPage=1
one of the threats discussed in the above is the domain name
ip-address take-over mentioned previously
https://www.garlic.com/~lynn/aadsm15.htm#28
which was one of the primary justifications supposedly for SSL
deployment (am i really talking to the server that I think i'm talking
to).
NSA Buys License for Certicom's Encryption Technology
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: cryptography@xxxxxxxx
Date: Sun, 26 Oct 2003 07:08:27 -0700
Subject: NSA Buys License for Certicom's Encryption Technology
http://www.eweek.com/article2/0,4149,1363251,00.asp
NSA Buys License for Certicom's Encryption Technology
By Dennis Fisher
October 24, 2003
In an extraordinary move, the National Security Agency has purchased a
license for Certicom Corp.'s elliptic curve cryptography (ECC) system,
and plans to make the technology a standard means of securing
classified communications.
As part of the $25 million agreement, the NSA can grant sublicenses
within a limited field of use. This most likely will include other
government agencies, federal contractors and other parties that send
sensitive data to the agency.
... snip ...
Electronic Safety and Soundness: A Four Pillar Approach; Public Policy Issues
Refed: **, - **, - **
From: Lynn Wheeler
Date: 10/30/2003 11:42 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Electronic Safety and Soundness: A Four Pillar Approach; Public Policy Issues
Having made minor contribution to
Electronic Safety and Soundness: A Four Pillar Approach; Public Policy Issues
a new paper appearing soon at:
http://www1.worldbank.org/finance/
in the e-security/e-finance section
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/9f941053fd4293dc852569510022c5a0/77768cb67681ae7c85256d09005807df?OpenDocument
from the Forward:
Over the last decade technological advances have been revolutionizing
the conduct of commerce and financial transactions. Technology has
allowed financial services to be provided to a wider variety of
institutional and retail clients at far lower transaction costs, with
important implications for access to financial services. The advent of
the Internet and advances in cellular, wireless, and satellite
technology have multiplied the possibilities for moving digital
information. Many emerging markets are aggressively adopting advanced
technologies in efforts to bridge the ''digital divide.''
However, the increasing use of these technologies, especially in
emerging markets, is not without risk. These systems, which rely on
computers and the Internet technology backbone, are vulnerable to
rapid, illegal intrusions that can disrupt, disable or corrupt
critical infrastructure such as power, telecommunications, government,
education, hospitals, and financial services. Privacy, security,
safety and soundness are all at stake as service providers race to use
these technologies to integrate functions and services at a higher
speed and reduced cost. In a series of papers starting over three
years ago, staff in the Financial Sector Operations and Policy
Department in the World Bank have investigated the links between
technology advances and financial sector development and access to
financial services, with a particular emphasis on electronic security
(esecurity) concerns.
past refs to world bank papers:
https://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
https://www.garlic.com/~lynn/aepay12.htm#25 Cyber Security In The Financial Services Sector
https://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
https://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature
VS: On-line signature standards
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/31/2003 08:56 AM
To: pekka honkanen Welho <lhonkane@xxxxxxxx>
cc: 'Anders Rundgren' <anders.rundgren@xxxxxxxx>,
'internet-payments' <internet-payments@xxxxxxxx>
Subject: Re: VS: On-line signature standards
as i've mentioned before certificates have very little to do directly
with digital signatures .... they are a mechanism for trust
propagation ... akin to the letters of credit from the days of sailing
ship .... where the relying party had no direct and/or online
knowledge of the signing party and no direct and/or online access to
the certifying party.
however, the scenario for the financial relying-party-only
certificates issue that were distributed during the 90s .... are
analogous to requiring that when I go into my bank branch office to
negotiate with the branch manager .... I first go into my bank branch
office and talk the branch manager into giving me a letter of credit
credential to introduce me to some stranger, relying party .... I then
leave the bank branch, re-enter the same bank branch and go to the
same branch manager and present the letter of credit credential (that
they just created) as a prelude to the branch manager doing business
with me.
There has been some past discussions with regard to certificates that
carry a non-repudiation indication and something that has been
severely depreciated. I believe originally, there was some desire to
differentiate to unknown, relying-parties (aka strangers) the
difference between the entity's use of keys for data hidning and keys
for authentication. These are effectively totally different business
processes relying on the same technology. However, one issue in the
difference in the business processes is that data hiding (encryption)
keys tend to require that the private key be escrowed (for business
continuity reasons) and the business processes for authentication
requires that the private key never be divulged. However, there seemed
to have been some aggradizement of the business process authentication
concept to non-repudiation.
One of the things seen (in at least the cal. state electronic
signature law and the US federal electronic signature law) is that
there is a somewhat explicit deliniation between demonstrating
intention (as required by things like contract law and
non-repudiation) and authentication. A digital signature can
demonstrate authentication (and exists totally independently of
whether certificates exist or not as part of providing trust
propagation to relying party strangers). However, it is pretty clear
than to demonstrate intention and/or agreement that there is a lot
more required (to form basis of valid signature ... as per law)
... and also has resulted in depreciation of any reference to
non-repudiation with regard to X.509 ... since there is nothing
(little?) in X.509 that provides the basis for non-repudiation. The
electronic signature law references a bunch of stuff required for a
valid/binding legal signature and non-repudiation ... and it has
little or nothing to do directly with "digital signatures"
... therefor the more general reference being made to "electronic
signatures" (as well as nothing to do with the need for trust
propagation as represented by certificates). It is possible for
"digital signatures" to be used in conjunction with other things to be
a valid "electronic signature" ... however there are a number of
other authentication methods that can be used in conjunction with
intention/non-repudiation operations that also satisfy the requirement
for "electronic signature".
to some extent a digital signature is purely a demonstration of one or
two factors from the three factor authentication model:
• something you have
• something you know
• something you are
A valid digital signature might demonstrate that possibly you possesed
a hardware token that contained a unique private key that existed no
place else in the world (or say a file that resides on your harddisk
containing the private key). The use of the private key to generate a
digital signature establishes one factor authentication as something
you have.
This might be improved by having hardware tokens that contain a unique
private key and require a unique PIN to be entered before they
operate. Given that the characteristics of the hardware token can be
established, then a digital signature by such a hardware token may be
considered as demonstrating two-factor authentication (the token as
something you have, and entering the correct PIN as something you
know).
More complex tokens can require both a PIN and a biometric ..... for
3-factor authentication; the application of the digital signature
(given that the characteristics of the token can be prooved) can
demonstrate 1) something you have (the token), 2) something you know
(correct PIN entered), 3) something you are (correct biometric
entered).
Notice that the really critical issues about the level of trust with
regard to authentication goes up with the factors involved .... and
has nothing at all to do with cretificates and/or the concept of trust
propagation.
With regard to legal, trusted signature .... the issues of
demonstrating intention and/or non-repudiation are a critical issue
(independent of things like digital signatures, and quite definitly
independent of of issues of trust propagation and certificates) as
well as the level of trust in the authentication mechanism
(i.e. number of factors, possibly evaluation of hardware token, etc
.... again having no relationship at all with regard to trust
propagation and certifictaes).
given the foundation for strong demonstration of authentication and
strong demonstration of intention and non-repudiation .... then one
might consider certificates as mechanism for trust propagation for the
benefit of relying party strangers (assuming an unconnected, offline
infrastructure where the relying party stranger has no prior knowledge
of the signing entity and/or no recourse for contacting the certifying
authority) .... but the existing certificates do little or nothing to
address the level of trust in the authentication mechanism and/or the
level of trust in the non-repudiation mechanism.
a few past threads related to 3-factor authentication:
https://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm14.htm#23 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
a few past threads specifically related to non-repudiation:
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
lhonkane@xxxxxxxx on 10/31/2003 2:18 am wrote:
http://www.fineid.fi/default.asp?todo=setlang&lang=uk
this is a link to an interesting multimedia presentation on the Finnish
government - banks - telcos joint project on using the government produced
certificate on bank and telco issued cards.
Pekka Honkanen
-----Alkuperäinen viesti-----
Lähettäjä: Anders Rundgren [mailto:anders.rundgren@xxxxxxxx]
Lähetetty: 30. lokakuuta 2003 23:46
Vastaanottaja: internet-payments
Aihe: On-line signature standards
Here is some information related to Internet payment gathered
from a poll made to the IETF-PKIX, IETF-SMIME, and the OASIS
PKI-TC lists regarding the current state of on-line signature standards
=====================================================
There are apparently no standards and nothing in the works either
with respect to signing on-line data on the web using Internet browsers.
=====================================================
Since web-signing is today [*] used by many, many, more people
and organizations than there are users of signed e-email, I remain puzzled.
Is the PKI community really just a bunch of "nerds", mostly out of
touch with the needs of the market?
And what good is a legal framework like the EU signature directive,
intended to address "legal interoperability" if there is no interoperability
in the technical solutions?
"The truth is [still] out there" to travesty a famous TV series.
However, my request spurred quite a lot of interest, so I believe that web-
signing really is a thing that finally will be standardized. The question
is more by who, as the major interest is really coming from the public
sector, not from commercial entities like banks, that rather protect their
investments in proprietary solutions. I personally plan to pusue such
a task in W3C or in OASIS in case somebody is interested.
*] Like Scandinavian banks having > 0.5M of users.
All current systems rely on entirely proprietary mechanisms.
Most of the vendors even require NDAs for getting the documentation.
Anders Rundgren
VS: On-line signature standards
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/02/2003 08:03 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "'internet-payments'" <internet-payments@xxxxxxxx>,
"pekka honkanen Welho" <lhonkane@xxxxxxxx>
Subject: Re: VS: On-line signature standards
But the only business purpose for certificates is for trust
propagation associated with offline operations (where the relying
party has no access to the real and timely information and therefor
must make do with stale, static copies).
In the payment card scenario .... the merchant
- doesn't need the public key since it relies on the issuer for an
online authentication & authorization
- the account number is already part of the transaction
- the account number already routes to the issuer
- doesn't need the issuer's signature on a ceritifcate since it
doesn't need the contents of the certificate and therefor doesn't need
a signature on something that it doesn't need
the merchant needs what's defined in X9.59 ... i.e. the data elements
of the transaction and the customer's signature on the transaction
... all for forwarding to the issuer.
https://www.garlic.com/~lynn/x959.html#x959
so that is the 3rd party scenario.
also, as previously outlined .... the issuer doesn't need a copy of
the issuer's certificate since the issuer already has the original and
therefor it is redundant and superfluous for the customer to
send a copy of something back to the issuer where the issuer has the
original. If you prefer, the description of of how to handle zero byte
certificates;
https://www.garlic.com/~lynn/aepay2.htm#position
also how it is redundant and superfluous to transmit
relying-party-only certificates back to the relying-party
(i.e. since the issuing institution already had the original)
https://www.garlic.com/~lynn/subpubkey.html#rpo
however the original thrust of the postings was to do with the
foundations of trust ... as opposed to the foundations of
trust propagation .... certificates are a method of
trust propagation .... which is a separate business issue from
establishing trust with regard to the validaty of electronic
signatures.
A digital signature can be viewed as part of a business process for
establishing the basis for the business process of electronic
signatures, specifically the authentication part of establishing
electronic signatures. Legal electronic signatures require (at least)
things like
- authentication
- non-repudiation
- demonstration of intent and/or agreement
Authentication can be thought of in the context of three-factor
authentication:
- something you have
- something you know
- something you are
So an electronic signature trust taxonomy
- authentication
- something you have
- something you know
- something you are
- non-repudiation
- demonatration of intent and/or agreement
Now I see no situation where certificates play in the above trust taxonomy.
Assuming the basis for electronic signature trust operation can be
established .... then in business process that need trust
propagation in an offline environment where the relying-party has
no other recourse, then one could conjecture the business process need
for a stale, static credential like a certificate. previous
posting
https://www.garlic.com/~lynn/aadsm15.htm#32
As per above .... it is pssobile to establish a digital signature
infrastructure which can be used to infer something you have
(like an encrypted private key software file or a private key hardware
token) and possibly something you know (an PIN to access the
private key that performs the digital signature). There is even a
possibility for digital signature infrastructure that can be used to
infer something you are (i.e. a certified hardware token that
does digital signatures, but requires biometric input). Again there is
no concept of a certificate and trust propagation associated
with the use of digital signatures to establish the basis of
authentication as part of a electronic signature trust business
process. Do you know where certificates infrastructures mention
three-factor authentication and/or anything to do with
something you have and/or something you know operations?
Certificates have to do with the business process of trust
propagation for offline environment where the relying party has no
other recourse. They appear to have little or nothing to do with the
actual business process of trust and establishing the legal
acceptable basis for business process of electronic signatures.
My perception is that e-government is an attempt to establish an
online infrastructure, where-as certificates address the business
process of establishing an offline infrastructure (where there is no
recourse to online and/or timely information). One might even make
that the assertion that demanding the creation of constructs that
satisfy business requirements for offline infrastructure only confuses
and probably actually obstructs the establishment and
understanding of what the fundamental constructs are needed for online
business processes.
anders.rundgren@xxxxxxxx on 11/2/2003 2:23 am wrote:
No, they work as a convenient "handle" to both the citizen and to
the issuers using various revocation mechanisms. To have a
unique relation with thousands of authorities is impossible from
an economic point of view no matter how good it may be.
But there is indeed a certain redundancy in certificates!
It would be technically enough that a signature contained
1. the public key
2. a claimed ID (account number
3. a link to the issuer
4.the signature itself
But this reduction of data would not have such a dramatic impact as
far as I can see. Well, it would delay the introduction of e-government
services a few years of course.
VS: On-line signature standards (slight addenda)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/02/2003 09:15 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 'internet-payments' <internet-payments@xxxxxxxx>,
pekka honkanen Welho <lhonkane@xxxxxxxx>
Subject: Re: VS: On-line signature standards (slight addenda)
a little more clarification for electronic signature taxonomy
- authentication
- something you have
- something you know
- something you are
- non-repudiation
- demonstrate intent and/or agreement
The typical, traditional use of certificates are to indiscriminately
broadcast them at the slightest propagation. As a result, there can be
hundreds or thousands of copies of a particular certificate floating
around the world.
Digital signatures as part of a authentication business process is
looking for being able to uniquely infer
- something you have
- something you know
- something you are
now, if I have a hardware token that contains a private key and
performs digital signatures .... and the hardware token can be
certified as containing a unique private key and highly resistant to
allowing a duplicate of that private key to be copied .... then when a
digital signature is performed, then one might infer that it is in the
possession of the individual owning the hardware token. From the
appilcation of a digital signature, one might infer that it is in the
possession of the token owner and therefor infer one-factor
authentication, something you have.
The possession of a digital certificate doesn't carry the same weight,
since it has been established that there are possibly thousands of
copies floating around the world .... so it can't be the basis of
one-factor, something you have authentication.
Now, if the hardware token is also certified to work in a
specific way when a PIN is supplied, then it might be plausable to
infer two-factor authentication when such a hardware token
performs a digital signature, aka two-factor authentication;
something you have (the hardware token) and something you
know (the PIN for the hardware token). As a side-note, such a PIN
is not a shared-secret since it need not be divulged to any
other entities (than the token owner). The PIN and token may be
assumed to be unique as the basis for establishing two-factor
authentication; something you have and
something you know.
The possession of a digital certificate doesn't carry the same weight,
since it has been established that there are possibly thousands of
copies floating around the world ... so the contents of a digital
certificate can't be the basis of two-factor, something you
have and
something you know, authentication.
Similarly, the existance and/or possession of a certificate also
doesn't infer something you are authentication.
The assertion is that certificates are part of support of an offline
paradigm, providing stale, static copies of information for trust
propagation.
VS: On-line signature standards
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/02/2003 10:11 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 'internet-payments' <internet-payments@xxxxxxxx>,
pekka honkanen Welho <lhonkane@xxxxxxxx>
Subject: Re: VS: On-line signature standards
anders.rundgren@xxxxxxxx on 11/2/2003 9:29 am wrote:
Lynn,
To convert everything into a payment system is not a good way
to discuss things. Identity <<>> Payment.
So an "issuer" in the ID-world has no reason to ever get
client signatures as the only thing an issuer of IDs can vouch
for is the binding between a "name" (a.k.a. account number)
and a public key. That means that in an ID-world using TTPs
the transferal of the user's public key as a part of a
"transaction" is indeed necessary. To use account numbers
for issuer lookup does not work in an ID-world either as
the very same account number (citizen name) may be issued.
That is, my name is not "Anders Rundgren, cid=4545454,
@bigca", only "Anders Rundgren, cid=4545454".
hum, lets see, what is the mailing list ... hum, it seems to be
internet-payments?
to the extent the previous posts had a discussion of a specific
payment related scenario .... it was in response to a specific example
you gave regarding possible compression of information in
certificates.
the original post and the majority of the subsequent posts was discussing
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
basis for valid acceptable electronic signature. as mentioned before
.... I outlined previously .... there was a discussion of
authentication .... specifically a commonly acceptable taxonomy for
authentication, namely three-factor authentication:
- something you have
- something you know
- something you are
within the context of a acceptable legal electronic signature having to do
with
- authentication
- non-repudiation
- proving intent and/or agreement
so I strongly assert that
- authentication
- something you have
- something you know
- something you are
- non-repudiation
- proving intent and/or agreement
is not converting everyting into a payment system. It is trying to
establish the basis for discussing, valid, legal electronic
signatures.
I possibly mistakenly assumed that with the subject line of on-line
signature standards that just plausably there was some room for
discussing valid, legal, electronic signatures?
Futhermore, given that this particular mailing list is specifically
titled internet-payments .... it wouldn't be completely unacceptable
to include a single example of electronic signatures within the
context of a payment system?
The subject of identity is yet to come up?
VS: On-line signature standards
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/02/2003 01:49 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "'internet-payments'" <internet-payments@xxxxxxxx>,
"pekka honkanen Welho" <lhonkane@xxxxxxxx>
Subject: Re: VS: On-line signature standards
anders.rundgren@xxxxxxxx on 11/2/2003 10:58 am wrote:
Lynn.
The problem in my opinion is that your ideas regarding the
non-utility of certoficates is maybe another discussion
than the legality of signatures. To the latter I have a fairly
basic comment: Before the advent of signatures, legality
in the e-world was not a major issue. To require three-
factor authentication is fine but unlikely to work very
as the basis for legal actions as you cannot trace the DNA
of signer in the signature, sort of. Biometric have one
possibly good application and that is as a protection
against misuse of a signature device. Like featured
on some of the more advanced HP PDAs. It may
also work in bank vaults etc. However, as a over-
the-net mechanism I believe biometrics is no good.
Anders
Again, I believe you are grossly mis-interpreting what I posted.
I've constantly asserted that certificates were originally designed to
address trust propagation in an offline environment and continue to be
used to address situations where the relying party has no other
recourse for the information.
I've also repeatedly provided numerous examples of having been
somewhat instrumental in the currently deployeed major use of
certificates:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/subpubkey.html#sslcert
So I can't understand your reference/assertion to my ideas regarding
the non-utility of certificates.
So hopefully not to miscontrue you statements as red herrings met to
obfuscate and misdirect .... i assert that in order to establish
valid online signatures .... you first need to relate a valid online
signature to a valid electronic signature. I assert that the paradigm
and framework for valid electronic signature (needed to establish a
valid online signature) is
- authentication
- something you have
- something you know
- something you are
- non-repudiation
- proove intent and/or agreement
and that digital certificates are extraneous to that core
paradigm. digital certificates can be added to a valid electronic
signature framework as part of trust propagation for relying parties
in an offline environment and/or relying parties have no other
recourse to the information.
so another possible misdirection is the statement about
"over-the-net" mechanism, I believe biometrics is no good.
I'm somewhat assuming that you are relating biometrics and something
you are authentication. so, to examine your assertion, lets further
expand the valid, legal, electronic signature taxonomy:
- authentication
- something you have
- something you know
- shared-secret
- non-shared-secret
- something you are
- shared-secret
- non-shared-secret
- non-repudiation
- poove intent and/or agreement
so a possible two-factor authentication implementation
something you have and something you know. One such existing
traditional mechanism is a magstripe debit card and a
shared-secret PIN. The debit card is inserted, prooving
something you have and you enter a PIN (which is passed to the
processor) prooving something you know. Separate from the
paradigm/taxonomy analysis, a vulnerability analysis has crooks
skimming both the magstripe data from the card and the PIN ... and
creating counterfeit magstripe cards with the PINs written on
them. Obviously such static data technology implementation doesn't
translate well to on-the-net; not because of some flaw in the taxonomy
but flaws in the technology and implementation.
Another vulnerability of the current infrastructure is (because
possibly of shared-secret human factors reason) a significant
percentage of the population write the PIN number on the card. That
significantly defeats the attempt to have two-factor
authentication (separate something you have and
something you know); but it is a fact of life given the
existing proliferation of shared-secret infrastructure and the
related human factors.
So one proposal is to replace PINs with fingerprints (especially for
the large percentage of the population that write their PIN on the
card). So the comparison becomes for this particular vulnerability
scenario ... which is easier:
- easier for the crooks (existing major fraud) to skim the magstripe
information and use a video camera to record the PIN entry, produce a
counterfeit magstripe card with the PIN written on it, and then
perform fraudulent transactions with the counterfeit card and the
recorded PIN
- easier for the crooks (existing major fraud) to skim the magstripe
information and use a video carmea to record the fingerprint entry,
produce a counterfeit magstripe card with the fingerprint written on
it, and then perform fraudulent transactrions with the counterfeit
card and the recorded fingerprint.
And for the other vulnerability scenario where a crook steals the actual
card, which is easier:
- earier for the crooks to steal a real card with the PIN written on
it and perform a fraudulent transaction with the real card by entering
the PIN recorded on the card
- easier for the crooks to steal a real card, possibly with latent
fingerprints, and perform a fraudulent transaction with the real card
and lift the latent fingerprint, produce a counterfeit fingerprint
from one of the latent fingerprints on the card and enter the
counterfeit fingerprint during the fraudulent transaction.
I assert in both cases, that for the comparison of this particular
case of two-factor authentication .... the something you are
scenario is more difficult for the crooks than the something you
know scenario.
So the financial industry biometric standard, x9.84 talks about the
security needed for transmitting a biometric value over a network
(from point of entry to backend processing) and the necessary security
precautions necessary to protect the biometric value from both
external attacks like evesdroppers as well as internal attacks
(eimployees, business operations). It describes fairly stringent
security .... which I assert would be pretty much the same whether it
is a private VAN or a public internet operation. The fundamental issue
is that PINs, biometrics (and even account numbers) are effectively
shared-secrets .... anybody evesdropping (external attacks or
internal attacks) and harvesting the information may be able to use it
for fraudulent transactions.
A big concern is that PINs as shared-secrets allows for value change
in cases of compromise while it is quite a bit harder to achieve a
change when a biometric value has been compromised.
So lets go back and look at the reference to being able to infer one,
two, and/or three factor authentication based on a digital signature
..... warning slight topic drift
I've observed frequent semantic confusion because the "label"
given to private key encryption of a secure hash includes the word
signature, which has significantly different meaning when used
in a legal sense. A digital signature is not a valid, legal electronic
signature ... even though the two terms happen to share the word
signature. A "digital signature" can be used to infer something
about one, two, and/or three factor authentication as part of a
valid electronic signature paradigm .... but a "digital signature" is
not a valid legal electronic signature (and to go even further afield
.... a digital certificate is even less a valid, legal electronic
signature than a digital signature is). A few past refs to semantic
confusion
https://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/2003k.html#6 Security models
I assert that I can certify some component (like a hardware token)
that will execute a digital signature .... and from the existance of
that digital signature, it can be inferred that somebody possesses
that token (one factor authentication, something you have).
Such hardware tokens can be built and certified that also provides the
grounds for inferring something you know and/or something
you are. Furthermore, the construction and certification of such
a component can be done that the something you know and/or
something you are changes from a shared-secret paradigm
(as discussed above) into a non-shared-secret paradigm.
The construction and certification of such a token can be such that
based on the token generating a digital signature, it can be inferred
that the correct PIN was entered (something you know) and/or an
acceptable biometric evaluated (something you are). It is not
necessary to transmit the token, the PIN< and/or the biometric over
the network. The device can be constructed in such a way .... that
from the existance of a particular digital signature ... that the
token was in somebody's possession (something you have
authentication) and possibly that the entered the correct PIN
(something you know authentication) and/or provided the correct
biometric for the token to evaluate (something you are
authentication).
I've repeatedly asserted that a digital signed protocol can be defined
where there is some information that carries a digital signature.
The level of trust in that digital signature can be based on a whole
set of business process factors that are totally independent of the
protocol carrying the digital signature. The trust and weight given
that digital signature can be an issue of the construction and
certification of the device and environment creating the digital
signature ... independent of the digital signature itself (as well as
independent of whether any number of associated digital certificates
happen to exist).
Furthermore, I assert with technology like "match on chip", the use of
biometrics can be done as a non-shared-secret paradigm and w/o
any biometric information flowing over any network. The issue of the
level of trust with regard to one factor, two factor, and/or three
factor authentication and the method and environment for
generating PINs and/or biometrics is related to the technology used
.... and can be totally independent of the protocol for carrying a
digital signature and/or whether or not there is a redundant,
superfluous, stale, static certificate carried along also.
Aka ... i assert the issue of something you are authentication
can be implemented as a business process involved in certifying a
specific kind of digital signature generating device and transparent
to the actual authentication transport (aka whether or not there has
been something you are authentication is inferred from the type
of device that generates the digital signature, in much the same way
that something you have authentication is inferrred from the
device that generates the digital signature).
VS: On-line signature standards
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/02/2003 02:22 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "'internet-payments'" <internet-payments@xxxxxxxx>,
"pekka honkanen Welho" <lhonkane@xxxxxxxx>
Subject: Re: VS: On-line signature standards
oh, i before I forget ... some misc. passed discussions of biometrics,
shared-secrets, and non-shared-secrets:
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
https://www.garlic.com/~lynn/aadsm10.htm#bio5 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio7 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio8 biometrics (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
https://www.garlic.com/~lynn/aadsm14.htm#23 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay11.htm#22 FBI Probing Theft of 8 Million Credit Card Numbers
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/99.html#189 Internet Credit Card Security
https://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
https://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#61 I-net banking security
https://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
https://www.garlic.com/~lynn/2002f.html#45 Biometric Encryption: the solution for network intruders?
https://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
https://www.garlic.com/~lynn/2002m.html#14 fingerprint authentication
https://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2003e.html#47 Public key and the authority problem
https://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
https://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003m.html#0 Passwords multiply as users' rage rises
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
FAQ: e-Signatures and Payments
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/12/2003 10:16 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Re: FAQ: e-Signatures and Payments
Basic beginning security 101 is that anytime that you fail to have
end-to-end security and integrity of the operation ..... you open
things to failure and fraud (this can because that the security and
integrity mechnaims doesn't follow the complete end-to-end operation
of the transaction and/or the integrity and authentication mechanisms
are separated from the actual transaction and/or both).. financial
industry x9.59 standard (to preserve the integrity of the financial
infrastructure for all electronic retail payments in all environments)
X9.59 has end-to-end transaction authentication and integrity
operation. I think that you've confused authentication, integrity and
reliable signatures again. Note that the X9.59 standard defines the
necessary transaction fields for a reliable end-to-end signed
transaction. The actual standard doesn't define the signing mechanism.
The appendix of the X9.59 standard contains a mappings of the X9.59
standard to existing payment infrastructures and signing
mechanisms. One such example mapping is:
https://www.garlic.com/~lynn/8583flow.htm
lots more references to X9.59 (including pointer to how to obtain the
actual X9.59 standard document):
https://www.garlic.com/~lynn/x959.html#x959
The X9.59 does define the fields in terms of ASN.1 encoding .... but
there is also work on defining the fields in terms of XML
encoding. The issue of ASN.1 encoding vis-a-vis XML encoding, is that
the end-points needed to establish and verify the integrity of the
transaction, but also allow the actual data fields to be carried in
various formats defined by the actual payment network (w/o unnecessary
duplication of information and the associated inefficiency). At the
time of the standard, ASN.1 provided for deterministic encoding of
values i.e. given that the originating end-point and the terminating
end-point were going to encode the same values, they had to come up
with the same bit-representation (aka the objective was to allow that
the originating end-point and the terminating end-point arrive at the
identical encoded bit-representation to prove values had not been
altered during transmission and/or processing). There was work in FSTC
(the organization sponsoring this mailing list) on FSML which provided
an extension to XML for deterministic bit encoding of values for the
same reason done by X9.59 .... that the originating end-point and the
terminating end-point could arrive at the same bit-representation (w/o
mandating the format of the values during transmission). The FSML work
has since been encorporated into XML signature work for supporting
deterministic encoding rules. An example tagged encoding is included
in the above appendex URL reference mapping. There is proposal that
X9.59 standard now be updated to include both ASN.1 encoding and XML
encoding (with the enhanced deterministic encoding rules from FSML).
random past authentication and/or end-to-end transaction threads that
you participated in:
https://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
https://www.garlic.com/~lynn/aadsm4.htm#10 Thin PKI won - You lost
https://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
https://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
https://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#pcards5 FW: The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
https://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate? (addenda)
https://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit-card payment question
https://www.garlic.com/~lynn/aadsm11.htm#20 IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#29 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm11.htm#31 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm11.htm#38 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm12.htm#4 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#6 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#7 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
https://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt
https://www.garlic.com/~lynn/aadsm12.htm#42 draft-ietf-pkix-warranty-extn-01.txt
https://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#56 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
https://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories
https://www.garlic.com/~lynn/aadsm14.htm#6 The case against directories
https://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
https://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook to SET Standard
https://www.garlic.com/~lynn/aepay6.htm#gaopki3 GAO: Government faces obstacles in PKI security adoption
https://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
https://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
https://www.garlic.com/~lynn/aepay6.htm#dspki2 use of digital signatures and PKI
https://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
https://www.garlic.com/~lynn/aepay6.htm#userauth2 MS masters NC mind-set (authentication is the key)
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay10.htm#17 Visa 3-D Secure vs MasterCard SPA Whitepaper (forwarded)
https://www.garlic.com/~lynn/aepay10.htm#34 some certification & authentication landscape summary from recent threads
https://www.garlic.com/~lynn/aepay10.htm#35 some certification & authentication landscape summary from recent threads
https://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards
https://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#69 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#70 Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#71 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#2 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process, payment, authentication and identification
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
anders.rundgren@xxxxxxxx on 11/12/2003 9:15 am wrote:
Maybe it is a bad idea to respond to your own postings but I give it a
try -:)
A logical consequence with the stuff below is that things like EMV,
and X9.59 has no bright future as they cannot support a reliable
signature mechanism except on a cryptographic level. But 3D Secure
can! And 3D Secure is just the first shot in this direction.
Stay tuned
/a
----- Original Message -----
From: Anders Rundgren
To: internet-payments
Sent: Wednesday, November 12, 2003 09:08
Subject: FAQ: e-Signatures and Payments
Extract from an FAQ for an on-line e-signature standards proposal in
progress:
...
That is, DRY Signatures are neither useful nor intended to be used
where the signature requester is unknown or maybe even untrusted by
the user. Does not the "trusted service provider" limit usability?
Although this may be considered as a serious disadvantage of DRY
Signatures, the same limitation is actually applicable to just about
all on-line systems, as both on-line "receipts" and automatic
client-side archival of "evidence" are usually missing. That is, the
user must indeed rely on the service provider to cater for trustworthy
handling of the data involved. Newer on-line payment systems, like
VISA's 3D Secure, address this in a very elegant fashion by instead of
requiring users to sign transactions directly to possibly unreliable
merchants, instead routes payment requests to the user's own trusted
and known bank (issuer). By doing that, users can be reasonably
assured that transaction requests are archived, and that signature
requests will always be in the same format as well as in a language
that the user understands. This scheme even allows fraudulent
merchants to be automatically blocked by the bank.
Regards
Anders Rundgren (Editor)
FAQ: e-Signatures and Payments
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/12/2003 09:20 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Re: FAQ: e-Signatures and Payments
i think you have it confused again.
x9.59 defines fields that require verified integrity and
authentication. so does the e-check project done by FSTC.
you can show x9.59 transactions in a user-friendly way ... sign
transactions in ASN.1 (and soon XML and send them in ASN.1, XML, 8583,
ach, etc.
as i outlined in the previous posting and numerous times previously in
past treads .... X9.59 (and e-check) define fields and encoding
mechanism for supporting verifying the integrity of the tranasaction
as well authenticating the transaction.
as I mentioned in the previous posting and numerous times previously
in past threads ... x9.59 (and e-check) allow the fields to mapped
into existing infrastructures and then be reconstructed for intetrity
verification and authentication.
security 101 teaches end-to-end security and integrity of
operation. when integrity of operation is broken .... either with
missing and/or fragmented security and possibly multiplicity of
different operations .... then at least complexity and opportunity for
fraud and additional failure modes are increased and/or
introduced. Simple 101, kindergarten security principles.
For example, separating the actual transaction operation from the
authentication and integrity checking might result in the transaction
operation being executed independently of the authentication and
integrity checking. Trying to match up transaction operation which
might be done in one network on one time-scale .... with
authentication and integrity operations that is done in a completely
different network and different time-scale creates opportunities for
things being out of sync, having different failure modes, extreme
complexity of matching up operations in one context with operations in
a totally different context. One of kindergarten, security 101 things
tend to be KISS .... the less KISS and the more complex .... the more
prone the infrastructure is to additional failure (and fraud) modes.
All other things being equal .... KISS always wins out over complexity
for the sake of complexity. Adding a electronic signature to an
existing 8583 transaction .... so the integrity of the 8583
transaction can be checked and authenticated by the issuing bank
.... significantly beats out any process that would send a 8583
transaction via one infrastructure .... and any sort of electronic
signature via a totally different infrastructure .... and then expect
that the issuing financial institution has to match up authentication
and integrity material with a totally independent 8583 transaction
that is being processed via totally different infrastructure.
For instance, lets say I walk in the store and do an X9.59 transaction
with a chipcard. The issuing financial institution gets an electronic
signature along with the 8583 transaction, check the authentication
and integrity of the transaction, checks the other information related
to the transaction and sends back a real time approval. The merchant
then lets me walk out with the merchandise.
I would assert that any change that you would make to the above description makes it less KISS, more complex, and less secure.
anders.rundgren@xxxxxxxx on 11/12/2003 12:57 pm wrote:
The problem with this is the unnecessary narrow definition of end-to
-end security.
# Going through a possibly fraudulent merchant's systems to reach
my bank is indeed end-to-end security but pretty useless such unless
the thing you sign is exactly what is sent to the bank. This is for
many reasons not very practical. At least not on the net.
Using 3D Secure et al you don't have this restriction. I.e. you can
show transactions in a user-friendly way but send transactions in
ASN.1 or XML. Still signatures can be verified towards the
transaction data if you have the transaction- to-viewable-format
transformation logic.
# If I can't trust my bank for performing a transaction on my behalf
I could well do without the bank altogether. Anyway this is what
hundreds of millions people do on their on-line banks so I can
hardly see that it is impossible or security-wise wrong.
Anders
FAQ: e-Signatures and Payments
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/13/2003 08:39 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: FAQ: e-Signatures and Payments
OK, the requirement for X9.59 was to insure the integrity of the
financial infrastructure for all electronic retail payments
... that is ALL as in ALL. So there was a demo of X9.59
at 1999 BAI in webstore configuration:
https://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
so lets say there are paranoid people that don't trust the merchant
terminal .... then I assert the operation of X9.59 with cellphone/PDA
with the cellphone/PDA using BLUETOOTH or WI-FI (or other wireless
interface) to the merchant terminal ... has exactly the same process
steps as a personal computer at home using the Internet (aka personal
device to merchant, merchant device to financial infrastructure).
the two issues with regard to merchant terminal have been covered in
past posts 1) is what you see, what you sign and 2) skimming any
entered "what you know" or "what you are" authentication
information. This is also referenced is some number of FINREAD
related previous posts (appended).
I wasn't referring to whether or not banks were used as trusted
providers ... the refernece and the accompanying description was about
the actual flow of the transaction and the actual flow of the
authentication and integrity information.
Of course banks can be trusted providers
The original statement (and subsequent statements) were with respect
to security protcool analysis and elementary security guidelines.
The original statement (and subsequent statements) was that (all other
things being equal), that if the process isn't an integral end-to-end
operation then it is
- less KISS
- more complex
- less secure
- more prone to failures
- more prone to fraud
The above assertions about elementary security principles are
independent of whether banks as trusted providers are involved or
not. To that extent, comments about banks as trusted providers are
somewhat orthogonal and obfuscation with respect to elementary
security principles.
minor reference some EMV stuff
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
past threads (that you participated in) which involved FINREAD
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
https://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm15.htm#38 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
other related threads mentioning FINREAD:
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
https://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
https://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature
https://www.garlic.com/~lynn/2003j.html#25 Idea for secure login
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
anders.rundgen@xxxxxxxx on 11/13/2003 12:45 am wrote:
Sure, X9.59 or EMV is problably just fine at least as long as you trust the
terminal where you insert your chip-card. However, on the Internet
using a web-store X9.59 end-to-end is anything but ready for prime-time.
And the interesting thing is that the Internet approach (3D) MAY one day
find its way down to the brick-and-mortar shop as it makes no sense to
long-term have multiple infrastructures for payments.
I guess we can agree on this last line at least? And then agree on that
it will be "the battle of the payment systems". Or has somebody already
won? I don't think so.
>I would assert that any change that you would make to the above
>description makes it less KISS, more complex, and less secure.
To me using banks as trusted providers, authenticators and archievers
seems like KISS as this is what banks have been doing since day #1.
/anders
AADS Postings and Posting Index,
next, previous
- home