Subject: Re: Trading Partner Web Certificates

From: [email-masked]
Date: Wed, 5 Jul 2000 09:43:07 +0300

Doug, your design below requires distribution of the private key of the
trading partner to each of its employees allowed to access your site. This
clearly creates significant exposure to this key. What are the reasons for
taking this risk, rather than having the trading partner (or you) issue
certificates to each employee of the business partner allowed to access
your site?

If the problem is the need to manage a potentially complex policy for
deciding which users can access your site (using which certificates)...
this can be easily achieved using e.g. our Trust Establishment system
(download from our site http://www.hrl.il.ibm.com).

Best Regards,
Amir Herzberg

IBM Research Lab in Haifa (Tel Aviv Office)
http://www.hrl.il.ibm.com

"Doug M Williscroft" <[email-masked]> on 06/23/2000
09:30:21 PM

Please respond to "Doug M Williscroft" <[email-masked]>

To:   [email-masked]
cc:    (bcc: Amir Herzberg/Haifa/IBM)
Subject:  Trading Partner Web Certificates

This note is to elicit feedback on a PKI model that my organization has
implemented for web delivery/collection of information. We call it the
"trading partner certificate" model.

The trading partner certificate model does not attempt to provide the
full benefits of the grand PKI vision but limits itself to browser-based
extranets. The solution we have adopted is rather simple but - due to
limitations of existing technology - not especially elegant. Even so, we
believe it to provide significant authentication benefit at at
significantly lower cost than other alternatives.

At the end of this note I describe a desirable new function for
certificate management (at the browser and/or OS) that would provide
broad benefit for extranet applications under this model.  I believe
this additional functionality would be relatively easy to develop, and
would quite possibly find a large market.

Our model:
1) Establish a trading agreement with an organization through standard
business processes which include contractual definition of obligaitions.

2) Issue a trading partner certificate to the organization. (In our
current case the certificates are "anonymous"; they make no statement
about the trading partner. This is not a necessary component of the
model. Neither is it necessary that we be the certificate issuer.)

3) The trading partner installs the certificate and private key on all
browsers that will be used to access our services. (Most of our trading
partners use the IE5 browser which allows the private key to be flagged
as "not exportable" from the computer - a highly desirable feature in
our from our perspective.)

4) The trading partner registers its users in our extranet directory -
and assumes responsibility for managing those users - including
assignment of access permissions within the bounds of the trading
partner agreement. (At this point user administration requires some
intervention on our part - we anticipate fully externalized user
management in the future.)

5) Users connecting to our web servers are challenged (via SSL) to
provide a client certificate.

6) Users presenting a valid trading partner certificate are challenged
for UserID and Password.

7) Users presenting a valid password and the correct trading partner
certificate for that user's organization are granted access to the
appropriate services.

To impersonate a user an attacker must gain direct access to a computer
in the trading partner organization, and gain knowledge of a valid
userID and password pair. We see this 2-factor mechanism as offering
protection against password discovery (by attackers external to the
trading partner organization), and against man-in-the-middle attacks
based on URL hijacking or DNS poisoning.

Desirable new certificate management functionality:
It would be helpful to our trading partners if certificates/private keys
could be centrally distributed en-masse to all computers/user profiles
in a trading partner organization. Currently, our trading partners must
manually install the private key to each user login account that will
use our services - a tedious activity. This task must be repeated prior
to certificate expiry. Fortunately our trading partners are willing to
accept this administrative burden because they consider the services we
offer sufficiently valuable.

Comments?

--
Doug Williscroft
HealthNet/BC Architecture and Standards Branch
Ministry of Health Information Management Group

Telephone: (250) 952-2497
_______________________________________________

---

From: "Doug M Williscroft" <[email-masked]>
Date: Fri, 14 Jul 2000 16:16:24 -0700

[email-masked] wrote:
> clearly creates significant exposure to this key. 

Amir, 
You are correct that the primary risk is in the broad distribution of
the private key within an organization. Since the key is *intended* to
identify the organization this would not be a risk *at all* if it could
be 'guaranteed' that the private key could not be removed from the
machine on which it has been installed. 

IE5 offers exactly this function, though I understand that there is
reasonable doubt about the quality of the function. I understand that
there is the possibility of attacks against the design and
implementation of the MS base cryptoprovider. All documents I have seen
on this topic are in reference to older versions of IE, though some of
the criticisms were against core design choices made in the cryptoAPI.
Even so the avenues of attack are enormously reduced over simple SSL and
uid/pwd. 

To reduce/eliminate the risk you identify, it would be nice to see a
cryptoprovider that could truly "lock-down" the private key. 

As I see it, a equally important issue is ease of administration; it
would be helpful if there were a way for an organization to easily and
centrally install the trading partner certificate on all relevant
machines.

> What are the reasons for

Why do we not issue individual certs to individual staff of external
trading partners:
 * Cost of issuance is unnecessarily high:
      requires tight integration with external trading partner hiring
practices. 
      Furthermore, organizational linkages are so loose, and lag times
so great, 
      that certificates cannot be certain to be revoked in a timely
manner. Individuals 
      would potentially retain access to our system long after they had
left the employ 
      of the trading partner. By using a locked down trading partner
cert, once the 
      ex-employee leaves the premises, they lose access.

* Cost of certificate administration very high for trading partners. 
      Several of our larger trading partners have staff that move from
workstation 
      to workstation. Individual certs introduce the need to manage the
details of 
      which workstations get which certificates. "Trading partner"
certificates 
      sidestep this issue entirely.

Why not have trading partner issue individual certs:
* Almost all (99% +) of our trading partners do not have the technical
or financial 
      ability to operate an internal CA. 
* Some smaller portion of them (80%?)do not have the financial
wherewithal to contract 
      CA services.
* Purchasing low assurance commercial certificates presents
administrative issues 
      (one year expiry increases effort required by both ourselves and
the trading partners).
* For many of our trading partners the cost of administering individual
certificates 
      is very high (shared workstations and roaming).