Authentication

The standard differentiates between simple and strong authentication which may be used depending on how critical the sections of the directory being accessed are, or the type of operations being requested.

Simple Authentication

Passwords
The standard method of simple authentication is for users requesting a connection to supply a password which is sent off with the users Distinguished Name for validation. The standard objects - Organisation, Organisation Unit, Organisational Person and Residantial Person all contain password attributes and other objects may be extended to include a password attribute.

When a DSA is sent a (Distinguished Name,PassWd) pair for validation it can look up the entry in the DIT for the entity requesting a connection, read the password (obviously not a generally readable attribute) and compare it to the PassWd which comes with the request. This is known as a Bind operation. In fact for the users which most commonly access a particular DUA or DSA there will generally be a cached list of (Distinguished Name,PassWd) pairs which can be looked up without the need for the DUA or the DSA to trudge off through the DIT looking for the entity and its password.

The obvious problem with the above scheme is that when users send off their (Distinguished Name,Encoded(PassWd)) pair they are effectively releasing a copy of their password onto the network where an imposter could conceivably intercept it.

Encrypting Passwords
To avoid this passwords are generally passed through a one way function before transmission so that they cannot be read by an imposter. When the (Distinguished Name,PassWd) pair is received at the far end the authenticating party puts the password that it has stored for this user through the same one way function and if the two passwords match the user is granted access.

Unfortuantely this still does not safeguard the directory from replay attack. An imposter could take a copy of your (Distinguished Name,Encoded(PassWd)) pair and simply send it off later to gain access. He does not need to know your password if he can supply the encoded version of it to the authenticating party.

Protection Against Replay
To provide protection against replay we must include a timestamp with the pair and pass it into the one-way function. Thus if this message is replayed later in an attempt to gain access then the authenticating party will disallow it because it sees that the timestamp is out of date (a message with this timestamp has been received already).

We are now moving towards a mechanism which makes it difficult for imposters to pose as legitimate users but we have still left ourselves open to at least one form of attack. What if an imposter sets itself up as a node on the network and intercepts your timestamped pair, preventing it from getting to the authenticating party. The imposter then has a valid timestamped token which it can use to have one shot at compromising the directory.


Still Not Done?
You may be beginning to realise how difficult it can be to secure something which is by its very nature distributed over a network. This is why the standard goes on to specify 'Strong Authentication'. The methods outlined above may be considered sufficiently strong for many applications - many facilities which currently exist on the network rely on similiar ideas.

However organisations which store personal information about people would have to be convinced that their obligations under data protection laws were being completely covered before they could consider putting such information into the directory.

Strong Authentication

Strong security is specified for the directory to provide more secure methods of passing passwords around the network and more particularly to provide a means of signing any information transfer within the directory to prove it came from an approved source.

Symmetric Encryption - DES
The obvious way of ensuring that information passed around a network is secure is to employ some kind of symmetrical encryption algorithm. This means that the two parties wishing to communicate have an aggreed key which they keep secret. The sender encrypts the message and the receiver decrypts the message using the same key. There is a very secure algorithm available to do this - DES which is recommended by the National Security Agency.

However this relies on the two parties having the same key to start off with. While it is just conceivable that the all the DSA's which need to communicate with each other could arrange to have common keys delivered to them, it is out of the question to condsider this scheme for all the DUA's and DSA's which might need to communicate. It would be just the kind of administrative nightmare which the directory is designed to avoid.

Unsymmetric Encryption - RSA
Far more suitable for the purposes of the directory are unsymmetric encryption algorithms. These allow messages to be encrypted with one key and decrypted with another key. The encrypting key cannot be worked out from the decrypting key. These type of algorithms are difficult to design but the Rivest, Shamir and Abelson algorithm is one which fulfils these properties and has been around for a while.

Using the RSA algorithm we can sign a message with a digital signature in the following way. The RSA algorithm carries with it a heavy computational workload to enccrypt or decrypt a piece of data, so generally we pass the data through a hashing function before encrypting it with our private key (E). Then we transmit the data in the clear along with the digital signature we obtained after encryption.

The receiving station takes the data, passes it through the same hashing function and compares this against the digital siganture which it has decrypted with the public key (D) of the sending station. If the two are the same then the receiving station can be sure of two things about the message

With this digital siganture a user can prove his authenticity when he logs on to the directory as he would with a password and also sign any piece of data he wishes to pass to the directory.

Of course not only do users have to authenticate themselves to DUA's and DSA`s but DSA's have to do the same with other DSA`s. They too can use this method of authentication. Other applications can use the directory to authenticate their own users. First the application links to the directory with its password and then it sends the password supplied by a prospective user along with the user's distinguished name for verification. This saves the application from having to keep its own set of user-password bindings.


Click here for further examples of applications using the directory

Further Issues

While this may seem to give us all that we need for a secure system there are two other issues which still need to be addressed before we can leave the subject of authentication

To ensure the authenticity of a message from another station all we need have is its public key. In fact we can also use this key to encrypt messages which only the owner of the private key can read. The obvious place to go for the public key of a party we wish to communicate with is the directory. The only problem is that a bogus DSA could supply you with its own public key rather than the public key of the party you wish to tell your treasured secrets to. You would then put your message out on the net and it would be readable by the bogus DSA rather then the person you intended to read it.

Whats needed is a way for legitimate DSA's to sign the public keys they send to you. This requires some trusted agency called a Certification Authority to give the DSA a private key and to make the corresponding public key generally available. Possible candidates for this role would be banks or government agencies. The DSA can then sign any keys it supplies and distribute them securely across the network.

The other problem is of a commercial rather then a theroetical nature. The RSA algorithm is patented in the USA and all users have to pay a royalty to a company in California. This will make implementors of the X.500 standard unhappy about using it in their software. The standards people are currently investigating the possibilty of finding another unsymmetric encryption algorithm to make available to the implementors. Because of this problem and also the complexity of the issues invloved most implementations so far do not deal adequately with strong authentication issues.