Stay Informed

Sign up to whitepaper announcements here.

From the Isode blog...

Subscribe to RSS headline updates from:
Powered by FeedBurner

 

Creative Commons

Creative Commons License
Isode's whitepapers are licenced under a Creative Commons Licence.

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:

  1. A public/private key pair must be obtained
  2. The public key is given to an appropriate CA who will generate a certificate (after first verifying the identity of the requestor)
  3. 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
Simple Authentication Setup (click for larger image)

Strong Authentication Setup
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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

 

Copyright © 2008 Isode privacy   feedback Subscribe to our rss newsfeed