Authentication is the name given to the process by which entity A proves his identity to entity B before they conduct some transaction. Authentication can work in two ways: as well as proving your identity to someone, you might want to make sure that they are who they say they are.
In a simple case, authentication may involve a user entering a password when logging in to a computer: assuming the only person who knows the password is the user himself, then the fact that a correct password is supplied can regarded as proof of the user’s identity. A problem with this type of authentication (sometimes called "simple" authentication), is that the user’s proof of identity (i.e. his password) has to be transmitted to the computer, and this raises the possibility that some malicious party may be able to intercept the transmission, make a copy of the password, and later on use it to masquerade as the user.
In the context of an M-Vault Enterprise Directory configuration, authentication may take place when a user (or administrator) accesses data inside the Directory, as well as between two co-operating Directory Servers where data is being replicated from one to the other. Although there may be situations where simple authentication (or none at all) is acceptable, for cases where sensitive or critical data is involved, it may be that something more sophisticated is required.
X.509 strong authentication is one way to deal with this type of problem: each entity obtains an electronic certificate which is constructed in a way that prevents anyone but that entity from being able to present it as proof of identity.
X.509 certificates rely on the use of key pairs. A key pair consists of two distinct values, either of which may be used to encrypt data. Once data has been encrypted with one of the keys, it can subsequently only be decrypted using the other key. For this reason the mechanism is sometimes referred to as asymmetric key cryptography. Once a key pair has been generated, then one of the keys is published (made known to anyone that wants it); the other remains known only to one person. The term Public Key Infrastructure (PKI) is used to describe this type of arrangement.
An X.509 certificate for an entity contains (among other things) the public key for that entity. By presenting its certificate, as well as some data which has been encrypted with its private key, an entity can therefore prove its identity (because no one other than the owner of the private key could have encrypted the data). Provided the certificate owner is a trusted entity, a transaction can proceed safe in the knowledge that no-one is masquerading as that entity.
A natural way of organising mutual authentication would be for everyone to keep a copy of the certificates for all the entities that they trust: when I am presented with a certificate, I just check to see if it’s in my list. However, this doesn’t scale very well: a list of certificates for all legitimate users might be impractically large, as well as being difficult to keep up to date. To make this easier, each X.509 certificate contains the identity of another entity which "issued" the certificate; such an entity is referred to as a Certificate Authority (CA). By issuing (or signing) a certificate, a CA vouches for the entity that owns the certificate. Assuming I trust the CA, then by obtaining the
CA’s certificate I can safely trust any certificate subsequently presented to me which has been signed by the CA.
So an X.509 certificate contains (among other things) the following information:
- the identity of the Certificate Authority (CA) which issued the certificate
- a range of dates outside which the certificate may not be used
- the name of the entity that the certificate belongs to. Such names are represented as
- the entity’s public key
The process for obtaining a key pair and certificate for an entity is first to create a key pair and a Certificate Signing Request (CSR). The CSR includes (among other things) the public key and the name of the entity. The CSR is then submitted to the CA, which will (assuming it is happy to do so) produce a corresponding certificate, whose "issuer" field will contain the identity of the CA.
The certificate issued by the CA for the entity may be given to anyone (the certificate itself contains no confidential information). But it can only be used to perform strong authentication by the entity itself, since using the certificate in this way requires knowledge of the private key. Note that the CA never sees the entity’s private key (it is not contained in the CSR), and so even it cannot subsequently use the certificate in this way.