22nd November 2005
Purpose
In order to gain the overall administrative "win" by choosing
strong authentication, it is critical to make the setup of keys and
certificates very easy, which in turn leads to the requirement on making
Certification Authority interaction easy. This paper looks at how to
achieve this goal, and Isode's approach to the problem.
Background
Strong authentication uses certificates as a means to identify one
or both parties in a transaction. A certificate contains the name of
its subject (the person identified by the certificate) and the name
of a Certificate Authority (CA), who vouches for the identity of the
subject. Additionally, each certificate contains the subject's "public
key". The public key is associated with a corresponding "private
key" that is kept secret. Only someone in possession of the private
key can use the certificate to identify himself.
In order for someone to use a certificate then, the following steps
are necessary:
- A public/private key pair must be obtained
- The public key is given to an appropriate CA who will generate a
certificate (after first verifying the identity of the requestor)
- The certificate, containing the subject's name, public key, and
signed by the CA, is returned to the requestor.
Administrative Benefits of Strong Authentication
One might expect that something called "strong authentication"
would be very complex to set up and administer. However, the opposite
is the case in many situations. Once the certificate and private key
have been installed, things are (or should be) very easy indeed. For
example, when setting up an X.500 DISP replication agreement between
two directory servers using simple authentication, passwords need to
be assigned for each direction of replication. This is avoided with
strong authentication. This can be seen in the two screenshots below.

Simple Authentication Setup (click for larger image)

Strong Authentication Setup (click for larger image)
When many such peer relationships need to be established, it can be
send that strong authentication gives a significant administrative gain.
Configuring Certificates
As mentioned earlier, using a certificate requires that a public/private
key have been obtained. Isode applications which need a certificate
are able generate their own key pair, and use that to construct a PKCS#10
format Certificate Signing Request (CSR) which contains the information
that a CA requires to generate a certificate.
Because a CSR is in a standard format, it may be submitted to an external
CA or processed by any application which is acting as a local CA. The
next section discusses these options in more detail.
In either case, assuming the CA is willing to do so, it will create
and return a certificate to the application, which can then install
it, along with its private key: it is the combination of certificate
and private key that subsequently allows the application to identify
itself.
For an Isode application then, generating keys and CSRs is handled
with minimal requirement from the user. But interaction with a CA is
necessarily more involved.
Certification Authority Choice
There are a number of options for an Isode customer to use for a CA:
- Use a commercial CA. There are many good products available, from
companies such as RSA, Entrust and Cybertrust. Many Isode customers
will choose to use such products for security and administrative reasons.
PKCS#10 CSRs are a straightforward mechanism to interact with such
products.
- Use a commercial service. This ought to be an option, but to Isode’s
knowledge there are no services that issue the type of certificate
required by Isode products.
- Use an open source CA. There are a few reasonable options, but none
is ideal. Some products, such as OpenCA, are quite complex to install
and operate. Others, such as the tools that come with OpenSSL are
simpler to install, but need some skill to use correctly.
- Use the Isode Mini CA. While
Isode understands that commercial or third-party offerings may be
most suitable in some situations, there are cases where the cost or
complexity of these will not be appropriate:
- In test or evaluation scenarios, where the goal is to evaluate
Isode's strong authentication capabilities. Relying on a third
party product may add too much complexity (and cost).
- For customers running a small number of servers, who wish to
gain the security and administrative benefits of strong authentication
(compared to simple password-based mechanisms) but do not have
very high security requirements or the need to issue large numbers
of certificates.
Why Isode Built Mini CA
In order to help Isode customers adopt strong authentication, we have
built a very easy to use CA. This is our "Mini
CA", and while it does not aim to be a comprehensive tool,
it provides all the necessary functionality to process CSRs and issue
certificates, as well as being able to revoke certificates and generate
Certificate Revocation Lists (CRLs).
For some customers, the Mini CA will meet operational needs; for others
it will be a transitional tool towards using a commercial CA product
or service.
Summary and Conclusions
This paper explains Isode's approach to making strong authentication
easy to set up, and the role of our Mini
CA tool.