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.
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.
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.
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 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.
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
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
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
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.