Misc AADS & X9.59 Discussions


AADS Postings and Posting Index,
next, previous - home

cardtech/securtech & CA PKI
cardtech/securtech & CA PKI (more in thread)
cardtech/securtech & CA PKI (more in thread)
cardtech/securtech & CA PKI (more in thread)
cardtech/securtech & CA PKI (more in thread)
cardtech/securtech & CA PKI (more in thread)
cardtech/securtech & CA PKI (more in thread)
cardtech/securtech & CA PKI (more in thread)
cardtech/securtech & CA PKI (more in thread)
cardtech/securtech & CA PKI (more in thread)
cardtech/securtech & CA PKI (more in thread)
cardtech/securtech & CA PKI (more in thread)
cardtech/securtech & CA PKI (more in thread)
Authentication in eCommerce applicatons
Interoperable Micropayment Order
KISS for PKIX
KISS for PKIX (part 2)
KISS for PKIX (& radius)
KISS for PKIX (part 4
KISS for PKIX (part 5)
KISS for PKIX (part 6)
KISS for PKIX (trust propagation & establishment)
KISS for PKIX (part 8)
KISS for PKIX password/digital signature
KISS for PKIX (authentication/authorization seperation)

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
Please respond to ecarm@xxxxxxxx
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
It was a somewhat loaded question.... the ANSI financial industry standards group has a draft payment standard for all account-based payments that supports digitally signed transactions ... but can use a mapping where there is no certificate and the total transaction payload weight is only slightly increased over the current level.

Effectively, the public key is registered in a field similar to that used for secret key purposes ... and instead of performing a secret key authentication, a digital signature authentication is done, utilizing the public key from the account record. The business process is identical to existing secret key business processes ... but the integrity of the operation has been upgraded with digital signature authentication (making a clear distinction between the advantages of digital signature authentication over secret key .... and the use of certificates and certificate authorities to create authentication towers and provide for key distribution for environments currently lacking any authentication business processes).

administrative costs of secret key infrastructure are higher since a secret key can be used to both originate as well as authenticate a transaction. Also many current secret key infrastructures are currently DES-based and are in need of upgrade anyway (and some simple of the digital signature upgrades represent much longer term lifetime infrastructures than various contending secret-key upgrade contenders).

for description and discussion of the draft standard see

https://www.garlic.com/~lynn/

you wrote: 
From: "Lyal Collins" <lyalc@xxxxxxxx.au>
Please respond to ecarm@xxxxxxxx
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI

I wasn't at that session, but there is a lot of evidence emerging that
PKI doesn't not answer all internet transaction needs in the most cost
effective way.

Another session did say that Kerberos authentication is being used
more and more in campus environments, because PKI doesn't scale well
in the educational capmus arena.

For instance, payments - banks and their custoemrs already know easch
other, so a simple password suits as an electronic signature,
especially under non-prescriptive electronic transaction legislation
models.  Passwords avoid the storage, bandwidth and processing
overheads on what are typically 300-500 byte messages - certificates
and signatures combined can exceed 5000 bytes each.  Symmetric key
encryption has been doing a great job for about 15 years in this
context - why replace it ?

PKI really only adds value to the "stranger problem" in ecommerce - ie
is the buyer able to pay, who is the seller.

Regards,
Lyal
Virtual Business Associates    ECommerce Strategies and Internet Security
ACN 083 334 052
Ph;    02 9712 0205      Fax;    02 9712 0467      Mobile;   0416 097 120
1/37 Walton Crescent  Abbotsford NSW 2046    Australia

> -----Original Message-----
> From: owner-ecarm@xxxxxxxx [mailto:owner-ecarm@xxxxxxxx]On Behalf Of
> Lynn.Wheeler@xxxxxxxx
> Sent: Wednesday, May 19, 1999 2:06 AM
> To: ecarm@xxxxxxxx
> Subject: [ECARM] cardtech/securetech & CA PKI
>
>
> there is rumor that at recent cardtech/securetech ... one of the
> panalist (and
> head of a CA PKI) in a PKI session may some statement about not
> being sure that
> CA PKI is the correct model for business. Is there anybody at
> that session that
> can share a trip report?????
>
>

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
note, typical PKIs have attempt to both address issue of upgrade of secret key to public/private key at the same time as creating totally independent authentication infrastructures which can be applied to environments (like offline email) that currently lack authentication infrastructures of their own.

AADS has taking a look at just the issue of upgrading existing secret key authentication infrastructures to public/private key ... and leveraging those existing authentication infrastructures w/o attempting to replace them with totally new, independent authentication infrastructures.

you wrote: 
From: "Nicholas Bohm" <nbohm@xxxxxxxx>
Please respond to ecarm@xxxxxxxx
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI

At 10:14 AM 5/24/1999 +1000, Lyal Collins wrote:
>I wasn't at that session, but there is a lot of evidence emerging that PKI
>doesn't not answer all internet transaction needs in the most cost effective
>way.
>
>Another session did say that Kerberos authentication is being used more and
>more in campus environments, because PKI doesn't scale well in the
>educational capmus arena.
>
>For instance, payments - banks and their custoemrs already know easch other,
>so a simple password suits as an electronic signature, especially under
>non-prescriptive electronic transaction legislation models.  Passwords avoid
>the storage, bandwidth and processing overheads on what are typically
>300-500 byte messages - certificates and signatures combined can exceed 5000
>bytes each.  Symmetric key encryption has been doing a great job for about
>15 years in this context - why replace it ?

Because asymmetric encryption adds more reliable authentication; but I
agree that PKI is irrelevant in pre-existing relationships.

>PKI really only adds value to the "stranger problem" in ecommerce - ie is
>the buyer able to pay, who is the seller.

The curious thing is that PKI tries to add so much more value than commerce
seems to need when paper is used (there is no equivalent to a PKI for
handwritten signatures, but somehow we seem to manage without).

Regards,

Nicholas Bohm

Salkyns, Great Canfield,
Takeley, Bishop's Stortford CM22 6SX, UK

Phone               01279 871272    (+44 1279 871272)
Fax         01279 870215    (+44 1279 870215)
Mobile      0860 636749     (+44 860 636749)

PGP RSA 1024 bit public key ID: 0x08340015.  Fingerprint:
9E 15 FB 2A 54 96 24 37  98 A2 E0 D1 34 13 48 07
PGP DSS/DH 1024/3072 public key ID: 0x899DD7FF.  Fingerprint:
5248 1320 B42E 84FC 1E8B  A9E6 0912 AE66 899D D7FF

>Regards,
>Lyal
>Virtual Business Associates    ECommerce Strategies and Internet Security
>ACN 083 334 052
>Ph;    02 9712 0205      Fax;    02 9712 0467      Mobile;   0416 097 120
>1/37 Walton Crescent  Abbotsford NSW 2046    Australia
>
>> -----Original Message-----
>> From: owner-ecarm@xxxxxxxx [mailto:owner-ecarm@xxxxxxxx]On Behalf Of
>> Lynn.Wheeler@xxxxxxxx
>> Sent: Wednesday, May 19, 1999 2:06 AM
>> To: ecarm@xxxxxxxx
>> Subject: [ECARM] cardtech/securetech & CA PKI
>>
>>
>> there is rumor that at recent cardtech/securetech ... one of the
>> panalist (and
>> head of a CA PKI) in a PKI session may some statement about not
>> being sure that
>> CA PKI is the correct model for business. Is there anybody at
>> that session that
>> can share a trip report?????

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
X9.59 defines digital signature for all account-based consumer payments and preserves the integrity of financial infrastructure. It does this with a single digital signature on the transaction and no encryption.

Design is to operate in all current environments, internet, non-internet, pos, atm, debit, credit, etc.

A mapping has been demonstrated for X9.59 w/o the burden of certificates. This mapping has been done for existing X9.15 and ISO8583 networks, The certificate-less mapping (or if you will, knowledge-based compression of certificate to zero bytes) we've referred to as Account Authority Digital Signatures (AADS ... as compared to Certificate Authority Digital Signature ... CADS).

An AADS chip strawman has also been defined that can be added to existing magstripe cards for very nominal costs. The objective of the strawman chip is to have at least as high integrity as any existing chip for hardly any cost (in part, computational requirements are lower than most encryption base methodologies ... putting only the minimum required circuits into the chip allows for higher yield per wafer while still meeting very high integrity objectives.

The AADS chip strawman and AADS infrastructure has also looked at parameterised risk management .... allowing deployment of an infrastructure with at least a 50-year lifetime (much longer than any other existing infrastructure upgrade proposal).

you wrote: 
From: "Lyal Collins" <lyalc@xxxxxxxx.au>
Please respond to ecarm@xxxxxxxx
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI

>I confess - my comment was also somewhat loaded.

Key2IT is a product to take Debit/Credit style and cheque processing
to the Internet, by introducing 3DES encryption, and reducing the
keymanagement overheads - allowing for lost or out of synch
(e.g. being batched, or due to network delays) transactions over
Internet and wireless networks.

The business model for lowest overhead operation of PKI required for
high dispute environments (money, property etc) means for high cost
issuing - ie in person identification, typically costing around $30-40
per person (indicative Australian figures).  Adding a smartcard to
this picture (in order to actually be secure) typically adds between
$5-15 to the cost.  Without in-person ID, who is the certificate being
issued to ?  (and consequent potentially large increase in disputes -
costing many tens of times the issuing cost for resolution)

A smartcard with several 3DES keys (Send, Receive, MAC etc) is at
worst an equal cost, typically a dramatically lower cost, low
bandwidth and computational overhead alternative to issuing a
certificate - on any media.  Add a certificate saying "this is a real
smartcard" and the fraud exposure can be dropped to near zero levels.
Smartcards may be effectively distributed by mail, e.g. with a PIN
mailed a day of so later.  This issuing infrastructure already exists
- and makes sense for Internet operations.

Smartcard readers with keypads were on display at CTST for around
US$15-35.  Total costs can be less than the cost of simply issuing a
certificate.  And the authentication technology already exists in
back-end systems - PIN verification.

A bulk replacement/upgrade of all in-store mag stripe equipment is
uneconomic, except as a "phase in" approach, meaning 5-10 years of
mag-stripe co-existence for the in-store sales.

Certificates add no value to in-store purchases, and, used effectively
(e.g.  a simplified model as per above) add value to the Internet.

Used in "text book" mode/scenarios, secure, reliable, low dispute PKI
is not afforable - ever.

The ANSI draft you mention has the overhead of requiring a person to
(possibly manually) register a public key with their bank.  It's not
clear that this permits user mobility (home, work, PDA etc) without
banking system upgrades to include multiple certificate fields in the
user account/configuration file.

Regards,
Lyal
Virtual Business Associates    ECommerce Strategies and Internet Security
ACN 083 334 052
Ph;    02 9712 0205      Fax;    02 9712 0467      Mobile;   0416 097 120
1/37 Walton Crescent  Abbotsford NSW 2046    Australia

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
private key -> digital signature -> public key ... verification

secret key -> encryption -> secret key ... verfication/decription

in consumer secret key scenerio ... both the consumer and the issuer need to know the secret key and keep the secret key safe from both unauthorized tampering as well as unauthorized discovery.

secret key information can be any shared-secret ... pin, mother's maiden name, social security number.

if the infrastructure registers a public key in place of mother's maiden name, social security number, or PIN ... then the claim is that security of the infrastructure is enhanced ... since in shared-secret implementations the repository for the shared-secret has to be kept free both from tampering as well as unauthorized access. Simply replacing shared-secret (mother's maiden name, social security number, &/or PIN) in the account record with a public key improves integrity of the operation since unauthorized viewing of the value can not lead to compromise (i.e. shared-secrets are used to both originate as well as authenticate transactions ... registered public key can only be used to authenticate transactions ... but knowing a public key can't be used to fraudulently originating a transaction).

Authenticating a transaction via digital signature and public key doesn't have to be any more complex than authenticating a transaction with a shared-secret. The certificate payload weight that is typically associated with public key is because digital signature authentication has been combined with key distribution infrastructure (the certificate). In fact, a financial institution can manage a public key in exactly the same manner that it uses to manage shared-secret authentication values (with improved integrity). Enormous increases in complexity of typical public key infrastructures (compared to shared-secret authentication) is because they are trying to combine both the authentication business process and the key distribution business process in the same operation.

The consumer nees to protect the value used to originate a transaction in a manner proportional to the value of the associated business processes. CA PKIs, certificates, digital signatures all seem to be targeting very high value business processes which then require a corresponding high level of protection. However, there is nothing inherit in using digital signature technology for originating exactly the same level/value business processes that are supported by existing shared-secret operations. There is fundamentally nothing more magic in public/private key authentication ... other than some desirable characteristics that the entity authenticating transactions can't use the same value to fraudulently originate transactions ... other than that ... they can be implemented using exactly the same business processes.

The CA PKIs, certificates, non-repudiation, etc ... are not the only business processes that can take advantage of digital signature authentication technology.

Cost of AADS/X9.59 deployment can actually be done as a transition and significantly improve the integrity of the current infrastructure ... thereby reducing infrastructure costs and enabling increases in commerce velocity. In fact, the claim of being able to do parameterised risk management ... taking a page out of the credit card infrastructure with variable credit limits by account ... can actually parameterize the integrity of each transaction based on value of transaction, whether it was magstripe, x9.59 w/o chipcard, x9.59 with chipcard & PIN, x9.59 with chipcard & biometrics, what level of reader cetification, what level of system certification, etc.

The claim is that the transition to this form of parameterised risk management for the current DES/ATM base is the only way of obtaining a 50+ lifetime infrastructure. The same X9.59 digital signed transaction infrastructure can easily exist for the next 50 years if the transaction values and the assurance level of the cryptography and all hardware components are parameterised for the transaction. If planned correctly, the transition to this infrastructure can be made at very nominal cost if integrated with other infrastructure swaping already going on.

Viewing digital signing as an ubiquitous, pervasive business process ... and driving the envelope on a chip at the maximum assurance level that does nothing but a AADS digital signature ... an AADS chip can be integrated into every new magstrip card ... as a very small percentage increase in the fully loaded magstrip delivery cost.

The downside of the existing shared-secret infrastructure is that there typically needs to be a unique card and unique shared-secret assocated for each operation ... in part because of cross-domain liability issues (while you have some recourse if somebody at institution A misuses shared-secret A at institution A .... it is less clear prooving that somebody at institution A misused shared-secret A at institution B ... in any case there is significant lack of use of the same shared-secret across multiple domains and institutions ... even to people giving out different/unique "mother's maiden names" to different financial institutions). The upside to an AADS digital signature infrastructure over the traditional shared-secret implementation is there no corresponding downside to using the same public key for authentication across a large number of different instittions (I can register the same public key ... in lieu of a password ... in fifty different places ... and not have to worry about my local ISP also being able to access my employer's internal corporate systems).

The net is that an AADS augmented magstripe ... while only a minor increment increase on the fully-loaded magstripe delivery costs ... could easily decrease the number of magstripe cards that a person needed to carry (allowing the use of the same card across multiple different domains). A reduction in less than 5% of the cards issued easily covers the cost of adding AADS to every magstripe card issued. A savings of 50% in the number of cards issued easily covers the incremental costs of swapping the readers (over and above the swapping of hardware that is going on anyway).

AADS/X9.59 then is

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
>(with improved integrity).
I would say - mathematically easier to prove integrity, not a
blanket better

... ignoring the mathematics for the moment ... a financial institution has to provide a higher level of protection for a shared-secret authentication (since learning the value can be used to originate fraudulant transactions as well as authenticate transactions) ... and they still have to worry about the value being exposed.

public key has the attribute that any number people can learn the value of the public key and still are unable to originate fradulant transactions. this also is the characteristic that could allow a person using the same public/private key pair across multiple domains

simple upgrade RADIUS ... the dominant ISP authentication mechanism ... from password to AADS ... an AADS chipcard a person used with all their ISPs and websites could be the same card they used at the office and with their financial institutions.

The chipcard could be optionally "no activation", "pin activated", or "biometrically activated" ... as appropriate/desired by the individual/domain ... the account records would record both the key and the assurance level of the chipcard.

The same AADS/X9.59 infrastructure supports all assurance levels because the risk issues are parameterised. The option of using one card ... or as many as the person deemed necessary ... then can be a consumer choice ... some consumers could find a single biometrically activated card to their preference (meeting all their authentication requirements ... although different domains might also have minimum assurance level requirements).

Besides significantly expanding the consumer preference options ... the PIN/biometric characteristics (effectively forms of shared-secrets) are not exposed to the infrastructure ... they remain purely between the consumer and the consumer's privately owned chipcard (both an integrity issue and a privacy issue).

At its core ... AADS doesn't preclude integrating authentication & key distrubition (ala CADS models ... done for infrastructures ... especially offline, that currently lack authentication mechanisms) or require integrating authentication & key distribution (business and consumer related account-based opertaions which already have significant authentication and key management infrastructures integrated with their current business practices).

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
The AADS of registering a public key at a financial institution is more secure than a password ... since just viewing a password can lead to a compromise ... the password is both used to originate a transaction as well as authenticate a transaction.

Because the use of public keys in AADS is more secure ... and because knowing the public key can't lead to originating a fraudulent transaction ... then the consumer has the option of registering a public key in multiple places ... and still being more secure than a password inferstructure: In the case of consumer/merchant relationship ... and the work by the financial industry standards group on X9.59 ... the merchant doesn't care who the consumer is (i.e. x.509 certificate) and the merchant doesn't care what bank a consumer has a relationship with (again a x.509 certificate) ... the merchant cares whether or not the bank says that it will transfer the funds indicated by the consumer. In the payment card world ... this is the issuing banks response back to the payment instruction ... everything else is of little or no meaning to the merchant.

In the current physical world ... the financial world effectively has to assign the task of authentication to the merchant at POS. This is one reason for names on the cards ... so the merchant can cross-check name with other pieces of identification. european privacy mandate is going towards consumer/merchant not having identification ... which precludes x.509 identity certificates.

As a result ... the real thing that the merchant is interested in ... is whether the consumer's bank says it will transfer the funds ... means that the merchant authentication isn't critical in the payment transaction ... furthermore ... having another agent with little or no financial obligation to you ... authenticate on your behalf ... has been showned to be a great opportunity for fraud. Furthermore, privacy mandates are driving towards removing merchant requirements for authentication ... futher supporting the financial industry's standards work on having the financial institution do all (as well as end-to-end) authentication on all transactions it authorizes.

Side, simple rule from kindergartern security ... any time you have different entities performing authentication and authorizing ... the gap represented by the difference in interests between the two entities is the gap which fraud enters.

So the financial industry in its X9.59 standards work is: That is much more of a philisophical stand-point.

From the technical/practical standpoint.

Maintenance of shared-secret at a financial institution carries more headaches and risks because any employee having access to shared-secret potentially can utilize the shared-secret to impersonate and originate fraudulent transactions. Migration to public key registration infrastructures eliminates that risk, liability, and exposure.

All public key registration authorities are account-based .... fundamentally AADS. The difference between a pure AADS registration authority and a CADS registration authority is that a CADS registration authority returns a copy of a certificate as part of the registration process.

Again within the privacy mandates ... we see the european banks making an initial realization that they would return a copy of a certificate that is a relying-party-only certificate ...containing only an account number ... eliminating 1) privacy invasion of an identity certificate and 2) any liability associated with trust propagation.

However, we show that in a RPO environment, since the original of the certificate is stored in the account record ... with the copy being returned to the consumer ... and since any financial transaction involving the certificate has to reference the account record containing the original of the certificate .... having the consumer create a 1) transaction (containing the account number), 2) digitally sign the transaction, AND 3) append a copy of the certificate to combined transaction/signature is redundant and superfluous. Sending a copy of a certificate on every transaction back to the registration authority that has to read the account record containing the original of the certificate is a redundant and superfluous activity. Or put another way, knowledge-based compression of certificate size reduces the certificate to zero bytes for financial transactions involving account-based transactions.

A more valid point for reducing the certificate to zero bytes ... is that there are some existing financial transactions involving certificates over the internet ... which authenticate the signature at the internet boundary and strip the signature & certificate off before injecting the transaction into the financial network. It turns out the payload weight of transactions in the financial network are measured in bytes or tens of bytes. Current certificates are measure in thousands of bytes ... and current information/templat based certificate compression is reducing that to hundreds of bytes. Even with the best non-knowledge-based compression ... the size of the certificate is on the order of ten times larger than the transaction.

So certificate-based financial transactions tend to have one or more of the following characterisitics
unnecessary authentication by extraneous parties that can open the opportunity for fraud (not doing kindergarten security with end-to-end authentication)
unnecessary authentication by extraneous parties that can affect consumer privacy
unnecessary authentication by extraneous parties than can affect liability
large, onerous, redundant and superfluous payload weights on the financial infrastructure
unnecessary authentication by extraneous parties not responsible for authorizing/executing the transaction.

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
you wrote: 
I submit that X9.59 really changes where the integrity
functions happen -
and when the location change is factored into the risk >environment,
little benefit arises.  Unless there is some process in X9.59 to
secure the >user's computing device ?

Lyal


X9.59 doesn't randomly change where the integrity functions occur ... it very carefully follows basic kindergarten security tenets and careful puts the authentication at the appropriate place where it belongs.

In general, careful digital signature authentication processes eliminate sufficient possible explots (and in conjunction with various technology advances) that it starts to become practical to deploy hardware in support of those processes. In part, as you imply, if there are significnat number of vulnerabilities that aren't being addressed, adding hardware to the infrastructure isn't likely to materially affect the amount of fraud (and the associated costs associated with fraud).

There are in fact, additional processes that are enabled by X9.59 digital object signing draft standard ... that are being looked at to address both significant fraud and systemic risk issues (where X9.59 only represents one of the building blocks). Also, part of the problem is selecting the pieces of an infrastructure that have some chance of staying ahead of the technology advances ... especially in the area of exploits, vulnerabilities and exposures.

Part of X9.59 was to define optimal integrity process and the optimal data elements to achieve maximum return on investment ... including being able to make X9.59 applicable to all account-based payments in all payment environments.

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
In the simplest form, for financial infrastructures ... AADS doesn't do any of the referenced. In the simplest form, AADS recognizes that authentication is normally part of some business process ... not an operation being done just for the fun of authentication. Financial infrastructures already have loads of integrity and authentication processes that can have their intetrity simply upgraded by changing from shared-secret to public key ... w/o requiring certificate creation, etc.

The originally point of certificates were to be able to provide authentication services to environments (like offline email) that lacked authentication business processes.

Trivial example is the idea that the account record containing the registered public key can be altered. Turns out that financial institutions spend millions, tens of millions, and possibly hundreds of millions of dollars already to protect against unauthrized updating of the account record. Adding the public key registration field to that account record ... places the public key under the same protection as the rest of the data in the account record.

Now since authentication is just a fraction of the financial business process around do financial transactions ... the real fields of interest in financial transactions are things like the balance field, with authentication fields being 2nd order values "protecting" the access to the balance fields, i.e. things like the balance fields are the real target of attack/exploits. If i'm in a room with the gold and the door to the safe ... do I steal the gold or the door.

Now, also as part of the huge spending that financial institutions do on integrity, part of integrity is availability ... things like triple redundancy in different geographic locations where if two of the three locations fail ... the third location by itself has all the information to completely authentication, authorize, and execute the transaction. That means collecting all information into one place required to completely perfrom a transactions in all its forms, harden that one location, replicate that operation multiple times, and harden the protocols involved in maintaining consistency.

Rather than viewing public key as an independent PKI commericial process, view public key as a better form of authentication ... somewhat in the same way that triple-DES is view as better technology than single-DES for authentication. In the same way that I might have reasons for upgrading technology from single-DES to triple-DES ... financial infrastructures can also gain benetit from upgrading from triple-DES technology to ECC public key technology ... totally independently of any issues around certificates, independent PKIs, etc.

All sorts of things have been claimed about DES, single-DES, triple-DES, and ECC public key for authentication purposes. If the same exact infrastructure can be used for all varieties ... and if ECC public key provides better/stronger authentication technology at a lower cost (w/o having to impact any the rest of the business processes) then why should ECC public key be ruled out from the selection (just because it says public key instead of secret key)?

It almost seems like because lots of other business models for public key type methods have been promoted for developing independent business towers to satisfy authentication requirements in environments that totally lack existing authentication processes ... those are the only methods of implementing public key. In fact, public key technology can be implementing in existing shared-secret environments, using existing methods & practices and not having to resort to things like certificates. This is especially applicable to infrastructures that already spend huge sums of money for integrity purposes.

Certificates aren't magic. Certificates reliably bind together information. Business have been using account records to bind together information for ages. Secret key isn't magic, public key isn't magic. Just because that there is one way of magic proposed for public key doesn't a priori from being used as a secret key upgrade.

This isn't Public Key in capitals ... this is public key in little letters ... no magic ... no requirement that certificates are precluded or required.

Turns out the technology for (little letter) public key already exists at the required price/performance level ... if it is looked at from the appropriate point-of-view ... no more waiting is needed.

Another example of myopic view of business processes. One of the example has been using the argument that if somebody updates the public key field in a record ... then they can do unauthorized financial transactions against the record ... ignoring for the moment that in financial infrastructure that the jewel is the account record and if you can already do unauthorized updates of the account record ... updating the public key field enabling being able to do transaction updates is contrived. If you want to fiddle with account fields ... and you can do it already ... changing the authentication field (secret or public) to do a smaller set of updates (that allowed by directly accessing the record) is contrived.

The other contrived scenerio is the multiple updates if the public key is registered in multiple places. Typical scenerio is somebody has their wallet/purse gone missing. They then have to call maybe 6-12 places to make lost/stolen reports. This happens whether they have 12 different cards ... with 12 different public keys, 12 different cards with the same public key, two cards with 12 different public keys or two cards with two keys ... registered in 12 different places. For people finding calling 12 different places a problem ... most offer an 800 number where all 12 places can be registered (whether they are 12 different keys or a single key in 12 different places ... and regardless of whether the key(s) are implemented in one, two, or 12 physical devices). The extra careful are likely to have at least two, replicated methods of authentication ... carried in separate places. The less careful may carry all their authentication information in a single place. Nothing in converting to public key mandates one, two, or 12 authentication values .... it is just observed that converting to public key eliminates cross-domain contamination that is inherent in shared-secret methods ... which opens up choices for the consumer. A consumer that carries all twelve of their authentication tokens in the same wallet could make the choice of converting to a single token with a single public key registered in 12 places. Another consumer might choose to have two tokens, each with single public key, each key registered in six different places ... one token carried in their wallet and one carried in their shoe, and their may be other consumers that prefer to have twelve different tokens, each with unique public key, each key registered uniquely, and the twelve different tokens secreted in twelve different places about their person. The observation is that converting from shared-secret to public key ... removes cross-domain contamination/liability as an issue with respect to how a consumer may wish to configure their authentication procedures (and opens up choice).

... and 
Many continually fail to look at the holistic process involved in
certificate operation:
- registration
- certificate creation
- issuing
- transport
- storage

Most fail to include Private Keys in the operating environment assessment.

The integrity of this overall process needs to be assured.
AADS changes the order of actions outlined above - not replaces it.

When commercially afforadable ways emerge to implement Public Key based
processes with the same level of trust that PIN/password functions already
have in the commercial world (not academic "pure" theory), many will
rejoice, including me.
"Comercially affordable" includes the operations and support costs  i.e.
technology for the sake of business, not technology for the sake of
technology.

The state of play is not "there" yet, but yet the discussions keep
circulating around a narrow view of issues.

In the meantime, reliable processes already exist, and operate very well.

Banks already know their customers - hence Public Key adds little or nothing
to that authentication and authorisation relationship.

Regards,
Lyal


... snip ...

X9.59 & public key (little letters) is a higher integrity authentication process ... that given the current technology price/performance advances ... can be a perfectly valid method of improving the authentication business process and lowering fraud costs (in much the same way that triple-DES and DUKPT are being considered to strengthen the authentication business process). In that sense ... it is pure issue of integrity technology that doesn't (directly) impact existing business processes.

I agree with the statement that Public Key (big letters, commonly thot about independent authentication business towers ... disassociated from existing financial transaction core business processes) adds little or nothing to the consumer's authentication relationship with their bank. In point of fact, the certificates that are the typical instantiation of Public Key ... are specifically designed to be used between parties that currently lack existing business relationship ... effectively trust propagation (based on the any trust inherit in the certification signing authority) between parties that otherwise lack any other method of trusting. In that sense, Public Key (big letters) ...it becomes a significant issue of the changes to existing business processes and relationships.

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
re: PIN/debit process

... the AADS chip strawman, has a proposal that, in fact uses the majority of the existing debit card process to deploy a dual-card at close to the existing cost of a magstripe-only card ... the claim is that it has as high an assurance level than any non-debit-based process costing 100* more ... with certified assurance audit trail that can be used by risk managers for parameterised risk management (changing any characteristic of the proposal either significantly lowers the assurance level or significantly increases the cost).

the idea was not to invent brand new business processes ... but to trivially integrate better technology into existing business processes ... and leverage unique characteristics of the technology to significantly improve those business processes.

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
re: pin/atm/x9.59/etc

another example ... suppose I register with an ISP that has RADIUS upgraded to support AADS authentication (in addition ot passwords, etc).

they don't particularly care who i am ... they care that they get paid. currently process involves names and other identity information to track down stuff if I don't pay the bill.

However, if I do an online registration only giving my public key ...and append an X9.59 signed transaction ... then the ISP can 1) send the X9.59 transaction onto the financial infrastructure to get paid and get back an acknowledgement that they will be paid, 2) verify that the key in the registration can verify the x9.59 object, and 3) register the supplied public key for the account.

The online registration doesn't need to contain anything other than the public key ... no identity, no address, nothing. The ISP has enuf information about getting paid. The consumer then can use AADS digital signed transaction that is authenticated by RADIUS at the ISP.

One of the big problems currently at ISPs are lost and stolen passwords. AADS authentication with AADS chip (in whatever form factor) ... same chip that person uses for X9.59 transactions reduces that problem. btw, social engineering is one of the methods that has been used for stealing passwords.

RADIUS is the current dominant authentication mechanism for the internet, works in a parameterised account-by-account manner, already supports multiple authentication mechanisms (including password) ... and simple AADS upgrade to RADIUS allows all existing accounts to work like they have been ... and AADS upgrades be made as required or needed for individual accounts.

Since AADS chip never gives up the private key (easily) ... there is nothing to steal except the chip itself.

As described on the web site ... the AADS strawman chip is designed to be as high assurance as any existing smartcard chip ... and since everything other than what is required to meet the compelling business case has been removed ... the chip is significantly cheaper than existing smartcard chips. There is some line of thought that since it is so high assurance and so inexpensive that it can be deployed ubiquitously.

The implied volumes move the chip off the NRE part of the curve and onto pure FAB-costs part of the curve. Since all functions but those absolutely necessary have been removed ... the chip is significantly smaller and simpler ... further reducing NRE (shifting how soon you move off the NRE part of the curve) and increasing the yield per wafer (except for burn-in & test ... FAB-costs are pretty much per wafer).

As a total aside ... significant number of the CAs actually do a $1 auth with AVS as part of validating information that they register for an account/certificate.

Social considerations may dictate that ISP obtain additional information for account registration ... possibly age ... but AADS infrastructure can significantly reduce information needed than otherwise explicitly dictated (i.e. X9.59 and AADS are privacy neutral).

Also, the same characteristics that makes it hard for unauthorized people to do X9.59 transactions and use the ISP account ... also make it hard to share the account among multiple people (in that it requires specific AADS chip). In effect, this drives in the direction of everybody having (at least one) unique AADS chip ... with unique authentication accounts (although possibly setup to share the same resource account). This isn't so bad since most security/integrity tenets dictate unique authentication in any case (although it is frequently violated in password-implemented scenerios).

Also, there is some possibility that the form factor becomes the USB token ... in lieu of a card ... especially with the work on USB standardization for POS.

cardtech/securetech & CA PKI

From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
re: moving public key;;

the statements were:
ISP doesn't care who you are ... they care that you pay your montly bill for your account
consumer sends message with both a signed X9.59 object and the public key
the ISP sends the X9.59 transaction on to the financial infrastructure for approval
the transactions comes back approved
the IPS then verifies the singed X9.59 object with the same public key


the public key can't be modified and still have it verify the signed X9.59 object

for the public key to be modified and for it to also verify the signed X9.59 object; the complete message would have had to be replaced in transit (not just the public key .... i.e. an attack would have had to substitute the attacker's account, sign the X9.59 transaction on the attacker's account with the attacker's private key and supply the attacker's public key).

In effect, the online CA registration models ... use the same process ... send a public key and send something that you have signed with the corresponding private key. If the signed object verifies ... then the public key is assumed to match the private key.

To prevent complete man-in-the-middle attacks on registration ... most places will use some form of SSL/TLS to wrapper the whole process ... not just this component ... userid selection, feature/function selection, yes/no web pages, etc.

RADIUS is one of those infrastructure things ... that majority of (internet) users utilize everyday w/o realizing it.

For more on RADIUS see

https://www.garlic.com/~lynn/rfcietff.htm

select RFCs listed by Term (term->RFC#) and select RADIUS from the Acronym fastpath. It currently lists RFCs 2548, 2139, 2138, 2059, & 2058.

Other RADIUS reference
https://web.archive.org/web/19990429174356/http://www.cisco.com/warp/public/732/111/555_pp.htm
http://www.phdtek.com/security/protocol/Radius/Links.htm
http://www.phdtek.com/security/protocol/Radius/overview.htm
https://web.archive.org/web/19991012153454/http://vpo.axent.com/prna/press/dsspr.htm
http://www.acc.com/internet/whitepapers/radius_old.html
https://web.archive.org/web/19991116102736/http://www8.zdnet.com/pcweek/reviews/0811/11rem.html

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
Date:  06/01/99 08:48:28 AM
re: isps/x9.59/radius/etc;

however, for high-value ISP operation ... where risk managers come into play and the AADS certified audit trail is required ... not just the public key information... but the assurance level of the chip (and to really know that it isn't some copy-chip obtained in some retail store) with certified audit trail, whether the form factor contins "on-card" pin-pad or biometric sensor, etc .... then AADS would provide a non-mon transaction that would need to be authorized by the account owner ... which will return the certified assurance level of all the components.

for lower assurance form factors w/o activation and/or on-card activation input ... separate assurance level is specified for the reader ... i.e. keyboard reader with pin-pad cut-out mode (i.e. if the card doesn't have its own, on-card pin-pad input, and this is normal PC with keyboard reader ... there is special pin-pad mode that cuts-out the keyboard interface to the PC ... bypassing the lower-assurance PC processing.

There are several possible assurance levels associated with chip activation ... including pin activation with pin-code flowing thru a PC that might be less than B3 secure and could possibly contain trojan horse software. For ubiquitous deployment ... it will be necessary for the infrastructure to support a wide variety of assurance levels ... but as mentioned in prior descriptions ... that doesn't prevent the identification/selection of best-of-breed technology (and assurance level) in each spectrum of the market segment. Given appropriate price-point level ... it is even possible for individual to select biometric activation where the biometric sensor is built into the form-factor housing the chip (however, at the moment, such a option/feature is simewhat beyond a $1 price-point).

cardtech/securetech & CA PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: ecarm@xxxxxxxx
Subject: RE: [ECARM] cardtech/securetech & CA PKI
you wrote: 
lynn,

While in the abstact it may be true that the ISP only
cares about getting paid, it turns out that it is not
100% true.

We find that we also care that we know the person,
so that we can manage behavior. When we get spammed
by our customers, it is a real problem. So we want to
have ID information, so that when they do spam us,
pass us porn, or wares that we can respond appropriately.

If we can not identify people, then we can't maintain
the performance of our systems, which translates into
a direct cost to us.

-----
John Sechrest          .         Helping people use
PEAK -               .           computers and the Internet
Public Electronic         .            more effectively
Access to Knowledge,Inc       .
850 SW 15th Street              .            Internet: sechrest@xxxxxxxx
Corvallis Oregon 97331               .                  (541) 754-7325


there is a couple issues:
conflicting goals of privacy vis-a-vis responsibility
cost of following evidentiary trail back to unacceptable behavior (including court orders if necessary)
ability to operate a service organization


... in #3, one of the surprising things that we found was that even for certificate based financial transactions where the consumer's financial institution was involved in no "protocol" way with either the certificate or the digital signature authentication process ... (and furthermore this was tauted as cost advantage) the consumer's financial institution realized that they still had to register the publickey/certificate in the account record in order to provide consumer service (i.e. if the transaction didn't work, the consumer called his bank ... not some nebulous entity that they never heard of which was supposedly doing authentication and had no idea who the consumer was). Turns out that the cost of deploying a digital signature authentication protocol was negligable compared to cost of providing consumer call-center support for doing digital signature transactions, registering a value, and providing customer call-center support for managing registered value (and if there were multiple registered values ... the cost was typically proportional to the number of values).

In #1 & #2, as mentioned before ... a great deal of trouble was gone into AADS & X9.59 to make them privacy neutral ... allowing both privacy and responsibility to be handled outside the protocol.

However, both X9.59 and AADS can support strong evidentiary audit trail ... much stronger than existing password/pin based schemes. If social dictates are such that audit trail might end at an anonymous point ... then there is less responsibility. If that evidentiary audit trail ends at a non-anonymous point then there can be more responsibility (and to what extent organizational, social, and governmental mediation is involved in the privacy vis-a-vis responsibility, for instance are court orders required or not).

One of the interesting current trade-offs is to what degree can an ISP invade personal privacy and/or directly associate particular activity with particular individuals vis-a-vis is an ISP directly responsible for the actions of its customers/individuals. To some degree similar tradeoffs are being discussed in the financial community regarding various "know your customer" mandates ... and to what extent is a financial institution responsible for socially correct behavior on the part of its depositors (at least some mandates are pushing that the financial transaction flowing thru a merchant ... even POS, should require NO direct identity information ... although account number might possibly represent indirect/obscure identiity information).

Since there are going to be a very broad range of requirements, and likely to be a broad range of different implementations over the next 50+ years ... the only way to define a long-life infrastructure was to move the variables (like privacy/responsibility) out of the base protocol (i.e. allow broad applicability across broad range of time, space and circumstances).

A variation on this scenerio ... is with a unique (at least one) AADS token-based authentication per individual ... there are discussions about not only being able to do non-mon transactions (as part of registration) for assurance levels (in order to more accurantely implement risk management) ... but also for things like birth date. There are social mandates being kick around where ISP-related activity be restricted by age. Is authenticated audit trail (as to age as part of ISP registration) an invasion of privacy or not? In theory, it is a straight-forward attribute to add to RADIUS authorization information. You could then imagine an out-of-band web server RADIUS transaction to the ISP of record to obtain birth date ... or a non-mon transaction to the financial institution to obtain birth date.

Authentication in eCommerce applications

From: "Anne & Lynn Wheeler" <lynn@xxxxxxxx>
Newsgroup: comp.security.misc
Subject: Re: Authentication in eCommerce applications
X9.59 is draft standard by the financial industry standards organization for all account based payments in all (electronic) environments ... i.e. web, point-of-sale, settop boxes, etc. It specifically defines a signed payment object ... but does include something that is defined as the hash of purchase order ... providing binding of the payment authorization to something like a purchase order (it doesn't sign the purchase order ... it signs something that authorizes payment for the purchase order ... with a binding to that purchase order ... which ... in effect ... signs the purchase order ... although indirectly).

at point-of-sale it implies a hardware token capability supporting the digital signing of the payment object.

for related info ... see


https://www.garlic.com/~lynn/

Authentication in eCommerce applications

Refed: **, - **, - **, - ** 
From: "Anne & Lynn Wheeler" <lynn@xxxxxxxx>
Newsgroups: comp.security.misc
Subject: Re: Authentication in eCommerce applications
... also ... slightly related ... there is IOTP work going on in IETF and other activities ... however 
From: Lynn Wheeler
To: Robert Hettinga <rah@xxxxxxxx>
cc: dcsb@xxxxxxxx
Subject: Re: Interoperable Micropayment Order
Note that there is an X9 draft standard for all account-based payments in all electronic environments (web, point-of-sale, set-top, etc) ... X9.59. X9 is the financial industry standards body and the US interface to ISO for financial standards.

I had proposed & did a draft version of the underlying authentication model for IETF standardization. However, there was intense push to (also) process it as an X9 standard ... regardless of any possible standardization effort in other bodies (including IETF). In part, the use of X9 (and/or ISO financial) standards by financial institutions meets due diligence requirements that aren't characteristic of standards done by other bodies.

for reference there is description at


https://www.garlic.com/~lynn/

KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: Stephen Kent <kent@xxxxxxxx>
cc: Eric_Guerrino@xxxxxxxx, "'ietf-pkix@xxxxxxxx'"
<ietf-pkix@xxxxxxxx>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))
there would also appear to be a semantic problem here .... public key can be used in lieu of passwords to authenticate.

digital signatures have a lot of advantages over passwords .... like the method of authenticating the digital signature (the public key) is not prone to password compromise (eliminating the problems with having a single password across multiple organizations and/or having to write down the passwords if unique passwords are alwas selected).

certficates are one method to authenticate the public key ... but there are also certificate-less PKIs that use other methods of providing the public key.

the dominate authentication application across the whole internet sphere is RADIUS (ISPs, corporate networks, intranets, extranets, etc). A simple upgrade method has been demonstrated for radius that registers the public key in place of the current business processes that register a password (selectively on an account by account basis) ... and then digital signature authentication is used in lieu of password authentication.

One of the simplest issues is that a standard X.509 "identity" can represent privacy invasion and/or violation of privacy mandates if full name/details are available ... or if relying-party-only certificate is used .... it it is trivial to show that if the authenticated transaction has to hit an accound-record (like logging on to an ISP and the ISP wants to know if your account is still active ... and hasn't been voided because of something like spam'ing) then having the certificate is redundant and superfluous since the public key can be extracted from the account. it also eliminates any question of legal issues that having been shroading certificates in the area of trust propagation

The interesting thing is that certificate-less PKIs tend to preserve exactly existing authentication business processes .... while at the same time being able to utilize off-the-self digital signing protocols/technology (just forgetting to append the certificate when sending off the transaction, or if you will, using knowledge-base compression to compress the size of the certificate to zero bytes).

In that sense, certificate-less PKIs are one of the most aggressive applications of KISS (elimination of redundant and superfluous business processes when there are perfectly good processes in place today).

Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: Stephen Kent <kent@xxxxxxxx>
cc: Eric_Guerrino@xxxxxxxx, "'ietf-pkix@xxxxxxxx'"
<ietf-pkix@xxxxxxxx>
Subject: RE: Common misconceptions, was Re: KISS for PKIX. (Was: RE:
ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
from another standpoint (in part because of not having to worry about all the extraneous issues raised with certificates) ... some of the certificate-less PKI work is looking at the risk issues ... especially within the context of the financial industry (financial operations are hot on calculating risk ... so they can correctly price/predict business ... in large part finance is a risk management business).

In the finance arena ... significant business processes exist that deal with establishing the initial business (i.e. certification by any other name) as well as validating transactions. On a transaction by transaction basis ... technology is needed that improves the integrity of the transaction ... i.e. digital signature in lieu of passwords/pins/names.

Assuming a digital signature authentication process ... it then is beneifical to accurately calculate the risk & assurance level associated with that digital signature .... i.e. is there an evidentiary, audit trail showing a hardware token, the assurance level of the hardware token, whether the hardware token has an activation process, whether any such activation process is PIN or biometric.

One of the interesting issues ... somewhat in line with the problems associated with using identify certificates flowing over open networks on every transaction ... is flowing biometric information over open networks. Having a biometric activated hardware token that the person "owns" ... means that the biometric exchange is only between the person and their token (side-stepping the privacy invasion and privacy mandates).

One could make the case, that in account-based business processes ... the inhibitor to certificate-based PKIs is that they create redundant and superfluous business processes and don't eliminate any processes (i.e. increasing cost while not showing any corresponding benefit). certificate-less PKIs tend to leverage existing account-based business processes ... i.e. optimal improvement of integrity at optimal increase in cost.

In the financial industry ... an area of opportunity for PKI registration and audit trail (i.e. not duplicating existing business processes) is providing an evidentary trail regarding the assurance level of the components used in a transactions.

An example is providing at sign-up time additional information about the integrity and characteristic of the hardware token (password/public-key and person sign-up is already existing business process) with respect to integrity of the crypto, integrity of the chip involved, what kind of token activation is employed, etc. This is a new process, that doesn't duplicate existing processes and is useful information for risk managers .... and provides the basis for creating parameterised risk management. The usefulness of this can then be shown to have three benefits: parameterised risk management of components involved in authentication technology can be demonstrated business case for new business processes that aren't covered/duplicated today.

As a working hypothesis ... business cases for new duplicate, redundant and superfluous sign-up procedures are hard to make ... especially in account-based environments ... when they don't show a corresponding elimination/reduction in other sign-up processes.

KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: Stephen Kent <kent@xxxxxxxx>,Eric_Guerrino@xxxxxxxx,
"'ietf-pkix@xxxxxxxx'"<ietf-pkix@xxxxxxxx>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))
another interesting scenerio for RADIUS is that most webservers ship with stubs for authentication and then sites frequently do roll-your-own userid/password lookup processes. ... a straight-forward scenerio is to provide a RADIUS protocol stub for web-servers ... then on an account-by-account basis the ISP (&/or web operator) can use the same administrative interface for managing account/userid authentication (for both internet/intranet/extranet authentication and client-side web authentication).

futhermore ... on an account-by-account basis ... the site/operator then can choose from a menu of RADIUS supported authentication mechanism at the account/userid level (and in the straight-forward case, public key registration is done in the same business process as password registration ... and digital signature authentication becames a straight-forward alternative/option to password authentication)

... and an interesting reply made to the above
RADIUS is an important and worthy authentication server. Switch vendors are now or will soon use RADIUS for port based network access. There is an approved PAR within the IEEE 802.1 group (802.1x) that will give the adminrator the option of requiring user authentication prior to opening up the switch port. Although the spec will most like not specify an authentication server(s), RADIUS is one authentication means that can be used to verify identity (and leverage its vendor specific attribute #26).

KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: Stephen Kent <kent@xxxxxxxx>
cc: "'ietf-pkix@xxxxxxxx'"<ietf-pkix@xxxxxxxx>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))
a cert-less approach is relatively trivial to apply across the corporate electronic environment. register the employees public key in a RADIUS administrative data-base (i.e. RA by any other name) and use RADIUS protocol for all corporate authentications i.e. existing RADIUS based authentication and straight forward apply RADIUS protocol to future applications.

This even works in SSL and other types of environments. Consumer's authentication at the server is done with RADIUS account-base.

This doesn't say anything about eliminating web server comfort certificates ... for setting up SSL sessions ... just addresses issue of authenticating individuals in environments that are really account-base operation.

The RADIUS protocol also addresses things like permissions ... again not carrying sensitive individual information in credentials like certificates ... but going to the account record to obtain the permissions and operational characteristics. as alwas choice is: 1) fully defined, identity certificate 2) relying-party-only certificate where the transaction has to hit the account record.

either all the necessary information is in the certificate or the certificate contains only enuf information to be able to get to the account record. if the operation has to hit the accound record anyway ... then it is trivial to show that the certificate is redundant and superfluous.

it wasn't intended to be a red herring statement ... it was a statement that is was one or the other ... either all the necessary information is in the certificate (in which case the certificate can represent a privacy and/or security issue) or the information is in an account record (in which case the certificate is redundant and superfluous).

this of course, doesn't apply to saying that the merchant comfort certificates (using for setting up SSL sessions) are unnecessary ... but that almost all cases that the certificates for employees and individuals ... tend to either 1) divulge privacy/confidential information or 2) have to hit an account record.

Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: Stephen Kent <kent@xxxxxxxx>
cc: "'ietf-pkix@xxxxxxxx'"<ietf-pkix@xxxxxxxx>
Subject: RE: Common misconceptions, was Re: KISS for PKIX. (Was: RE:
ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
i believe the context of the reply was within the statement of what are the reasons why cert PKIs are having hard time. One of the issues raised was cost ... part of that scenerio is that digital signature authentication can be separated from the question of cert infrastructure costs ... i.e. semantic confusion that the digital signature authenticates the transaction (not the certificate) and that the certificate is one method of authenticating the public key. The digital signature business case can actually be separated from the certificate business case (they don't have to be synonomous) ... leaving the certificate business case to show that it can eliminate/reduce cost of existing account-based operations.

One way is to show identity certificates carrying all information and permissions can eliminate the accounts ... but that introduces privacy and security exposures. The other way is to show relying-party-only certificates ... with no information but an account number .... which then have to hit the account record ... at which point the certificate can be shown to be redundant and superfluous.

So examining the parameters and operational regions for certificate business cases .... it is useful to understand where they provide significant benefit like in the webserver comfort certificate case. .

KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: Stephen Kent <kent@xxxxxxxx>
cc: "'ietf-pkix@xxxxxxxx'"<ietf-pkix@xxxxxxxx>
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))
oh yes ... and to some extent the cert-less work, in fact grew out of working on various SET projects (or lets say that the size of the certificate was compressed to zero bytes).

1) first off, set doesn't provide end-to-end authentication ... the digital signature/cert is verified at (essentially) and internet boundary and then the digital signature and cert is stripped off the transaction before forwarding to the customers bank for final authentication, authorization, and execution. The forwarded request does have a flag turned on saying whether the sender successfully performed a digital signature authentication. Two years ago, visa presented some number at a ISO meeting in europe on the number of transactions coming thru which had the digital signature validated turned on ... and for which they could proove there was no digital signature capability (one of the simple hazards of not having end-to-end security). Furthermore, the digital signature authentication was just a preliminary screening and the consumer's backend actually performed the real authentication, authorization and execution using account record information.

2) while not part of the SET specification ... every institution that I know of that looked at doing SET generated a work request to add the certificate/public key to the consumer's account record.

3) trying to achieve end-to-end security with transaction that hits the account record anyway ... in an infrastructure where the base transaction is 60 bytes and there may be thousands of these per second ... it was a significant task to get the operational people's attention that they should let an extra 80bytes pass thru the production infrastructure (digital signature plus a little bit more) on each transaction.

So applying a little bit of knowledge-based compression on the data to pass thru the infrastructure ... in order to meet guidelines for end-to-end security ... started trying to throw out every byte that was absolutely not necessary.

that was when it started to dawn that a certificate contained either all the information to do the transaction or had a pointer to an account record that contained the necessary information. If the transaction has to hit an account record anyway ... then a little bit of knowledge-based compression ... compressed the size of the certificate to zero bytes.

this is also a result of a more precise definition where the digital signature authenticates the transaction ... and any certificate is used to authenticate a public key used in the digital signature ... but certificates doesn't have to be the only method of authenticating a public key (account records have been used by businesses for eons for validating various information ... like current account balance). The certificate doesn't authenticate the transaction ... the digital signature authenticates the transaction ... and any certificate is used to authenticate the public key.

so back to the question in the thread about the issue of of certificate PKIs costs being a downside inhibitor .... it may not only be the raw costs of the certificate PKIs that is in question ... but also the fact that in several environments that they may represent redundant and superfluous costs. The issue then is that for such environments ... either the redundant and superfluous costs are not appropriate and/or certificate PKIs need to find a way of leveraging their characteristics for eliminating other costs.

And to re-iterate ... fully qualified identity certificates carrying full permissions can be used to eliminate use of account records (which can in turn raise privacy and security concerns) ... or they just carry a pointer to the account records ... which makes it harder to show that they aren't redundant and superfluous.

KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: BalluffiF@xxxxxxxx
cc: kent@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
ACTION :draft-ietf-pkix-scvp- 00.txt))
It isn't so much that it is applicable to "closed-systems" ... it is applicable to systems that create some front-end sign-up/trust relationship and then perform on-going transactions based on more global trust equation that isn't atomic & self-containable on a per transaction basis (like information aggregation ... i.e. account balance which is the combination of all deposits minus all debits/withdrawals)

certificates are useful in situation for providing "on-the-fly" trust where none previously existed. for random interactions this basically combines both the transaction and the trust information into a single operation (where the scope of the trust propagation can be transaction atomic and self-contained within the definition of a certificate authorities policy and practices).

For instances where setup/sign-up trust operations are part of the business process ... certificates may or may not represent a mechanism for establishing the initial trust environment (potentially replacing existing trust establishment procedures). Part of the issue of transaction trust in a financial environment includes aggregation information ... like current account balance). As such, financial institutions establishes a more complex trust environment including sign-up/setup that brackets large set of individual transactions (instead of repeatedly doing all of the trust establishment on each transaction).

in the x9.59 scenerio ... while the bank card transactions appear to operate between the consumer and the merchant ... in reality the merchant is acting as a transaction conduit to the consumer's financial institution ... where the consumer is instructing their financial institution to transfer funds from the consumer's account to the merchant's account

possible objective for certificates is being useful for trust propagation in environments currently lacking existing trust infrastructures. webserver comfort certificates are useful in providing such trust ... even without certification authority infrastructures (i.e. simple certificate manufacturing processes).

so looking at banking ... the issue for certificates is looking at the part of the business process where trust establishment enters into the equation ... and being able to leverage the trust propagation characteristic of certificates.

It isn't so much whether there is an open or closed characteristic ... it is whether the trust establishment occurs on every transaction or if there is an business infrastructure that has a setup/sign-up phase for establihing trust (i.e. setting up a bank account and maintaining the existing bank account balance).

So, to the extent, that certificate authority policy and practices covers areas of trust propagation that coincides with trust attributes needed in the signup/setup process ... then specific certificate trust propagation is useful at that setup/signup point.

KISS for PKIX

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: "Flanigan, Bill" <flanigab@xxxxxxxx>
cc: "'David P. Kemp'" <dpkemp@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: RE: KISS for PKIX
you wrote:
HMM, YOU'VE LOST ME HERE, DAVE. I HAVE NO IDEA HOW AOL OPERATES. BUT IF A CERT IS USED SOLELY AS A REPLACEMENT FOR A PASSWORD, WHY BOTHER? (YOU WOULD PROBABLY HAVE TO TYPE IN A PASSWORD ANYWAY TO ACCESS THE CERT IN THE CLIENT (OR TOKEN) AND ENABLE IT TO BE SENT TO THE SERVER.) THIS SEEMS TO ME TO BE A NEXT-TO-ZERO LEVEL OF ASSURANCE, WHICH IS NOT, I HOPE, WHAT PKIX IS ABOUT (WHY USE HDTV TO VIEW TRANSPARENCIES MEANT TO BE USED WITH A MAGIC LANTERN?) AGAIN, DAVE, IT'S SMART FOLKS LIKE YOURSELF WHO CAN HELP MAKE THE *RIGHT* MODIFICATIONS OR ENGINEER AN OVERHAUL/ REPLACEMENT AND THEREBY GREATLY AID EARLY (AND LATER?) ADOPTERS. ONE WAY OR THE OTHER, I FEEL THAT THIS *CHASM OF COMPLEXITY* BETWEEN PROTOCOL DEVELOPERS AND ADOPTERS MUST BE BRIDGED FOR PKIX/X.509 TO BECOME THE PKI FLAVOR OF CHOICE FOR THE PLANET.

.....................................................

password is shared-secret .... shared with the organization that is authenticating you.

digital signature ... & public key in place of password has lots of appeal ... especially coupled with hardware token (applies to both CADS and AADS implemenations)

even if the hardware token is pin/password protected ... current password compromise can be done in number of ways (thru the network, social engineering, etc) ... and then just knowing the password, compromises the integrity of the service. In the hardware token case, service is only compromised if the hardware token is also stolen (something you have and something you know).

at recent presenation there were claims that password exploits were trivial in great majority of cases because either 1) person used same password for all their services (security exposure in itself) or 2) used all different passwords ... but had to write them all down and keep them in convenient place.

If #1 ... do various knowledge guessing &/or go after one of the lower security systems to gather a copy and then exploit all systems

if #2 ... hire janitors to search in & around keyboards for password list.

integrity of hardware token is such that it is realistic to use same hardware token for multiplicity of authentication purposes.

KISS for PKIX .... password/digital signature

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: "Flanigan, Bill" <flanigab@xxxxxxxx>
cc: "'David P. Kemp'" <dpkemp@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: RE: KISS for PKIX .... password/digital signature
Date: Tue, 27 Jul 1999 07:32:23 -0700
another characteristic (again applies to both aads as well as cads deployments)

is that protocol and authentication process can be common across a wide variety of integrity implementations for the source ... i.e. software protected private key, hardware tokens for private key, pin activated token w/key, biometric activated token w/key, assurance level of the token, assurance level of whether dealing with known chip or possibly copy-chip.

somewhat not be encumbered with figuring out the meaning of a certificate ... we've had little more luxary to look at other critical areas ... things like can we parameterize the infrastructure and use the same infrastructure for very high value things (possibly billions of dollars) as well as relatively low value things (tens of cents) ... and leverage the infrastructure parameterization to adapt of periods in the 50+ year scale. The result is that risk managers can look at the infrastructure and make informed decisions regarding components necessary for specific risk levels.

This is a avenue that could also be applied to certificate/offline infrastructures ... although the perceived incremental value proposition would be different .... i.e. high value transaction risk assesement is not only looking at integrity levels of the components but also various real time and aggregated information

in that sense the certificate/account analogy is somewhat like badge entry systems ... their are both online (aka account, presumably even DOD has at least some online badge entry systems) implemenations as well as offline (aka certificate) solutions for badge entry systems. Offline/online choice can be combination of cost, risk and liability. the liability one can be tortured trail ... i.e. if something adverse is learned then can a person be instantaneously fired and all access revoked (liability can shift based on when something is known ... and business processes like liability insurance can dictate how something is handled).

KISS for PKIX. (authentication/authorization seperation)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
To: Stephen Kent <kent@xxxxxxxx>
cc: "David P. Kemp" <dpkemp@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: RE: KISS for PKIX. (authentication/authorization seperation)
re: authentication/authorization seperation

we seem to be dealing with two different issues ... possible analogy is gravitational force distances vis-a-vis sub-atomic partical force distances.

seperation of authentication and authorization between different random organizations ... where critical business dependencies falls to competitors with different goals, objectives and policies I consider not a good thing.

however, it is reasonable to consider consistent & controlled checks & balances within a business unit desirable. in some situations, finance industry will have critical approval personal on mandated vacation ... so others are foced to participate in approval process. there can also be sophisticated controls to preclude collusion between collections of people attempting to bypass organizational checks and balances. such operations tend to have consistent policies and practives and capable of enforcing checks & balances consistency within a business operating unit.

such considerations is far different from seperating authentication and authorization by such wide margins that various operations may actually randomly & uncontrollably be undertaken by direct competitors.

as such, i considered that i've been making statements regarding (authenticaqtion & authorization) seperation guidelines operating from fthe context of gravatational distances vis-a-vis other statements about guidelines applied at sub-atomic particle distances.

within business context, creating a very high integrity security perimeter and operating practices ... and then allowing critical operations to occur outside of that perimeter (and at a much lower &/or unknown integrity level) is foolish seperation of function. that is a totally separate issue from sophisticated anti-collusion practices that might occur within known security perimeter and operating practices.

from a business practices standpoint there is also an issue of infrastructure complexity ... creating multiple independent security perimeters and operating practifces ... solely to address the anti-collusion problem is frequently not justified ... i.e. anti-collusion tends to play at some of the higher integrity levels .... and multiple independent secruity perimeters and their required interaction not only drives up the cost significantly ... but can also contribute to infrastructure degradation because of increase complexity of interactions and unforeseen failure modes (i.e. directly related to violating KISS).

At least some major consideration for looking at account authority solution was to "cost-share" existing security perimeter & operating practices w/o necessarily having to create new ones ... especially when it can be shown that such leveraging at least increases the integrity of the environment at the optimal price/performance ... resulting in maximum ROI.


AADS Postings and Posting Index,
next, previous - home