List of Archived Posts

2005 Newsgroup Postings (5/18 - 5/31)

More Phishing scams, still no SSL being used

Brit banks introduce delays on interbank xfers due to phishing boom

Certificate Services

General PKI Question

Authentication - Server Challenge

Blinky lights WAS: The SR-71 Blackbird was designed ENTIRELY

Blinky lights WAS: The SR-71 Blackbird was designed ENTIRELY

Improving Authentication on the Internet

More Phishing scams, still no SSL being used

More Phishing scams, still no SSL being used

Revoking the Root

Revoking the Root

The Worth of Verisign's Brand

The Worth of Verisign's Brand

The Worth of Verisign's Brand

Now the crackpots are trying to make it their own

Outsourcing

The Worth of Verisign's Brand

Outsourcing

Improving Authentication on the Internet

First assembly language encounters--how to get started?

The Worth of Verisign's Brand

technical question about fingerprint usbkey

The Worth of Verisign's Brand

The Worth of Verisign's Brand

technical question about fingerprint usbkey

The Worth of Verisign's Brand

REPOST: Authentication, Authorization TO Firewall

REPOST: Authentication, Authorization TO Firewall

Improving Authentication on the Internet

Status of Software Reuse?

Improving Authentication on the Internet

Improving Authentication on the Internet

Improving Authentication on the Internet

The Worth of Verisign's Brand

The Worth of Verisign's Brand

Improving Authentication on the Internet

Secure FTP on the Mainframe

More Phishing scams, still no SSL being used

Behavior in undefined areas?

Friday question: How far back is PLO instruction supported?

The 8008

Development as Configuration

Development as Configuration

SqlServerCE and SOA - an architecture question

The 8008

Friday question: How far back is PLO instruction supported?

Listserver for DFSMS/HSM

defeating firewalls made easy

Where should the type information be?

XOR passphrase with a constant

Regarding interrupt sharing architectures!

Single Password - Linux & Windows

Single Password - Linux & Windows

More Phishing scams, still no SSL being used

From:  <lynn@garlic.com>
Date: Wed, 18 May 2005 16:52:20 -0700
Newsgroups: netscape.public.mozilla.crypto
Subject: Re: More Phishing scams, still no SSL being used...

Peter Gutmann wrote:

This assumes that the OCSP responder has access to live CA
data. Many responders are fed from CRLs, so you get the illusion of
a quick response with all the drawbacks of a CRL (OCSP was specially
designed to be 100% bug-compatible with CRLs, a much better name
for it would be Online CRL-Query Protocol).  As one PKI architect
put it, "Being able to determine in 10ms that a certificate was good
as of a week ago and not to expect an update for another week seems
of little, if any, use to our customers".

there was this small client/server startup in menlo park that wanted to
payment transactions on their server.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

that had this thing they called SSL. in the year that we worked with
them, they moved from menlo park to mountain view and changed their
name from mosiac to netscape (trivia question: who owned the term
"netscape" at the time?).

as part of doing credit card payments ... we specified that the
webservers and the payment gateway had to do mutual authentication
(this was before there was any thing like mutual authentication defined
in ssl).

along the way, we realized that the certificate part was essentially a
facade since the payment gateway and the allowable webservers required
conventional business processes for managing their relationship
... and that having certificates was purely an artifact of the
existing code being implemented that way (as opposed to the public key
operations relying on more traditional repositories for access to
public keys).

This was also in the period that we coined the term ;certificate
manufacturing to distinquish the prevalent deployment of certificates
from the descriptioins of PKIs commoningly found in the literature.

The juxtaposition of credit card transactions and PKIs were also
startling. The common accepted design point for PKIs were the offline
email model from the early 80s ... where the recipient dialed their
electronic post office, exchanged email and hung up. They then could
be faced with attempting to deal with first time email from total
stranger that they had never communicated with before. A certificate
filled the role of providing information about total strangers on
first contact when there were no other resources available (online or
offline ... aka the letters of credit paradigm from sailing ship
days).

imagine four quadrunts defined by offline/online and
electronic/non-electronic. in the 60s, the credit card industry was in
the upper left quadrant; offline and non-electronic. They mailed out
monthly revokation lists to all registered merchants. With new
technology they could have moved into the offline/electronic quardrant
(the online/non-electronic quadrant possibly not being
practical). However, in the 70s, you saw the credit card industry
moving directly to the online/quadrant where they had real-time,
online authorization of every transaction. In the mid-90s when there
were suggestions that the credit card industry could move into the 20
century by doing PKI, certificate-based transactions ... I got to
repeatedly point out that would represent regressing the credit card
transaction state of the art by 20-30 years ... back to the
non-electronic archaic days of offline transactions and the mailed
revokation booklets.

It was sometime after having repeatedly pointed out how archaic the
whole PKI & CRL paradigm actually was that OCSP showed up on the
scene (when real-time, online facilities are actually available). It
is somewhat a rube-goldberg fabrication that attempts to gain some of
the appearance of having modern, online, real-time transactions
... while trying to preserve the fiction that certificates (from the
offline & electronic guardrant) are even necessary.

The problem is that the original design point for PKI, CRLs, etc ....
the offline & electronic guardrant is rapidly disappearing in the
always on, ubiquitous internet connected environment.

The other market niche that PKIs, CRLs, etc have sometimes attempted
to carve out for themselves has been the no-value transaction sector
...  where the value of the transaction is not sufficient to justify
the (rapidly decreasing) cost of an online transaction. The problem
with trying to make a position in the no-value transaction market
... is that it is difficult to justify spending any money on CAs,
PKIs, certificates, etc.

some amount of past posts on SSL certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

Another facet of the SSL certificate market has to do with SSL
domain name server certificates (probably the most prevaling
use). One of the justifications for SSL domain name server
certificates were concerns about the integrity of the domain name
infrastructure. So browsers were setup that would check the domain
name in a typed in URL against the URL in a server certificate.

The business scenario has a certificate applicant going to a
certificate authority (CA) to apply for an SSL domain name server
certificate. They supply a bunch of identification ... and the
certification authority then attempts the expensive, complex and
error-prone process of matching the supplied identification
information with the domain name owner identification information on
file with the authoritative agency that is responsible for
domain name ownership (aka the domain name infrastructure).

Now it turns out that the integrity concerns with the domain name
infrastructure can extend to the domain name owner information on file
... putting any certification process by a certification authority
(for ssl domain name certificates) at serious risk.

So somewhat from the certification authority industry, there is a
proposal that when people get domain names, they register a public
key.  All future communication with the domain name infrastructure is
then digital signed and verified with the onfile public key (purpose
is to improve the overall integrity of the domain name
infrastructure). SSl certificate applicants can also digital sign
their SSL certificate applications to a certification authority. The
certification authority can retrieve the onfile public key (from the
domain name infrastructure) to verify the digital signature on the
application which turns a complex, expensive, and error-prone
identification process into a much simpler, less expensive, and
reliable authentication process.

However, there is a couple catch-22s for the PKI industry. First,
improving the integrity of domain name infrastructure medigates some
of the original justification for having SSL domain name certificates.
Also, if the certification authority can build the trust basis for
their whole operation on the onfile public keys at the domain name
infrastructure ... it is possible others might realize that they could
also do real-time retrieval of onfile public keys as part of the SSL
protocol ... im place of relying on certficate-based public keys.

Brit banks introduce delays on interbank xfers due to phishing boom

From: <lynn@garlic.com>
Date: Thu, 19 May 2005 08:43:17 -0700
Newsgroups: news.admin.net-abuse.email
Subject: Re: Brit banks introduce delays on interbank xfers due to phishing boom

Vernon Schryver wrote:

That is a popular and well established brand of snake oil peddled by
the usual suspects including PKI vendors.  Authentication by itself
cannot stop phishing any more than it can stop spam.  Authentication
is only part of authentication and authorization.  Phishers would react
to digitally signed legitimate banks mail just as spammers have reacted
to SPF, by digitally signing their bait.  If banks used PKI certificates
for the key distribution problem, then phishers would buy throw-away
$350 certs from Verisign to go with their $10 throw-away domain
names....if they're not already doing that to make HTTPS to their web
sites look safe to the suckers.

nominal ID theft involving skimming/harvesting some form of static
data that can be used for fraudulent transactions. nominally there is
some differentiation between

1) id theft involving static data that can be turned around and used
to perform fraudulent transactions on existing acctouns
(authentication risk)

2) id theft involving static data that can be turned around and used
to establish new accounts or operations (identification risk)

With the extremely prevalent use of static data resulting in both
authentication and identification fraud ... there has been lots of
skimming/harvesting going on. This skimming/harvesting can be viewed
of being of two forms .... skimming/harvesting data-in-flight and
skimming/harvesting data-at-rest.

Typically SSL (encrypted sessions) is viewed as a countermeasure for
the skimming/harvesting data-in-flight threat. While
skimming/harvesting of data-in-flight has been observed in other
environments ... there seems to be little evidence of
skimming/harvesting (evesdropping) of internet data-in-flight (aka
seems to be much more theoritical issue). There appears to be lots of
excamples of skimming/harvesting data-at-rest .... large databases of
people information and/or things like merchant transaction files ....
slightly related reference ... security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61

A large proporition of threats lumped under ID theft actually involve
static data used for authentication fraud (aka fraudulent transactions
on existing accounts as opposed to identification fraud ...
establishing new accounts in the victim's name).

In the three-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

id theft involving static authentication data is frequently something
you know. This is the pin/passwords. Another example is your mother's
maiden name or SSN frequently used for authentication purposes.

These forms of static data authentication are frequently also referred
to as shared-secrets (aka pin/passwords) and learning the
shared-secret is sufficient to impersonating the victim in faudulent
transactions on their existing accounts. While payment cards fall
nominally into the something you have authentication ... their
magstripes represent static data that has frequently been involved in
skimming/harvesting activities where it enables the manufactur of
counterfeit cards. In security terms, shared-secrets and/or static
data infrastructures are also subject to replay attacks (i.e. fraud
from recording the shared-secret or static data and simply replaying
what was recorded).

Skimming/harvesting of large "data-at-rest" databases of personal
information has represented a significantly large return-on-investment
for the crooks (cost of the attack vis-a-vis expected fraud enabled).
there have been recent studies that claim at least 77 percent of these
kinds of exploits involve insiders.

Phishing attacks involve getting unsuspecting victims to voluntarily
give up their static data or other forms of shared-secrets. The
internet have provided the crooks with technology for phishing attacks
that start to compare with traditional skimming/harvesting of
data-at-rest in terms of fraudulent return on investment (cost of
attack vis-a-vis amount of fraud enabled).

Traditional security technique for limiting exposure of pin/password
(or other forms of static data shared-secrets) is to require that a
different unique shared-secret be used for every unique security
domain. Among others, this is a countermeasures to insider
skimming/harvesting shared-secret in one domain and then using it in
another domain (aka high school kid working for the local garage ISP
getting your connection password ... and being able to use the same
password with your home banking account).

Phishing attacks involve getting unsuspecting and naive victims to
voluntarily give up such information (heavily leaveraging internet
technology to attack large numbers of people at very low cost and
risk).

Possible countermeasures to phishing attacks involve

1) education of large numbers of potential victims,
2) minimizing crooks ability to impersonate authorities as part of
convincing people to divulge their information
3) minimizing the use of static data in authentication paradigms ...
people can't divulge information that they don't know.

Note that the last countermeasure is also countermeasure for the
skimming/harvesting attacks (frequently by insiders) ... where there
is no shared-secrets or static data that can be havested by crooks to
replay in future fraudulent transactions.

The extensive use of shared-secrets and static data is also vulnerable
to humans unable to cope with rapidly increasing number of
shared-secrets that they must memorize (for authentication purposes).
many individuals are faced with electronically interacting with scores
of unique, different security domains, each requiring their own unique
password.

The PKI highlighted in recent post to the PKIX mailing list:
http://www.garlic.com/~lynn/aadsm19.htm#11 EuroPKI 2005 - Call for Participation

is that the majority of activity involved in PKIs seem to revolve
around certification activity related to producing a certificate.

In 3-factor authentication model, the verification of a digital
signature with a public key can be viewed as a form of something you
have authentication ... aka the subject has access and use of the
corresponding private key producing the digital signature. PKIs are
not required in order to deploy a public key authentication
infrastructure
http://www.garlic.com/~lynn/subpubkey.html#certless

The use of public key authentication operations can eliminate much of
the burden and exposures associated with shared-secrets and static
data infrastructures; knowledge of the publc key is not sufficient to
impersonate the victim; 1) eliminates exploit of skimming/harvesting
static data for use in replay attacks or fraudulent transactions and
2) eliminates requirement to have a unique public key for every
unique, different security domain. In the static data, shared-secret
paradigm the same value (pin, password, mother's maident name, etc) is
used for both originating the request as well as verifying the request
http://www.garlic.com/~lynn/subintegrity.html#secrets

A public key can only be used for verifying the request ... it can't
be used for originating the request. Divulging a public key is not
sufficient for a crook to be able to perform a fraudulent transaction.

However, some forms of public key operations are still subject to
phishing attacks. Many public key deployments have the private key
resident in a software file. Phishing attacks involve convincing the
victims to perform various operations ... typically giving up
information that enables the crook to perform fraudulent operation.
However a phishing attack could also invole getting the victim
(possibly w/o even knowing what they are doing) to transmit their
software file containing a private key or shared-secret.

So one (public key environment) countermeasure against phishing
attacks exposing the victim's private key is to guarantee that private
keys are encapsulated in hardware tokens that can't be easily
transmitted (even the hardware token owner has no direct access to the
private ... just access to operations that utilize the private key).

This is countermeasure for the phishing attacks where the crooks are
harvesting static data for later use in fraudulent transactionsq. Such
private key hardware tokens are still vulnerable to other kinds of
qsocial engineering attacks where the crooks convince naive users to
directly perform transactions on behalf of the crook.

The issue for the existing common PKI vendors ... is they frequently
view their revenue flow from the manufacturing of certificates.
Certificates are not necessary to deploy a public key authentication
infrastructure.

The PKI, certificate design point is the offline email environment
from the early '80s. The recipient dials up their local electronic
post office, exchanges email, hangs up and starts reading their
email. They encounter a email from a total stranger than they've never
communicated with before and they have no method of obtaining any
information about this stranger. Certificates were designed to supply
some minimum amount of information where the recipient had no other
recourse in an offline environment dealing with total strangers (the
letters of credit model from sailing ship days).

The issue is that the such certificate, offline design point doesn't
apply to common business relationships where prior communication is
the norm and there are existing business process relationship
management conventions (some of them having evolved over hundreds of
years). A simple example is bank accounts where there is not only
information about the customer ... but also other things that
represent dynamic and/or aggregated information (like current balance)
that is not practical in a certificate model. Given that the relying
party already has information about the originator and/or has
real-time, online access to such information, then a stale, static
certificate becomes redundant and superfluous.

recent related posting about SSL domain name certificates
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used

lots of past posts about SSL domain mame certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

Certificate Services

From: <lynn@garlic.com>
Newsgroups: microsoft.public.security
Subject: Re: Certificate Services
Date: Thu, 19 May 2005 21:30:11 -0700

Dan wrote:

Implementing WPA with RADIUS doesn't mean you HAVE TO install
Certificate services, unless you are implementing EAP-TLS.  You can
always use PEAP-MS-CHAPV2 which will require username and password
instead.

note that there have been certificate-less public key implementations
for both kerberos and radius done. in fact the kerberso pk-init ietf
draft for supporting public keys started out simply with
certificate-less public key operation.
http://www.garlic.com/~lynn/subpubkey.html#kerberos
http://www.garlic.com/~lynn/subpubkey.html#radius

in principle, certificate-less operations maintains existing business
processes for registering authentication material ... but replaces the
registration of a pin/password with the registration of a public key.
then the user authenticates with a userid/digital signature .... where
the digital signature is verified with the onfile public key.
http://www.garlic.com/~lynn/subpubkey.html#certless

the original design point for PKIs and certificates was the offline
email model of the early 80s; the recipient dailed up their local
electronic post office, exchanged email, hung up and found themselves
with an email from a total stranger that they had never communicated
with before. in this first-time stranger communication in the offline
world, the recipient had not resources to determine information about
the sender. this is somewhat the email analogy to the letters of
credit paradigm from sailing ship days.

using somewhat abstract information theory, a certificate represents
an armored, stale, static, distributed catched information. it is
pushed by the sender to the relying-party ... so that the relying
party can have information about the sender in the stranger,
first-time communication where the relying party is offline and has no
recourse for obtaining any information about a stranger in a first
time communication situation.

in the early 90s, there was some move for x.509 identity certificates
by trusted third party certification authorities. however, it was
somewhat difficult for a CA to predict exactly what identity
information some unknown relying party in the future might require. As
a result there was some move to grossly overlead identity certificates
with enormous amounts of privacy information.

in the mid-90s, various infrastructures (like financial institutions)
were coming to realize that enormous amounts of identity infomration
represented significant liability and privacy issues. as a result
there was some efforts in the area of relying-party-only certificate
http://www.garlic.com/~lynn/subpubkey.html#rpo

where a certificate might only contain some form of an account number
as certified information. the key owner would constantly digitally
sign transactions with their private key and push the transaction, the
digital signature, and the certificate to the relying party (who had
originally issued the certificate and has a superset of all the
information already on file, including the public key and the
associated account record). in all cases the account selection
(number, userid, or some other value) was also present in the
digitally signed transaction.

when the relying-party receives the transaction, they pull the look-up
value from the transaction, read the associated account information,
retrieve the public key from the account, and using the onfile public
key, verify the digital signature. In such scenarios, it is possible
to demonstrate that such stale, static digital certificates are
redundant and superfluous.

there was another downside in the case of financial payment
transactions. the typical payment transactions is on the order of
60-80 bytes. the typical relying-party-only certificate from the
mid-90s was on the order of 4k-12k bytes. The scenario for adding
stale, static, redundant and superfluous digital certificates to every
financial transaction did represent a factor of 100 times payload
bloat added to each transmission (constantly sending redundant and
superfluous information back to the financial institution that it
already had on file).

General PKI Question

From: <lynn@garlic.com>
Newsgroups: microsoft.public.security
Subject: Re: General PKI Question
Date: Fri, 20 May 2005 08:45:22 -0700

Ted Zieglar wrote:

First, a bit of background: If you want to send an encrypted message,
you encrypt the message with the intended recipient's public key. That
way, only the intended recipient can decrypt the message (with their
private key).

If you want to send a signed message, you encrypt the hash of your
message with your own private key. If the recipient can decrypt the
hash with your public key, that proves that the message came from you.

Now to your question: Where does one obtain someone's public key?
Well, there are several methods but in general it works like this: If
you're encrypting a message your software obtains it from a PKI. If
you're signing a message your software will attach your digital
certificate to the message.  The digital certificate contains your
public key.

basically there is asymmetric key cryptography as opposed to symmetric
key cryptography. in symmetric key cryptography, the same key is used
for both encrypting and decrypting the same message. in asymmetric key
cryptography they are different keys.

a business process has been defined for asymmetric key cryptography
where one key is designated as "public" and divulged to other parties
and the other key is designated as "private" and is never divulged.

some additional business processes have been defined

1) digital signature authentication .... a secure hash is computed for
the message, which is then encoded with the private key. other parties
with the corresponding public key can decode the digital signature and
compare the decoded secure hash with a freshly computed secure hash of
the message. this will validate a) the origin of the message and/or b)
if the message has been modified.

2) confidential data transfer ... people will encode messages with the
recipient's public key. only the recipient with their (never divulged)
private key can decode the message. frequently because of overhead of
asymmetric key cryptography ... a random symmetric key is generated,
the message is encrypted with the symmetric key and the symmetric key
is encode with the public key.  The encrypted message and encoded
symmetric key are transmitted together. only the corresponding private
key can decode the symmetric key ... and then, in turn decode the
actual message.

In general, public keys can be registered with other parites ... in
much the same way shared-secrets and other kinds of authentication
materials are registered today ... using well established business
process relationship managment processes (some that have evolved over
hundreds of years, like bank accounts).

The initial kerberos pk-init ietf draft for adding public keys to
kerberos implementations specified registering public keys in lieu of
passwords
http://www.garlic.com/~lynn/subpubkey.html#kerberos
later specifications were added that certificate-based public keys
could be used

There have also been RADIUS implementations where public keys were
registered in lieu of passwords and digital signature authentication
operation was performed
http://www.garlic.com/~lynn/subpubkey.html#radius

From 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

digital signature authentication schemes are a form of something you
have authentication .... only you have access and use of a (never
divulged) private key.

Certificate-based public keys (PKIs) were designed to address the
offline emails scenario of the early 80s; recipient dials up their
(electronic) postoffice, exchanged email, and hungup. They were then
possibly faced with some email from a total stranger that they had
never communicated with before.  Certificates were somewhat the
"letters of credit" analogy (from the sailing ship days) ... where the
recipient/relying-party had no other means of obtaining information
about the subject ... either locally (or heaven forbid using online,
electronic means).

In the early 90s, there were x.509 identity certificates ... where the
CAs, not being able to reliably predict what information some future
relying party might need .... were looking at grossly overloading
certifictes with excessive amounts of privacy information. Later in
the 90s, some number of infrastructures (like financial institutions)
were realizing that identity certificates, grossly overloaded with
excessive amount of information represented significant liability and
privacy issues.

At this time, you saw some appearance of relying-party-only
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

where the information in a certificate was reduced to little more than
a record lookup indicator (userid, account number, etc). a person
would create a message, digitally sign it, and package the message,
the digital signature and the certificate and send it off to the
relying party. the relying party then would use the indicator in the
base message to index the appropriate relationship record and retrieve
the associated information (including the registered, onfile public
key).  the onfile public key would then be used to verify the digital
signature (authenticating the message). It was trivial to demonstrate
that the stale, static certificate was redundant and superfluous.

in the financial sector, these relying-party-only certificates were
also be targeted at payment transactions. the typical payment message
is on the order of 60-80 bytes. the typical relying-party-only
certificate from the period was on the order of 4k-12k bytes. not only
were the stale, static certificates redundant and superfluous, but
they could also contribute a factor of 100 times in message payload
bloat.

a basic issue is that the certificate design point was addressing the
problems of a offline, unconnected world for first time communication
between total strangers. as the world transitions to ubiquitous,
online, certificates are looking more like horse buggies on an
interstate with 75mph speed limit.

we were asked to do some consulting with this small client/server
startup in menlo park that wanted to do some payment transactions on
their server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

and they had this thing called SSL that could encrypt internet
transmission.  slightly related, recent posting
http://www.garlic.com/~lynn/2005h.html#39 Attacks on IPsec

there was also a perceived integrity problem with the domain name
infrastructure ... so SSL server domain name certificates were defined
http://www.garlic.com/~lynn/subpubkey.html#sslcert

where the browser would compare the domain name in the typed-in URL
with the domain name in the digital certificate. Along with working on
the specifics of payment gateway ... we also got to go around and do
end-to-end business audits of several of the certification authorities
that would be providing SSL server domain name certificates.

The process has an applicant for an SSL server domain name certificate
providing loads of identification information. The certification
authority then performs the expensive, complex, and error-prone
identification matching process of checking the supplied
identification material with the identification material on file with
the authoritative agency for domain name ownership.

Note that the authoritative agency for domain name ownership is the
same domain name infrastructure that has the integrity issues that
give rise to the requirement for SSL server domain name certificates.

So somewhat from the certification authority industry, there is a
proposal that SSL domain name owners register a public key at the same
time they register a domain name ... as part of an attempt to improve
the integrity of the domain name infrastructure (so that the
information that goes into certification of SSL domain name
certificates is also more reliable).

Now, somebody can digitally sign their SSL domain name certificate
application. The CA (certification authority) can now retrieve the
onfile public key from the domain name infrastructure to validate the
applicant's digital signature ... note this is a certificate-less
digital signature authentication using online, onfile public keys
http://www.garlic.com/~lynn/subpubkey.html#certless

this also has the side-effect of turning an expensive, complex, and
error prone identification process into a simpler and more reliable
authenticatin process.

However, this integrity improvement represents something of a catch-22
for the CA PKI industry ...

1) improvements in the integrity of the domain name infrastructure
mitigates some of the original requirement for SSL domain name
certificates

2) if the CA PKI industry can make the trust basis of their whole
infrastructure on certificate-less, real-time retrieval of onfile
public keys .... it may occur to others that they could use the same
public keys directly (potentially modifying the SSL protocol
implementation to use public keys directly obtained from the domain
name infrastructure rather than relying on stale, static
certificates).

Authentication - Server Challenge

From: <lynn@garlic.com>
Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
Subject: Re: Authentication - Server Challenge
Date: Fri, 20 May 2005 12:26:09 -0700

de9me . via .NET 247 wrote:

- Client is a C# WinForm .NET app

-Webservice is hosted on a linux machine running BEA WebLogic

I want the client app to respond to the server challenge for
authentication:

a) Using https (SSL), which would prompt user for a PKI certificate.
b) A server challenge for BASIC authentication, which would pop-up a
logon window requesting username/password.
c) BASIC authentication over SSL, which would prompt for PKI cert and
pop-up logon window requesting username/password.

This is the behavior that Internet Explorer provides to end users.
How do I provide this same functionality in a C# .NET client app?
Therefore, how do you capture/interpret a server challenge (non IIS
web servers) or are there methods/libraries you can use to do the same
thing that IE provides?

a lot of webservers provide stub authentication routine ... for
implementation of client authentication. a frequent proposal in the
past has been to radius-enable such stub routines ... then the
infrastructure can use the full power of radius based
authentication/authorization/permissions/administration/etc operations
for managing their clients.

There are a number of standard radius implementations that accept some
asserted entity ... which is then authenticated from information
maintained at radius and then the permissions &/or policies associated
with that entity are established.

standard radius have been shared-secret based supporting clear-text
password or challenge/response protocols. there have also been
enhancements to radius for supporting digital signature verification
where the shared-secret password registration is replaced with public
key registration (all the administration and business practices are
preserved for relationship real-time management).
http://www.garlic.com/~lynn/subpubkey.html#radius

the simple pulic key in lieu of shared-secret password is effectively
a certificate-less based operation
http://www.garlic.com/~lynn/subpubkey.html#certless

depending on whether shared-secret clear-text or non-clear-text
authentication is used ... the mechanism may or may not require an
encrypted SSL channel.

Somewhat the design point for certificate-based public keys was the
offline email environment of the early 80s. The recipient dialed up
their (electronic) post office, exchanged email, hung up and were then
possibly faced with handling first time communication with a complete
stranger. This is the letters of credit paradigm from the sailing ship
days .... how does the relying party determine anything about complete
stranger on initial communication ... when there was no direct access
to either local or remote information available to the relying party.

The early 90s saw some certificate-oriented operations attempting to
deal with x.509 identity certificates and the inability to predict
what information some unknown relying party in the future might
require from a complete stranger. The tendency was to look at grossly
overloaded the identity certificate with enormous amounts of privacy
information.

By the mid 90s, some infrastructures were starting to realize the
x.509 identity certificates overloaded with enormous amounts of
privacy information represented serious liability and privacy
concerns. There was then some retrenchment to relying-party-only
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

basically certificates that contained little more than an index to
some kind of account/entity record (where all the real information
was) bound to a public index/key. However, since this fundamentally
violated the target environment that certificates were designed to
address (offline enviornment with first time communication between
total strangers), it was trivial to demonstrate that stale, state
certificates were redundant and superfluous. The subject generated a
message, digitally signed the message and then packaged the message,
the digital signature, and the digital certificate and sent it off to
the relying party. The relying party extrated the record index/key
from the initial message and retrieved the message (including the
originally registered public key). The onfile public key was then used
to validate the digital signature. The inclusion of the stale, static
digital certificate in the transmission was redundand and superfluous.

The redundant and superfluous, stale, static digital certificate did
represent something of an issue in proposal for use in payment
transactions of the period. A typical payment message is on the order
of 60-80 bytes. Even the typical relying-party-only certificate from
the period was on the 4k-12k bytes. While the stale, static
certificate was redundant and superfluous it did have the potential of
creating enormouos payload bloat in the payment networks, increasing
transmission requirements by a factor of one hundred times.

Blinky lights WAS: The SR-71 Blackbird was designed ENTIRELY

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinky lights  WAS: The SR-71 Blackbird was designed ENTIRELY
 with slide rules. (fwd)
Newsgroups: alt.folklore.urban,alt.folklore.computers
Date: Fri, 20 May 2005 13:50:05 -0600

Morten Reistad writes:

There was a twice daily routine to go check the cabinet lights. There
were several hundred things that were checked. They embraced SNMP
when it arrived.

from my view, snmp had some interesting wars in the 80s. at interop
88
http://www.garlic.com/~lynn/subnetwork.html#interop88

snmp was still duking it out with the other contenders

there was some amount of osi out in force also (the world govs. were
starting to mandate the internet be eliminated and everything be
converted to osi).

I got a couple workstations in a booth diagonal from a booth that case
had snmp being demo'ed (about 10-15' away) ... and case was convinced
to help with an after hours snmp port to the workstations (demo it on
other machines than his).

from my rfc index:
http://www.garlic.com/~lynn/rfcidx3.htm#1067

1067 -
 Simple Network Management Protocol, Case J., Davin J., Fedor M.,
 Schoffstall M., 1988/08/01 (33pp) (.txt=67742) (Obsoleted by 1098)
 (See Also 1065, 1066) (Refs 768, 1028, 1052) (Ref'ed By 1089,
 1095, 1156, 1704)

or
http://www.garlic.com/~lynn/rfcauthor.htm#xaCaseJ

Case J. (case@snmp.com)
 3412 3410 2572 2570 2272 2262 1908 1907 1906 1905 1904 1903 1902
 1901 1628 1512 1452 1451 1450 1449 1448 1444 1443 1442 1441 1285
 1157 1098 1089 1067 1028

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Blinky lights WAS: The SR-71 Blackbird was designed ENTIRELY

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blinky lights  WAS: The SR-71 Blackbird was designed ENTIRELY
 with slide rules. (fwd)
Newsgroups: alt.folklore.urban,alt.folklore.computers
Date: Fri, 20 May 2005 13:55:37 -0600

oh yes, past posts mentionding sr-71
http://www.garlic.com/~lynn/2000f.html#13 Airspeed Semantics, was: not quite an sr-71, was: Re: jet in IBM ad?

... there are a different set of stories from boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

doing the F16.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Improving Authentication on the Internet

From: <lynn@garlic.com>
Newsgroups: netscape.public.mozilla.security
Subject: Re: Improving Authentication on the Internet
Date: Fri, 20 May 2005 22:06:04 -0700

Frank Hecker wrote:

As I've said before, I don't think use of certs in general and SSL in
particular should be artificially constrained to fit the perceived
requirements of the Internet e-commerce market. To get back to Gerv's
draft paper, I think his discussion is consistent with that approach:

He's proposing leaving the existing browser CA/SSL model and UI in
place for legacy CAs and certs, and basically creating an extension to
the model and UI specifically for SSL uses with financial
implications.  Certainly one can quibble with the various details of
his proposal; for example, it may be that it would be more appropriate
to give special treatment to only one additional class of cert, rather
than the two classes ("shopping" and "banking"). However this general
approach is IMO worth discussing.

we were asked to work with this small client/server startup in menlo
park that wanted to do payments on their server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

and they had this thing called ssl. in the year we worked with them,
they moved from menlo park to mountain view and changed their name
from mosaic to netscape (trivia question ... who had the original
rights to the name netscape?).

so part of this was for what became to be called e--commerce. the
customer would type in the url ... and it would go to an ssl shopping
shite. the browser would get back an ssl domain name certificate and
check the domain name in the certificate with the name typed in by the
customer. merchant webservers began complaining that running sll for
the shopping experience was cutting performance by 80-90 percent and
almost all such merchant sites now run w/o ssl. as a result there is
no checking of what the customer typed in to the browser for a URL
against what site the user is actually visiting.

eventually the customer gets to the end of shopping and hits the
check-out button ... which does supply a URL that specifies ssl. Now
if this was really a fraudulent site ... it is highly likely that the
crooks will have established some perfectly valid domain name and
gotten a valid SSL certificate for it ... and they are likely to also
make sure that whatever domain name that the check-out button supplies
... corresponds to the domain name in some certificate that have valid
control over.

now when somebody applies for a SSL domain name certificate ... the
certification authority usually goes to a great deal of trouble to
validate that the entity is associated with an identifiable valid
company (this basically is a complex, costly, and error-prone
identification process). They then contact the domain name
infrastructure and try and cross-check that the company listed as the
owner of the domain is the same company that is applying for the
certificate. Now if there has actually been a domain name hijacking
...  there is some possibility that the crooks have managed to change
the name of the company owning the domain to some valid dummy front
company that they have formed. in which case the whole certificate
authority process falls apart since it is fundamentally based on the
integrity of the domain name infrastructure registry of true owners.

so there is a proposal to have domain name owners register a public
key along with their domain name. then future communication from the
domain name owner is digitally signed and the domain name
infrastructure can verify the digital signature with the
(certificate-less) onfile public key for that domain name.  this
supposedly mitigates some of the forms of domain name hijacking.

the proposal is somewhat back back the SSL certification authority
industry since it improves the integrity of the domain name
infrastructure ... on which there ability to correctly certify the
true domain name owner is based.

it has another side effor for the ssl certification authority industry
... rather than doing the expensive, time-consumer and error prone
identification process they can require that ssl certificate
applications also be digitally signed. they then have a much simpler,
less-expensive, and reliable authentication process by retrieving the
(certificate-less) onfile public key for the domain name owner (from
the domain name infrastructure).
http://www.garlic.com/~lynn/subpubkey.html#certless

it does represent something of catch-22 for the ssl certification
authority industry. if the integrity of the domain name infrastructure
is improved it somewhat mitigates one of the original justifications
for having ssl certificates. another issue is if the ssl certification
authority can base the trust of their whole operation on the retrieval
of (certificate-less) onfile public keys from the domain name
infrastructure ... one could imagine that others in the world might
also start trusting real-time retrieval of certificate-less, onfile
public keys from the domain name infrastructure. There might even be a
slightly modified version of SSL that used real time retrieval of
certificate-less, onfile public keys ... rather than a public key from
a stale, state (and potentially revoked?) certificate.

part os this comes somewhat from the original design point for PKI
certificates which was the offline mail environment of the early
80s. A recipient would dialup their (electronic) post-office, exchange
email, and hangup. They then could be dealing with a first-time
communication from a total stranger. This is somewhat a later day
analogy to the letters of credit model from the sailing ship days
... where the relying party had no (other) method of validating
first-time interaction with total stranger.

In the early 90s, there were x.509 identity certificates. The
certification authorities were somewhat faced with not really being
able to predict what information an unknown, future relying party
might require about an individual.  There was some tendency to want to
grossly overload such identity certificates with excessive amounts of
personal information.

Somewhat in the mid-90s, various institutions came to the realization
that such identity certificates grossly overloaded with excessive
personal information presented significant liability and privacy
issues. There was some effort to retrench to something called a
relying-party-only certificate
http://www.garlic.com/~lynn/subpubkey.html#rpo

which basically contained some sort of unique record index pointer
(account number, userid, or other distinquishing value) and a public
key. The subject would create a message (also containing the
distinquishing value) and digitally sign it with their private key.
They then would package the message, the digital signature and the
certificate and send it off to the relying party. The relying party
would extract the distinguishing index value from the message and
retrieve the indicated record containing all the necessary
relationship information about the originating entity (including their
registed public key). They then could validate the digital signature
using the onfile public key. In such situations it was trivial to
proove that such a stale, static certificate was redundant and
superfluous. Part of what made it so easy to proove they were
redundant and superfluous was the whole operation violated the
original design point that certificates were met to serve
... first-time communication between complete strangers where the
relying party had absolutely no other method for establishing any
information about the stranger they were communicating with.

There was also some look at these stale, static redundant and
superfluous digital certificates for payment transactions by customers
with their respective fianncial institutions (again violating the
basic design point environment that certificates were met to
serve). It turns out that the nominal payment message size is about
60-80 bytes. The nominal relying-party-only certificate from the
mid-90s (even with only an account number and a public key) was on the
order of 4k-12k bytes.  Not only was the attachment of stale, static
digital certificates to every payment transaction redundant and
superfluous, but doing so would represent an enormous payload bloat of
a factor of one hundred times.

More Phishing scams, still no SSL being used

From: <lynn@garlic.com>
Newsgroups: netscape.public.mozilla.crypto
Subject: Re: More Phishing scams, still no SSL being used...
Date: Sat, 21 May 2005 10:57:22 -0700

Gervase Markham wrote:

In other words, a nonce is a way of having a lifetime of zero for the

OCSP request.

IMO, given other latencies which would be present in a system for
revoking the cert of a phishing site, a near-equivalent level of
security with much greater scalability could be achieved by having
nonce-less operation, 1-minute timeouts, and using the TLS extensions

which (I am told) allow the webserver to deliver the OCSP response
rather than the OCSP responder itself. Then, the OCSP server has to
service one request every 30 seconds per webserver, rather than one
request per client connection.

so, sort of per the earlier postings
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used

you could use a realtime, certificate-less, onfile public key retrieval
from trusted DNS infrastructure ... for using in establishing
encrypted SSL session (instead of obtaining server public key from a
certificate).

now for 20 some years, DNS has had generalized mechanism for
multi-level caching of information with per entry cache expiration
interval (including at the lowest end-user end-point).

i think it was 1991(?) acm sigmod conference in san jose ... somebody
raised a question about what was this x.5xx stuff going on .... and
somebody else explained that it was a bunch of networking engineers
attempting to reinvent 1960s database technology.

so the primary target for SSL has been client access for e-commerce.
There have been studies that show the e-commerce activity is highly
skewed ... with possibly only 200 sites accounting for upwards of 90
percent of activity. If you were looking specifically at public key
serving within a DNS real-time retrieval paradigm .... with standard
caching and cache entry expiration intervals to address performance
issues that might hypothetically crop up ... you are looking at
relatively small number of public keys that have to be cache to cover
the majority of actual world-wide SSL activity.

More Phishing scams, still no SSL being used

From: <lynn@garlic.com>
Newsgroups: netscape.public.mozilla.crypto
Subject: Re: More Phishing scams, still no SSL being used...
Date: Sat, 21 May 2005 13:20:09 -0700

.... and of course what you could really do is slightly tweak multiple
A-record support ... and add an option to ip-address resolve request
...  and piggy back any available public key(s) on the response giving
the server's ip-address(es). no additional transactions needed at all
... and you have the public key before you even have made the attempt
to open the tcp session. if the server had also registered their
crypto preferences when they registered their public key ... you could
almost imagine doing the ssl session setup integrated with the tcp
session setup.

when we were on the xtp tab .... xtp was looking at doing reliable
transaction in 3-packet minimum exchange; by comparison tcp has a
minimum 7-packet exchange ... and currently any ssl then is over and
above the tcp session setup/tear-down. the problem with the current
server push of the certificate ... the tcp session has to be
operational before any of the rest can be done.

misc. past ssl certificate postings
http://www.garlic.com/~lynn/subpubkey.html#sslcert

misc. past xtp/hsp (and some osi) postings
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

Revoking the Root

From: <lynn@garlic.com>
Newsgroups: netscape.public.mozilla.security
Subject: Re: Revoking the Root
Date: Sat, 21 May 2005 18:50:47 -0700

Ian G wrote:

Oh... so it's written in the standard.  Are you saying that the
standard defines no way to revoke a lost CA root?  Or that it is
impossible to revoke a CA root?  They are two entirely different
things.

OpenPGP does it, the keys can revoke themselves, and indeed the early
docs used to exhort you to create a revocation certificate for
emergency use.

I don't know what SPKI does - do roots in that system revoke
themselves?  In my own designs, we would just go the manual route and
alert everyone.

No financial system permits such trust to be placed in a single point
of failure; Most of the finance systems I have seen have defence in
depth and layered "meltdown" plans.  For example, there was Mondex's
famous plan to distro new code into the cards if the crypto got
cracked, and all of the cards schemes operated secret shadow
accounting systems for meltdown motives (originally).

i think there was a discussion 8-9 years ago ... root can sign a CRL
revoking itself. the issue was what can a bad guy do with a stolen
root private key. they can sign fraudulent certificates and they can
sign revokations. however, supposedly revokation was only a one-way
operation .... either the bad guys or the good guys might sign a
revokation of the root key ... but it was not possible for anybody to
sign anything that could unrevoke a revoked root key. The idea was
once somebody put the revokation of a root key in play (whether it was
the good guys or the bad guys) nobody would be able to reverse the
operation.

there were numerous statements by major financial transaction
operations over the past ten years that they would never convert to a
conventional PKI system because they would never deploy any kind of
infrastructure that had single points of failures (or even small
number points of failure) .... the compromise of a root key (no matter
how unlikely) was viewed as traditional single point of failure
scenario.  there was some study that major financial operations could
be out of commission for 4-8 weeks assuming a traditional PKI-based
operation and a compromise of root private key. such positions were
frequently mentioned in conjunction with systemic risk and the
preoccupation of major financial operations with systemic risk
vulnerabilities.

The basic motivation for mondex was the float that mondex
international got when the next lower level business unit bought one
of their "superbricks". Anybody lower than mondex international in the
chain were just replacing float lost to the next higher level in the
chain.  This issue might be considered the primary financial driving
force behind the whole mondex movement. It was so significant that
mondex internatioinal began offering to split the float as an
inducement for institutions to signup (i.e. the organizations that
would purchase a superbrick from them).

A spectre hanging over the whole operation was some statement by the
EU central banks that basically said that mondex would be given a two
year grace period to become profitable, but after that they would have
to start paying interest on customer balances held in mondex cards
(effectively float disappears from the operation ... and with it much
of the interest in institutions participating in the effort).

mondex international did do some other things ... they sponsored a
series of meetings (starting in san francisco) on internet standard
work ... which eventually morphed into IOTP.

from my rfc index:
http://www.garlic.com/~lynn/rfcietff.htm

select Term (term->RFC#) in RFCs listed by section
and then scroll down to

Internet Open Trading Protocol
  3867 3506 3505 3504 3354

Clicking on the individual RFC numbers fetches the RFC summary for that
RFC. Clicking on the "txt=nnn" field, retrieves the actual RFC.

misc past posts mentioning systemic risk:
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
http://www.garlic.com/~lynn/99.html#156 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#240 Attacks on a PKI
http://www.garlic.com/~lynn/aepay2.htm#fed Federal CP model and financial transactions
http://www.garlic.com/~lynn/aepay2.htm#cadis disaster recovery cross-posting
http://www.garlic.com/~lynn/aepay2.htm#aadspriv Account Authority Digital Signatures ... in support of x9.59
http://www.garlic.com/~lynn/aadsm2.htm#risk another characteristic of online validation.
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm3.htm#cstech7 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsmail.htm#variations variations on your account-authority model (small clarification)
http://www.garlic.com/~lynn/aadsmail.htm#complex AADS/CADS complexity issue
http://www.garlic.com/~lynn/aadsmail.htm#parsim parsimonious
http://www.garlic.com/~lynn/aadsmail.htm#mfraud AADS, X9.59, security, flaws, privacy
http://www.garlic.com/~lynn/aadsmail.htm#vbank Statistical Attack Against Virtual Banks (fwd)
http://www.garlic.com/~lynn/aadsm10.htm#smallpay2 Small/Secure Payment Business Models
http://www.garlic.com/~lynn/aepay10.htm#13 Smartcard security (& PKI systemic risk) thread in sci.crypt n.g
http://www.garlic.com/~lynn/aepay10.htm#19 Misc. payment, security, fraud, & authentication GAO reports (long posting)
http://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001f.html#35 Security Concerns in the Financial Services Industry
http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#31 You think? TOM
http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
http://www.garlic.com/~lynn/2003l.html#64 Can you use ECC to produce digital signatures?  It doesn't see
http://www.garlic.com/~lynn/2003m.html#11 AES-128 good enough for medical data?
http://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
http://www.garlic.com/~lynn/2004j.html#5 Authenticated Public Key Exchange without Digital Certificates?
http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

Revoking the Root

From: <lynn@garlic.com>
Newsgroups: netscape.public.mozilla.security
Subject: Re: Revoking the Root
Date: Sat, 21 May 2005 19:15:43 -0700

Ian G wrote:

Whereas if a root cert was used, then that could only have been lifted
in a very few places.  The use of a root cert would then send a very
strong signal back that would lead to how and when and where it was
ripped off.

the proposals that allow backup/copying of a private key (as a
countermeasure to a physical single point of failure) ...  when we were
running ha/cmp project:
http://www.garlic.com/~lynn/subtopic.html#hacmp

we coined the terms disaster survivability and geographic
survivability to differentiate from simple disaster/recovery.

in any case, just having a process allowing copying of a private key
and multiple copies increase the vulnerability to diversion of copies
for fraudulent purposes

some recent studies claim that at least 77percent of fraud/exploits
involve insiders. from an insider fraud standpoint, diversion of root
private key becomes analogous to embezzlement.

bad things can happen with compromise of PKI root key and resulting
fraudulent transactions.

however, the systemic risk of having a single PKI root key revoked and
having to put the infrastructure thru restart/recovery from scratch is
viewed as possibly being even a worse prospect.

The Worth of Verisign's Brand

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Worth of Verisign's Brand
Newsgroups: netscape.public.mozilla.crypto
Date: Sun, 22 May 2005 06:50:23 -0600

"Anders Rundgren" writes:
 If
this list believe that users should do conscious decisions on what CAs
to trust you are on the wrong track as this is impossible to do for
mere mortals.  A possible solution would be that you for a fee
"outsourced" CA trust decisions to a party that have this as their
prime business.  Such a model would in fact add considerably more
interesting stuff to the plot than just CA validity.  It could
actually claim that a reputation of an organization your are about to
contact is not the best.

trust is a funny thing. in the non-association payment card world
... each merchant that accepts payment card has a bilaterial agreement
(aka contract) with each financial institution issueing cards (for
which they accept/trust cards, aka N*M contracts, aka N merchants, M
issuers). in turn, each financial institution issueing cards has
effectively bilaterial agreement with the consumers they issue a card
for. for ten thousand merchants, a thousand issuing institutions, and
a million customers ... for merchant having contract with every
issuing institution, it would be 10K*1K contracts (on the merchant
side) and 10**6 on the issueing side. this avoids the larger problem
of every merchant having a contract with every customer with a payment
cards (or even for each of a customer's payment card).

in the association payment card world ... the contract problem is
slightly simplified. a merchant has a contract with their merchant
financial institution (one per merchant). A merchant financial
institution has a contract with the association (one per merchant
financial institution). A consumer has a contract for each one of
their payment cards with the respective card issuing financial
institutions. Each card issuing financial institution has a contract
with the association. Basically there is three level hierarchy of
trust & contractual relationship. This mitigates the worst case
scenario of having ever customer sign a trust/contract with every
merchant (say worst case with billion customers and a million
merchants ... having a million, billion contracts).

The other characteristic that carries thru via the financial
institution contracts with the assocations, is that the merchant
financial institution is liable to the assocation on behalf of the
merchants they sponsor ... and consumer financial institution is
liable to the association on behalf of consumers they issue cards
to. The merchant example, is that merchant financial institutions both
love & hate big ticket merchants like airlines; they love the
percent charges they get on the big ticket transactions for accepting
the liability ...  but it is painful when an airline goes bankrupt and
they have to make good on all outstanding charged tickets (which
frequently has run to tens of millions).

The typical TTP CA trust model (from a business standpoint) is
interesting ... since there are explicit trust/contract typically
between the CA and the key owners that they issue certificates to.
However, there frequently is no explicit trust/contractual
relationship that traces from relying parties to the CA (as you would
find in the financial world that traces a trust/contractual trail
between every merchant and every constumer issued a payment card, aka
a merchant can trust a payment card via the thread of contracts thru
their merchant financial institution, to the association and then to
the card issuing consumer financial institition, with a corresponding
thread of explicit liability at each step).

In the federal PKI model ... they sort of made up for this by having
GSA (as a representative of the federal gov. as a relying party) sign
contracts with every approved CA issuing certificates. That way the
federal gov. (as a relying party), when accepting a certificate and
making some decision or obligation based on the trust in that
certificate ... has a legal liability trail to the certificate issuing
institution.

In the SSL certificate model, when a client/end-user makes any
decision or obligation based on the trust in the SSL certificate, it
is rare that every client/end-user has a contractual trail back to the
SSL certificate issuing institution. In the payment card world, the
merchant accepting a payment card has a contractual trail to the
responsible financial institution accepting liability on behalf of the
consumer they issued a card to. In a similar way, each consumer
presenting a card to a merchant has a contractual trail to the
responsible financial institution accepting liability on behalf of the
merchant they represent.

When a merchant presents an SSL certificate to a consumer ... the
consumer has no contractual trail to the SSL certificate issuing
institution.

In the early development of this stuff that became to be called
e-commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

there was some look at the business issues of payment associations
issuing branded SSL certificates ... so that the presentation of such
a branded SSL certificate carried with it trust/liability obligations
similar to the branded association decals you see on physical store
fronts.  One problem was what might be impled by placing trust in an
SSL certificate (and therefor the associated possible liabilities) are
quite a bit more ambiqutous than what is defined for trust between
merchant & consumer in a payment card transaction. If all such
branded SSL certificate were only to explicitly cover the actual
payment transaction and no other activity ... then it was much easier
to define the liability issues (aka there are contractual/business
issues that tend to be orthogonal to technical protocol issues ... and
people working on technical protocol issues may not even have any
concept of what they are about).

One of the issues has been that many merchant financial institutions
were having a hard time even coming to grips with reality of signing
contracts allowing internet merchants to be credit card enabled.  They
could see it for brick&morter institutions that already are
MOTO authorized (i.e. internet credit card transactions mapping
into the existing non-face-to-face, credit-card holder not
present contractual parameters of mail-order/telephone-order transactions).

The issue was for a purely internet merchant that had no inventory, no
physical property ... etc. ... no assets that could be forfeited in
the event of a bankruptcy that would cover the risk exposure to the
financial institution for taking liability of all possible outstanding
transactions.

The other charactistic of CA PKI certificate paradigm being targeted
at the early 80s, offline email paradigm ... was that in the payment
card scenario every merchant transaction is online and passes thru the
(liability accepting) merchant financial institution (or some agent
operating on behalf of the merchant financial institution).

The CA PKI certificate paradigm for the early 80s, offline email had
the relying-party/recipient dialing their (electronic) postoffice,
exchanging email, hanging up, and being faced with first-time
communication from a total stranger ... where the relying-party had no
other recourse for establishing any attributes regarding the stranger.
The PKI certificate was sort of filled an analogous role to the
"letters of credit" from the sailing ship days. This is an offline
push model where the subject is pushing the credential to the
relying-party ... and the intended purpose was to address the
environment where the relying-party had no real-time method for
corroborating the information.

In the 90s when some suggested that the credit card model should be
brought into modern era with certificates; I would comment that it
would be regressing the payment card industry to the archaic, ancient
non-electronic period of the '50s & '60s (when the merchant,
relying-party had no recourse to online information and had to rely on
the revokation booklets mailed out every month, and then every week).

The payment card industry transitioned to the online model in the 70s
and left the old fashion offline model (that the CA PKI model uses)
mostly in history.

In any case, the issue for the merchant financial institution,
accepting liability on behalf of the merchant, gets to see every
financial transaction in real time, as it is happening. At any point
in time, the merchant financial institution has an approximate idea of
the aggregate, outstanding fianncial liability it has per merchant
(because it is seeing and aggregating the transactions in real time)
and could choose to shut it off at any moment.

One of the financial institutions objections to the CA PKI certificate
model ... was that there could be an incremental financial liability
every time the merchant presented the certificate ... and there was no
provisions for an issuing financial institution (that chose to stand
behind such a paradigm) to calculate their potential, outstanding
risk. The issue of not knowing their potential liability exposure at
any moment was somewhat othogonal to not knowing how to deal with
operations that might not having any assets ... and therefor there was
nothing to recover in forfeiture if a bankruptcy occured.

That was somewhat the idea that CA PKI certificates ... in the modern
online risk management world ... was ideally suited for no-value
transactions (i.e. since the trust issue involved no value ... it
would be easy to always know the oustanding, aggregated risk ...
since you knew that summing values of zero ... still came up zero, no
matter how many such events there were).

-
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The Worth of Verisign's Brand

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Worth of Verisign's Brand
Newsgroups: netscape.public.mozilla.crypto
Date: Sun, 22 May 2005 07:19:33 -0600

Anne & Lynn Wheeler writes:

accepting liability on behalf of the merchant, gets to see every
financial transaction in real time as it is happening. At any point in
time, the merchant financial institution has an approximate idea of
the aggregate, outstanding fianncial liability it has per merchant
(because it is seeing and aggregating the transactions in real time)
and could choose to shut it off at any moment.

slight addenda ... the merchant financial institution ... accepting
liabiilty on behalf of merchants they sponsored in the infrastructure
has one other mechanism.

basically, in a payment card transaction ... the card issuing
financial institution comes back with a real-time promise to pay the
merchant. the card issuing financial institution then tranfers the
promised funds to the merchant financial institution.

the merchant financial institution, in calculating the outstanding
run-rate liability for any particular merchant ... can put a delay on
actually making such funds available to the merchant. ... aka they
have some calculation on the risk history of the merchant and an idea
(from real-time transactions) of the current outstanding liability.
Another of the ways that a merchant financial institution can control
the aggregate financial risk exposure they have per merchant ...is by
delaying the actual availability of funds (in any default/bankruptcy
by the merchant, since the funds haven't actually be released ...  the
delayed funds can be used by the merchant financial institution to
help cover their outstanding financial liability on behalf of the
merchant).

In the CA PKI model, unless you are dealing with purely no-value
transactions ... there is a double whammy of having the per
transaction risk being somewhat ambiguous ... and in the offline
certificate push model ... having no idea at all ... how many times a
particular certificate has been pushed (basically multiplying an
unknown number by another unknown number to come up with some idea of
the outstanding liability at any specific moment).

somewhat in the business or value world ... trust frequently is
translated into terms of financial liability.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The Worth of Verisign's Brand

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Worth of Verisign's Brand
Newsgroups: netscape.public.mozilla.crypto
Date: Sun, 22 May 2005 10:39:28 -0600

"Anders Rundgren" writes:

How should a good system have been designed?  The IETF should have
recognized the obvious: e-mail is a TWO-DIMENSIONAL identity and
thus trust structure.  That is, domains (MTAs) should
authenticate/encrypt to each other, preferably using the in fact not
too useless SSL PKI.  Then end-users should authenticate to the
mail-servers.  As they already do that for fetching mail it is odd
that it is not required for sending mail.  There is very little
reason for end-to-end security in a corporate environment.  In fact,
archiving and automatic content control (including virus checks)
mostly make encryption a bad choice in such environments.

there is a separate issue ... ISPs for a long time tended to not want
to take responsibility (and therefor liability) for spam origination.

had this argument maybe ten years ago about ISPs filtering originating
packets (from the ISP customers before hitting the internet) based on
things like bogus origin ip-address (various kinds of spoofing attacks
... not totally dissimilar to phishing attacks with bogus
origin). even as late as 5-6 years ago, the counter arguments were
that ISPs had neither the processing capacity nor the technology
capacility for recognising incoming packets and filtering packets that
had bogus origin ip-address. However, in this period, ISPs were
starting to do all kinds of other packet/traffic filtering &
monitoring of their customers for things in violation of the terms
& conditions of their service contract (prooving that they did
have the capacity and technology).

A possible scenario is if ISPs somehow demonstrated that they were
doing filtering/censoring on things coming from their customers before
it got on the internet ... if something actually got thru and reached
a destination victim ... the destination victom might be able to turn
around and sue the originator's ISP. I think that ISPs want to avoid
being seen as financially liable for bad things that might be done by
their customers.

the other counter argument raised was that even if responsible ISPs
started censoring activity of their customers ... there were enuf
irresponsible ISPs in the world that it wouldn't have any practical
effect. However, there is multi-stage scenario 1) responsible ISPs
might be able to do origin filtering on 90% of the bad traffic, 2)
doing origin censoring rather than destination censoring eliminates a
lot of infrastructure processing overhead getting between the origin
and the destination, 3) for store & forward traffic, responsible ISPs
could still perform entry censorship at the boundaries where it cross
from an irresponsible ISP to responsible ISP.

in many of these situations it isn't whether the receiving can
absolutely proove who the originator is .... it is whether the
originator is generating traffic with spoofed address that the
originator's ISP would have reason to know isn't consistant with the
originator's assigned address.

Not too long after the greencard incident ... we were on a business
trip to scottsdale and having dinner at a resturant in old town.
Three people came in and were seated behind us (a man and a couple).
The man spent most of the dinner explaining to the couple how to
configure their service for commercial purposes ... and how he was
going to be able to send out loads of spam on their behalf (if they
would sign up with him); the techniques he had for staying ahead of
the ISPs that might want to get around to shutting down one or another
of his spam producing facilities (we suspected that the man doing the
talking might have been involved somehow with the greencard incident).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Now the crackpots are trying to make it their own

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Now the crackpots are trying to make it their own
Newsgroups: comp.sys.ibm.pc.hardware.chips,comp.arch
Date: Sun, 22 May 2005 11:19:44 -0600

"Tom Linden" writes:

Can the cache be shared by separate processes?

ugh ... nearly 40 years ago as an undergraudate
. .. i started doing a bunch of work on page replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock
on multi-user timesharing systems
http://www.garlic.com/~lynn/subtopic.html#timeshare
that was being turned around and shipped in commercial systems,
actually, i was also doing the generalized resource scheduling
algorithms that also were being shipped in commercial systems
http://www.garlic.com/~lynn/subtopic.html#fairshare

... anyway ... I was asked several times about the problem of
low-bandidth information leakage and what was I going to do about it.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Outsourcing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Outsourcing
Newsgroups: alt.folklore.computers
Date: Sun, 22 May 2005 14:49:19 -0600

greymaus writes:

'Twas an article in one of the financial papers, UK, about the rise
of Asia, one of the reasons for the rise of india given was that
they were not as hung up on moralities, veracities, as the
Europeans... :)

there was an article in a hong kong paper around 90 or 91 about the
competition for the emerging world-wide outsourcing market ... and the
position that the province just across on the mainland wanted to play.

the article basically went into some amount of detail why india was in
much better position to compete (vis-a-vis the nearby mainland
province) in the emerging world-wide outsorcing market ... a primary
issue was that india had a significantly better civil servant middle
class ("left behind by the british") providing essential
infrastructure support (that was needed/required to compete
effectively in the emerging world-wide outsourcing market).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The Worth of Verisign's Brand

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Worth of Verisign's Brand
Newsgroups: netscape.public.mozilla.crypto
Date: Sun, 22 May 2005 15:03:03 -0600

Anne & Lynn Wheeler writes:

there is a separate issue ... ISPs for a long time tended to not want
to take responsibility (and therefor liability) for spam origination.

there is also the economic model that ISPs might be able to
feature/charge for protecting their customers from the bad things that
happen on the internet .... where there doesn't seem to be anybody to
pay ISP to have them protect the internet from bad things their
customers might do to the internet (and in fact ... the customers that
were planning on doing bad things to the internet might even be
willing to pay more for the privilege).

a couple days ago i ran across a quicky comment about a new book
called freakonmics ... and just now stopping by a local computer
bookstore ... it is the first book you see at the door. it purports to
be "a rogue economist explores the hidden side of everything"

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Outsourcing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Outsourcing
Newsgroups: alt.folklore.computers
Date: Mon, 23 May 2005 09:10:16 -0600

Nick Spalding writes:

The fact that that middle class mostly knows English doesn't do much
harm either.  -- Regards, Nick

english would be useful for dealing with english speaking customers,

this point of the HK newspaper article specifically was that the
internal infrastructure was significantly better operated ... like how
many weeks (months, years) it would take for a local business to get
electricity, water, permits, phone ... and how reliable was the
electricity, water, phone, transportation, utility, etc, services.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Improving Authentication on the Internet

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Improving Authentication on the Internet
Newsgroups: netscape.public.mozilla.security
Date: Mon, 23 May 2005 09:15:18 -0600

Gervase Markham writes:

I don't agree. Without transparency, you can't know how much
security you have.

Nevertheless, quoting aphorisms is not particularly helpful.

The process will acquire more transparency; there are plans afoot to
make that happen. But we had to start somewhere.
Gerv

may be 2nd order factor ... complexity tends to be related to security
vulnerabilities ... transparency can be useful when dealing with
complexity ... and therefore a countermeasure for security complexity
vulnerabilities. KISS can also be a countermeasure for security
complexity vulnerabilities.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

First assembly language encounters--how to get started?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: First assembly language encounters--how to get started?
Newsgroups: alt.folklore.computers
Date: Mon, 23 May 2005 11:55:41 -0600

forbin@dev.nul (Colonel Forbin) writes:

In the Pentagon, it is often the only one.

in the late 70s, we used to joke that FSD's (federal service division,
sold to loral in the 90s) primary language was script (aka document
application that supports GML ... precursor to SGML, XML, etc; most
people thot of the language with respect to the command they typed as
opposed to the language itself).

gml (& standardization as sgml)
http://www.garlic.com/~lynn/subtopic.html#sgml

brought to you curtesy of the cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The Worth of Verisign's Brand

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Worth of Verisign's Brand
Newsgroups: netscape.public.mozilla.crypto
Date: Mon, 23 May 2005 14:09:40 -0600

Anne & Lynn Wheeler writes:

trust is a funny thing. in the non-association payment card world
... each merchant that accepts payment card has a bilaterial
agreement (aka contract) with each financial institution issueing
cards (for which they accept/trust cards, aka N*M contracts, aka N
merchants, M issuers). in turn, each financial institution issueing
cards has effectively bilaterial agreement with the consumers they
issue a card for. for ten thousand merchants, a thousand issuing
institutions, and a million customers ... for merchant having
contract with every issuing institution, it would be 10K*1K
contracts (on the merchant side) and 10**6 on the issueing
side. this avoids the larger problem of ever merchant having a
contract with every customer with a payment cards (or even for each
of a customer's payment card).

using the non-association & non-merchant bank example ... then if SSL
TTP PKI CAs were to apply normal business processes ... then every
relying party for an SSL domain name server certificate would need to
have a pre-existing contract with every SSL domain name server
certificate issuing institution. Looking in a typical browser
repository of trusted CA public keys ... there are possibly 40-50
(although some are multiples for the same business operation).

Taking one billion internet clients as first order approximation to
estimated SSL domain name certificate relying parties ... then gross,
first under approximation to required number of such contracts would
be 50 billion individually signed contracts.

in the payment card scenario this is mitigated by having the
credential (payment cards) issuing institutions sign contracts with
the brand associations (hiearchical legal trust rollup on the issuing
side).  Then the relying-party merchants have contracts with merchant
financial institutions which in turn rollup with the merchant
financial institutions having (legal trust) contracts with the payment
associations.

in this sense, SSL TTP PKI CAs are more efficient than an
approximately analogous real business operation (aka payment cards as
issued credentials which require explicit business processes between
all the parties) by eliminating conforming to standard business
practices (having explicit legal trust relationship between the
relying parties and the credential issuing institutions). An example
where this was addressed has been in the Federal PKI .. where the
federal gov., as a relying party, signed explicit (legal trust)
contracts with each authorized certificate issuing certification
auhtority.

one of the things on the table (when originally pulling together the
current e-commerce infrastructure) was that the same finanical
infrastructure that took liability for merchant transactions would
also issue SSL domain name certificates (which in addition to prooving
domain name ownership would also indicate the liability accepting
relationships).  However, for whatever reasons, that option was not
followed.

The current scenario is that the SSL domain name certificates
basically represent some due diligence in checking with the domain
name infrastructure as to the true domain name owner. However, there
is (nominally) no related, explicit, contractual chain of legal trust
that can be followed from relying parties to the certificate issuing
operations.

Also, as oft repeated, one of the motivating factors in the perceived
need for domain name due diligence (aka SSL domain name
certificates by any other name) has been integrity concerns with
regard to the domain name infrastructure .... and how can a client
really be sure that the server they are talking to is actually the
real server related to the domain name they typed in as part of the
URL. This becomes somewhat ambiguous when one realizes that the domain
name infrastructure is the authoritative agency for domain name
ownership ... and the same authoritative agency that
certification authorities have to check with regarding true domain
name ownership.

misc. past ssl certificate postings:
http://www.garlic.com/~lynn/subpubkey.html#sslcert

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

technical question about fingerprint usbkey

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: technical question about fingerprint usbkey
Newsgroups: sci.crypt
Date: Tue, 24 May 2005 08:31:40 -0600

"frozt" writes:

i saw them fool those things with a melted gummy bear on techtv...

the issue can be security proportional to risk.

something like 30 percent of debit cards are reputed to have the
PINs written on them. part of this is the serious proliferation
of shared-secrets ... and the difficulty of people being forced
to remember scores of different shared-secrets.
http://www.garlic.com/~lynn/subintegrity.html#secrets

some number of the fingerprint scenarios are targeted at the
pin/password market where there is significant, common practice for
people writing down their pin/password.

in this case the issue comes down what is simpler, easier for
a crook (having stolen a card)

1) to lift a pin written on the card and fraudulently enter
the pin

2) to lift a fingerprint possibly left on the card and fraudulently
enter the fingerprint.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The Worth of Verisign's Brand

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Worth of Verisign's Brand
Newsgroups: netscape.public.mozilla.crypto
Date: Tue, 24 May 2005 08:25:33 -0600

"Anders Rundgren" writes:

Mutual authentication is not rocket science but in order to work you
need OTPs or PKI. That is, it is time to let passwords RIP.

for the original stuff that was going to turn into this stuff called
e-commerce ... we specified mutual authentication SSL ...  before
there was a thing in SSL for mutual authentication.

however, it is evident that the design point for certificates & PKI
based infrastructure is for stangers that have never communicated
before. in this original mutual authentication deployment that
we had specified ... it was between (merchant) webservers and
the payment gateway.

however, it quickly became evidently clear that there had to be prior
contract between merchant webservers and their respective payment
gateway. that the use of certificates in the SSL establishment was
purely an artificial artifact of the existing SSL implementation.

in actual fact, before the SSL session was ever established ... the
merchant webserver had a preconfigured set of data on what payment
gateway they were going to contact and the payment gateways had
preconfigured information on which merchants they would process for.
Once the SSL session was established ... this preconfigured
authentication was exercised w/o regard for any certificates. The use
of certificates as authentication mechanism was purely a facade and an
artificial artificate of the use of the existing SSL implemenation ...
and in no ways represented the real (online) business authentication
process.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

relying party, business parties have well established processes for
maintaining information about their business relationships (some of
this well established business relationship processes have evolved
over hundreds of years). passwords are an authentication technology
that have been managed using these relationship business management
processes. it is possible to use the existing business relationship
processes for managing other kinds of authentication material,
including public keys.

certificates are not intrinsicly a substitute for replacing all of the
existing, well established, business relationship processes, nor are
they a mandatory requirement as the only means of managing public key
authentication material in well-established business relationships.

the design point for PKI and certificates were the offline email
paradigm of the early 80s, where a recipient would dial their
(electronic) postoffice, exchange email, and then hangup. The
recipient (relying party) was then possibly faced with processing
first time email with a total stranger. the role of the certificate
was analogous to the letters of credit from the sailing ship days, the
relying party lacking any prior information of their own regarding the
stranger and/or any timely, direct access to a certifying authority.

this is the analogy to the early days of the payment card industry,
where the plastic card was the credential and their were weekly mailed
booklets to every merchant (relying party) of the list of revoked
credentials. in the 70s, the payment card industry quickly moved into
the modern, online world of real-time transactions (even between
relying parties that were strangers that never had any prior contact).
in the mid-90s when the suggestions were made that the payment card
industry could move into modern times by converting to (offline,
stale, static) certificates ... my observation that moving to
certificates would actually represent regressing 30 years to an
offline model ... rather than the real, modern, online model that they
had been using for over 20 years.

It is perfectly possible to take well established business processes
used for managing relationships ... and "RIP" shared-secret
authentication technology ... by substituting public key registration
in lieu of shared-secret (pin/password) registration. businesses are
not likely to regress to stale, static certificates for the management
of timely and/or aggregated information ... like current account
balance. From there is trivial step-by-step process to proove that
stale, static certificates are redundant and superfluous between
relying parties that have existing business relationships.
http://www.garlic.com/~lynn/subpubkey.html#certless

the original pk-init draft standard for kerberos specified only
certificate-less management of public keys, treating public keys as
authentication material in lieu of shared-secrets and leveraging the
existing extensive online management of roles and permissions ... that
are typically implicit once authentication has been performed aka it
is not usual that authentication is performed just for the sake of
performing authentication acts ... authentication is normally
performed within the context of permitting specific set of
permissions (in the financial world, some of these permissions
can be related to real-time, aggregated information like current
account balance)
http://www.garlic.com/~lynn/subpubkey.html#kerberos

similarly it is possible to take another prevelant relationship
management infrastructure, RADIUS. and substitute digital signatures
and the registration of public keys in lieu of shared-secrets ...  and
maximize the real-time, online management and administration of
authentication and permissions within a synergistic whole environment.
http://www.garlic.com/~lynn/subpubkey.html#radius

in any sort of value infrastructure, if it is perceived advantageous
to have real-time management, admnistration and access to permissions,
authorization and other kinds of authentication information ...  then
in such an environment, it would seem not only redundant and
superfluous but also extremely archaic to rely on the offline
certificate paradigm designed for first-time, communication between
total strangers (and the stale, static certificate would substitute
for direct, real-time access to trusted authority).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The Worth of Verisign's Brand

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Worth of Verisign's Brand
Newsgroups: netscape.public.mozilla.crypto
Date: Tue, 24 May 2005 13:52:23 -0600

"Anders Rundgren" writes:

Mutual authentication is not rocket science but in order to work you
need OTPs or PKI. That is, it is time to let passwords RIP.

so passwords by definition are a preestablished relationship
and a relationship administrative and management infrastructure.

in the mid-90s some were complaining ... so what if stale, static,
redundant and superfluous certificates were redundant and superfluous
in an environment involving pre-established relationship and a
existing relationship administration and management system ... they
can't actually hurt anything. However that doesn't take into account
the redundant and superfluous overhead costs of actually doing the
redundant and superfluous certificate-oriented processing where there
already is an established administrative and management relationship
system.  The other scenario is that some might get confused and decide
to rely on the stale, static, redundant and superfluous certificate
data in lieu of actually accessing the real data.

the other scenario would be to leverage a certificate-based operations
in no-value scenario ... and eliminate any established relationship
administrative and management infrastructure. Say, a membership
environment, where any member could "buy" (obtain) any resource
possible and there was no need to perform per member reconciliation.
Say a bank ... that would allow any customer to perform as many
withdrawels as they wanted ... regardless of their current balance (in
fact, eliminate totally the concept of a financial institution even
having to keep track of customer balances ... as being no-value and
superfluous).

however, the truth is ... with regard to value infrastructure, there
tends to be a requirement for a relationship administrative and
management infrastructure (some of the methodology has been evolving
for hundreds of years) that tracks and accumulates information on
individual relationships ... even dynamically and in real time.

for value infrastructures that are managing and administrating
relationships with tried & true established methodology ... then
certificate-oriented PKIs become redundant and superfluous ... as are
the stale static certificates themselves.

the issue then in a mature and well established administrative and
management infrastructure it is straight-forward to upgrade any
shared-secret (identity information, SSN#, mother's maiden name,
pin, password) oriented authentication infrastructure
http://www.garlic.com/~lynn/subintegrity.html#secrets

with a digital signature infrastructure where public keys are
registered as authentication information in lieu of shared-secrets and
digital signature validation (using the public key) is used in lieu of
shared-secret matchine.
http://www.garlic.com/~lynn/subpubkey.html#certless

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

technical question about fingerprint usbkey

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: technical question about fingerprint usbkey
Newsgroups: sci.crypt
Date: Tue, 24 May 2005 14:32:13 -0600

"frozt" writes:

i saw them fool those things with a melted gummy bear on techtv...

the other is that a major skimming fraud with ATM machine overlays and
pin-hole camera (you even see them on crime-shows these days) is
picking up the magstripe and the pin-hole camera recording which keys
were used to enter the pin. current pin-hole camera technology is
having a harder time picking up fingerprint for counterfeiting than it
is having picking up keys entered for counterfeit PIN entry.

it isn't that there aren't fingerprint vulnerabilities ... but they
are more difficult than some common PIN vulnerabilitys ... aka
lost/stolen card with pin written on the card ... or ATM overlay
picking out PIN from keys used on pin-pad.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

The Worth of Verisign's Brand

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Worth of Verisign's Brand
Newsgroups: netscape.public.mozilla.crypto
Date: Tue, 24 May 2005 23:45:41 -0600

Ian G writes:

As an observation, what's happening on the
litigation front suggests that the scene is now set
for this conflict of goals to be tested in court.  There
are now 4 separate thrusts in litigation testing the
assumptions of Internet security (two of these are
not public).  Which means that patience is
exhausted, and what is presented as security is
no longer taken at face value.

one might also be tempted to make a case that in a situation where
their are two parties with ongoing relationship and there are well
established infrastructures for managing that relationship (in some
cases involving methodologies that have evolved over hundreds of
years) ... that and that the introduction of any external operations
interferring in management of that relationship ... like a TTP CA ..
is detrimental to the efficient business operation.

there is a case made that the exploding use of electronic, online
access has created a severe strain on the shared-secret authentication
paradigm ... people having to memorize scores of unique pin/passwords.
http://www.garlic.com/~lynn/subintegrity.html#secrets

asynmmetric cryptography created a business solution opportunity.

In the shared-secret paradigm, the same datdum is used to both
originate as well as authenticate. Persons having access or gaining
access to the authentication information also have the information to
fraudulent impersonate and originate.

The business solution applied to asymmetric cryptography was to
designate one of the paired-keys as "public" and freely available for
authentication purposes. The business process then defines the other
of the paired-keys as "private" and is to be kept confidential and
never divulged. The business process defines only the private key
(which can never be divulged) can be used to originate a digital
signature ... and only the public key is used to verify the digitial
signature.

from the 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

the validation of a digital signature with a specific public key
implies something you have authentication ... i.e. the originator
has access and use of the corresponding private key (which has always
been kept confidential and has never been divulged).

Attacks on authentication material files involving public key
authentication doesn't open the avenue of impersonation (as can occur
when using shared-secrets).

Therefor registering public keys as authentication material in
existing relationship administrative and management infrastructures
acts as a countermeasure to individuals compromising those files and
being able to used the information for impersonation and fraud.

The business role of CAs and certificates ,,, especially TTP CAs, is
to provide information for relying parties in situations involving
first time contact between strangers where the relying party has no
recourse to any resources for determining information about the
originator.

In situations where two parties have established, on going
relationship and there are well established facilities for
administuring and managing that relationship that the statle, static
offline paradigm certificates are redundant and superfluous.

It is possible that the significant paradigm mismatch between well
established relationship adminstrative and management infrastructures
and CA TTPs (targeted at addressing the problem of first time
communication between two strangers) is responsible for at least some
of the discord.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

REPOST: Authentication, Authorization TO Firewall

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: REPOST: Authentication, Authorization TO Firewall
Newsgroups: comp.security.firewalls
Date: Wed, 25 May 2005 10:37:11 -0600

"Greenhorn" writes:

Do firewalls provide dynamically defined access
control  i.e., can they act as access controllers.
e.g., it should be able to do the following, a user
tries to access a resource, the packets would come to
the firewall, if they are HTTP packets and the user is
new (from IP address not being in the authenticated
list), the packets would be redirected to a webproxy,
the webproxy tries to get the user authenticated by a
AAA server (say RADIUS), the firewall would get an
authorization message from the AAA server (or
webproxy), saying the time the user must be allowed
access, the resources he can access etc.
The firewall would provide that access.

Can this be done by the firewalls in the market such
as Checkpoint firewall-1

authentication/authorization boundary checkers are frequently being
referred to as portals (when used as boundary interface to the
internet). the application firewalls and packet-filter routers have
frequently just been somewhat transparent boxes that filter out
identifiable bad stuff.

boxes that clients interact with for authentication/authorization
function are frequently referred to as portals.

authorization policy filtering based on origin ip-address possibly by
time-of-day ... could be an administrative function that
updated/changed packet filerting router rules at different times of
the day. This frequently would be a push operation from the policy and
administrative infrastructure ... rather than a pull function from the
individual boxes.

authenticaton tends to be asserting some characteristic (like
an account number or userid) and then providing some information
supporting that assertion ... from 3-factor authentcation paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

using ip-address origin is more akin to identification w/o necessarily
requiring any proof (or additional interaction demanding proof).

authorization frequently tends to be taking some characteristic
(either from simple identification or from an authorization process)
and looking up the related permissions defined for that characteristic
(like which systems can an authenticated userid access).

RADIUS was originally developed by livingston for their modem
concentrator boxes (i.e. provided authentication boundary for
userid/login authentication for dail-up modem pools). It has
since grown into a generalized IETF standard for AAA
http://www.garlic.com/~lynn/subpubkey.html#radius

In the original livingston case ... the modem concentrator provided
both the RADIUS boundary authentication/authorization as well as the
traffic routing function in the same box. This continues as dominate
technology used world-wide by ISPs to authenticate their dial-in
customers.

the boxes that are routing traffic between intranet and internet are
frequently not exposted to clients as separate functional boxes ... as
is the case of the modem-pool routers that managed the boundary
between the ISP intranet and their dial-in customers.

there is a related but different kind of administrative boundary
situation for DSL/cable customers. They typically have a unquely
identifiable box or (non-ip) address. DHCP requests come in from these
boxes ... if the boxes are associated with a registered, up-to-date
account .. and administrative policy will return DHCP responses that
enable access to generally available ISP services. However, if the box
is not associated with a registered, up-to-date account ... the DHCP
response can configure them so that all their DNS requests and the
resulting ip-address responses go to an in-house sign-up (regardless
of the domain name supplied by your browser ... it would always get
back the same ip-address directing it to a webservice associated with
administrative signup). You tend to find similar setup/configuration
for hotel high-speed internet service and many of the wireless ISP
service providers.

in this scenario ... the dynamic administrative policy isn't based on
ip-address (as an identification) but some other lower level hardware
box address (enet mac address, cable box mac address, etc).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

REPOST: Authentication, Authorization TO Firewall

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: REPOST: Authentication, Authorization TO Firewall
Newsgroups: comp.security.firewalls
Date: Wed, 25 May 2005 12:04:05 -0600

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

All models of the PIX support (from PIX 5.1 onward) RADIUS downloadable
access-lists . This suggests an alternative approach to the
pay-for-use question: if one were using 515/515E, 525, or 535 with
the 7.0 software, then the downloadable access list could be
time-based. When the time ran out, then it could be arranged
so that the user fell into a deny-everything situation.

The user interface would be a bit different, though: instead of
the user getting challenged for a username/password and told that
it is no longer valid, the user simply would suddenly not be
able to get to anywhere. Same effect, but perhaps more confusing
for the user.

long ago and far away ... for the original e-commerce payment
gateway
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

we started out with administrative pushing permitted/allowed
ip-addresses (webservers that had valid contracts to use the payment
gateway) into routers.

this was also in the early days of haystack labs, wheel group, and
some others.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Improving Authentication on the Internet

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Improving Authentication on the Internet
Newsgroups: netscape.public.mozilla.security
Date: Wed, 25 May 2005 12:14:21 -0600

Nelson B writes:

Ah, I was wondering when paradoxes would enter this discussion.
CA self revocation:  Everything I say is a lie.

"I think not" said Descartes, who promptly vanished.

the original scenario was that CA could only assert that they were no
longer valid ... they could never assert the reverse. So only a valid
CA could declare themselves no longer valid ... or bad guys that had
compromised the private key could declare the CA no longer valid ...
but the inverse couldn't be asserted.

so if the bad guys wanted to do a DOS after having compromised the
private key ... then they could, at most, declare the CA no longer
valid ... which by definition is what you want to happen anyway when a
key has been compromised.

the other thing that they could do ... was hope that the CA went
unrevoked as longer as possible ... so that they could use the
compromised private key to generate fraudulent certificates.

However, specifically with respect to revoking a CA ... you could
either do it or not do it ... nobody could ever undo it.

So the bad guys could either say nothing (about the CA) or lie about
the CA by using the compromised private key to revoke the CA. However,
by definition, if the private key has been compromised then what you
want anyway is a revokation of the CA.

The only thing that the valid CA could do is say nothing (about
themselves) or revoke themselves. If the real CA has made a decision
to revoke itself ... then there isn't much else you can do about it.

In any case, self-revokation is a special case of "everyhing else I've
said is a lie". Once it asserts that special case ... then it is no
longer able to assert anything more (and somewhat immaterial whether
that special case was a lie or not).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Status of Software Reuse?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Status of Software Reuse?
Newsgroups: alt.folklore.computers
Date: Wed, 25 May 2005 13:06:38 -0600

for some topic drift ... cp67/cms had an update command, it basically
was used to merge an "update" deck with base software source and
produce a temporary file that was then assembled/compiled.

it was oriented towards 80 column "card" records and sequence numbers
in cols. 73-80.  The cp67/cms assembler source had convention of ISEQ
assembler statement ... to indicate that the sequences in the sequence
number field should be checked (from physical card deck days when
decks could be dropped and shuffled).

the control commands were of the form

./ d nnnnnn <mmmmmm> (delete record from <to> )
./ r nnnnnn <mmmmmm> (replace records from <to> with following source)
./ i nnnnnn          (insert new source after record nnnnn

it started out essentially being a single change file application

as an undergraduate ... i was making enormous amount of source code
changes to cp67 and cms ... and the default process required you to
manually type-in the sequence number field (cols. 73-80) for all new
source records.

I got tired of this and created an update preprocessor that
supported "$" for replace & insert commands

./ r nnnnnn <mmmmm> <$ <aaaaaaa <bb>>>
,/ i nnnnnn         <$ <aaaaaaa <bbb>>>

where it would generate a temporary update file (for feeding into the
update command) that had the sequence number field automatically
generated. It could default to choosing number & increment based on
previous/following cards ... or you could specify a starting number
and any increments.

i believe it was the virtual 370 project that really kicked off the
multi-level update effort. The "H" modifications to cp67 running on
real 360/67 that supported virtual 370 machines ... which had some
number of new/different control operations and instructions.  The "I"
modifications were applied after the "H" modificationa and product a
cp67 kernel that ran on (real) 370 architecture (rather than real
360/67 hardware).

this was a set of execs (command processor file) that used a "cntl"
file to select updates and their sequence for applying incrementally a
hierarchical set of update files. This would iteratively processe "$"
update files ... generating temporary update file and applying the
temporary update file to the source file ... creating a temporary
source file. The first iteration involved updated the base source file
... additional iterations wuould update the previously generated
temporary update file.

I had replicated archived a H/I system (all the source and all the
processes and files needed to generate running systems) on multiple
tapes. Unfornately the datacenter i was using in the mid-80s had an
internal operational problem ... where they had a rash of operators
mouting valid tapes for scratch tapes and destorying data. The H/I
archives tapes were wiped out in this period.

As a small reprieve ... not too long earlier ... Melinda
http://www.princeton.edu/~melinda/

was looking for early examples of the multi-level source update
process. i managed to pull a comple package (execs, control files,
executables, etc) from the h/i archive tapes (prior to their getting
wiped).

In the early time-frame, an MIT student (that has since become quite
well known for work he has since done on the internet) was giving task
for an application that would attempt to merge multiple independent
update hiererachies. This is sort of software re-use ... in the sense
that the same common source was used possibly by different
organizations for developing different target solutions.

As the use of the multi-level update feature became wider used ...
the "$" preprocessing support and the iterative application was merged
into the base update command. Now rather than creating multiple
iterative temporary files ... it would manage everything in memory,
applying things as it went along ... and not producing a temporary
source file until after the last update had been applied.

misc. past posts about the cp67 h/i operating system work
http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries

a fiew past posts on cms source update
http://www.garlic.com/~lynn/2002n.html#39 CMS update
http://www.garlic.com/~lynn/2002p.html#2 IBM OS source code
http://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003.html#62 Card Columns
http://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Improving Authentication on the Internet

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Improving Authentication on the Internet
Newsgroups: netscape.public.mozilla.security
Date: Wed, 25 May 2005 13:11:42 -0600

Ian G writes:

Sure, that's obvious.  But, Lynn, can you shed any light on why the
standards didn't include a mechanism?  You seem to be intimating
that the original PKI concept included it.

i have memory of the exchanges taking place about the protocol process
... i would have to dig back thru the archives to see if i can find
the actual copies. it might also be possible to use a search engine to
find archived copies somewhere on the web.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Improving Authentication on the Internet

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Improving Authentication on the Internet
Newsgroups: netscape.public.mozilla.security
Date: Wed, 25 May 2005 13:46:03 -0600

I thot discussion might have been pkix &/or x9f related .. as an
easier step then starting to search my own archives ... i've done a
quicky web search engine ...

one entry in pkix thread
http://www.imc.org/ietf-pkix/old-archive-01/msg01776.html

here is recent m'soft article mentioning the subject:
http://www.microsoft.com/technet/itsolutions/wss