- 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:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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):
http://www.garlic.com/~lynn/2003m.html#55 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003m.html#49 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003m.html#52 public key vs passwd authentication?
Simple SSL/TLS - Some Questions
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
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
Simple SSL/TLS - Some Questions
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
http://www.garlic.com/~lynn/aadsm15.htm#19
when doing the original deployment stuff
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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
http://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:
http://www.garlic.com/~lynn/2003n.html#14 Poor People's OS
The air force found none of the problems in the studied infrastructure:
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#43 another 30 year thing
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2003i.html#59 grey-haired assembler programmers (Ritchie's C)
http://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.
http://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:
http://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>
http://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:
http://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.
http://www.smartcard.co.uk/resources/articles/cartes2002.html
access problems, trying wayback machine
http://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:
http://www.garlic.com/~lynn/x959.html#x959
misc. aads chip strawman & asuretee refs:
http://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:
http://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
http://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:
http://rr.sans.org/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:
http://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
http://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
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
misc. past stuff about relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
misc. past stuff about using certificate-less digital signatures in
radius authentication
http://www.garlic.com/~lynn/subpubkey.html#radius
misc. past stuff about using certificate-less digital signatures in
kerberos authentication
http://www.garlic.com/~lynn/subpubkey.html#kerberos
misc. fraud & exploits (including some number of cc related press
announcements)
http://www.garlic.com/~lynn/subintegrity.html#fraud
some discussion of early SSL deployment for what is now referred to as
electronic commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
the following also have some references to domain name hijacking
events (as opposed to ip-address hijacking):
http://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
http://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
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:
http://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
http://www.garlic.com/~lynn/aepay12.htm#25 Cyber Security In The Financial Services Sector
http://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
http://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.
<