Strong authentication based on X.509 PKI (Public Key Infrastructure) is available in a number of protocols and provides both security & administrative benefits and drawbacks. This paper looks at the security and administrative benefits (and draw backs) of using strong authentication as well as the generic issues that apply to many applications and protocols using strong authentication. Future white papers will look at specific applications of strong authentication.
This paper shows that, in many situations, there are significant security and administrative benefits to using strong authentication. These benefits are behind Isode’s drive to add strong authentication capabilities to many parts of the Isode product set.
PKI and Strong Authentication
X.509 is a mechanism for supporting large scale deployment of security, based on asymmetric cryptography. PKI (Public Key Infrastructure) is needed to support X.509 (and is defined as a part of X.509). An introduction to PKI and X.509 is given in the Isode Whitepaper [A Short Tutorial on Distributed PKI].
Strong authentication is a very simple use of X.509 and is used to provide verification in a protocol between two applications. The core of X.509 is the definition of certificates and PKI. X.509 defines a model for strong authentication. The X.509 model for strong authentication has two important features:
- It uses a minimum number of protocol exchanges, which is important for high performance applications.
- It does not rely on data confidentially, which gives a significant performance advantage for applications that require authentication, but do not require data confidentiality.
These features add some complexity to the application to check for replay attacks and in some cases requires (roughly) synchronized clocks. X.509 defines
- One Way Authentication: A single protocol exchange to authenticate one party to another.
- Two Way Authentication: A double protocol exchange, which enables both parties to authenticate each other.
- Three way Authentication: This gives the same service as two way authentication, but uses an extra protocol exchange, and as a consequence does not require the two end points to have synchronized clocks.
X.400 and X.500 use the X.509 authentication framework directly:
- Peer to peer server applications, such as X.500 DISP replication, will generally use two way authentication.
- Client applications such as X.400 P7 or X.500 DAP may use two way authentication. In some situations one way authentication is also used, which may be when the client does not wish to authenticate the server, and when a client not using strong authentication wishes to strongly authenticate the server.
Internet applications use X.509 in the context of the Internet Standard Transport Layer Security (TLS), which has X.509 based authentication as an option. TLS uses X.509 Certificates, but does not use the X.509 authentication framework. It uses a simpler approach, which relies on the data confidentiality offered by TLS and on using additional protocol handshakes. This means that the performance of Internet strong authentication will be lower than X.400/X.500, but the implementation will be simpler. The quality of authentication service is similar. TLS describes two authentication services:
- Server Authentication: Where the identity off a server is authenticated by a client. This is the security service used by Web (Secure HTTP) to authenticate a Web site to a Web browser.
- Client Authentication: Where a client application is authenticated by a server (e.g., For an LDAP server to verify the identity of a client). Client authentication is generally used in conjunction with server authentication.
This paper uses the term "strong authentication" to mean X.509 based strong authentication, including both X.400/X.500 strong
Protocols that support Strong Authentication
There are a number of standard protocols that support strong authentication. Strong authentication was initially developed for X.400 and X.500, and all of the peer protocols support strong authentication. In particular:
- X.500 DAP, DSP and DISP.
- X.400 P1, P3 and P7.
Internet strong authentication support is in context of TLS. Some Internet protocols such as HTTP (Web Access) make direct use of this capability. The messaging and directory protocols of particular interest to Isode make use of this authentication in conjunction with SASL (Simple Authentication and Security Layer) using the SASL-EXTERNAL mechanism. In particular:
- SMTP, LMTP, POP and IMAP.
When to Use Strong Authentication
All of the protocols listed above make use of strong authentication. The choice of when to use strong authentication is determined by the application. Isode’s approach is:
- For client APIs supporting strong authentication, the choice to use strong authentication is made by the user of the API.
- For Isode management tools supporting strong authentication, the user is given the choice.
- For M-Switch X.400, the options to select authentication mechanisms defined in RFC 1801 (X.400-MHS use of the X.500 Directory to support X.400-MHS Routing) are supported by Directory Based Configuration of the Isode Messaging Servers.
- For M-Vault, configuration of requirements on client and peer authentication
can be configured using Isode's M-Vault Console GUI.
Basic Security Benefits
There are a number of inherent security benefits that arise from use of strong authentication and asymmetric cryptography:
- Key distribution is avoided. Because there is only one private key, it is straightforward to give this to the one entity that needs to hold it, or have the entity generate the private key. Getting the same secret key to both parties generally poses both security and administrative problems.
- Key strength is controlled by administrative decision. This avoids the security problems that arise from common situations where poor secret keys are chosen.
- Protocols that transmit passwords in the clear and the associated security risks are avoided. This includes simple authentication for the X.400 and X.500 protocols, and login/plain choices for LDAP, POP and IMAP.
- For client/server protocols such as LDAP, strong authentication avoids the trade-off between protocol choices that transmit plain passwords and allow a hash to be stored on the server for verification versus protocols that avoid transmitting the plain password, but require the password to be held in the clear on the server.
Storing the Private Key
Strong authentication requires that the party being authenticated hold a copy of the private key. This leads to a number of administrative and security issues, that are described here.
Private Key Storage Mechanisms
Private keys are very large, and it is impractical for a user to remember this information. There are two basic approaches to storing private key information.
- Put the private key information into a file. This may be encrypted with a PIN that is short enough to be remembered by the user. A PIN is usually used for clients. For servers, a PIN is less likely to be used, as the PIN will be required in order to start the server. This is often acceptable, as servers are generally operated in secure environments and the data held on the server is as critical as or more critical than the private key.
- Store the private key on special hardware. For a client, this is typically a smart card which can be inserted into the machine. For a server, it may be a smart card or a special purpose hardware device designed to hold keys.
Benefits of Private Key Storage
There are a number of benefits to storing the private key in a file or on hardware:
- For a client, use of smart card can be a very convenient way to handle authentication.
- By requiring possession of a smart card, or that the user operate from a machine with the private key installed, a two factor authentication mechanism is provided (where a PIN is used) that increases overall security.
Problems with Private Key Storage
There are two basic problems that arise with using private keys. The first is the mobile user that needs to authenticate from many locations. Where all of the locations do not have smart card readers, a smart card approach cannot be used. It is impractical to install a user’s private key in a large number of locations, and this may give security risks. It will often not make sense for a mobile user to use strong authentication. Where high security is needed, it may be inappropriate to support mobile users.
The second problem relates to the procedures for installing private keys on widely used desktop platforms. While it is not particularly difficult to do, the process is sufficiently complex and error prone, that experience with services such as Internet banking suggest that managing private keys for a large number of unskilled users has a high support cost. This must be considered when choosing to use strong authentication.
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 private key is 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 to show/hide)
Strong Authentication Setup (click to show/hide)
When many such peer relationships need to be established, it can be seen that strong authentication gives a significant productivity gain. Once the private key is set up for a server, adding in authentication for peer agreements becomes point and click, with no requirement to assign passwords.
To make the total experience easy, the important problem to solve is making the private key easy to install.
Summary and Conclusions
There are some significant generic security and administrative benefits to using strong authentication. These generic benefits need to be considered in the context of the application being deployed, and the details of the deployment configuration.