7.6 CONSEQUENCES OF DIGITAL SIGNATURES FOR DISTRIBUTED OPERATIONS

7.6.1 On the Outgoing Request

The first point to note is that the operation submitted by the DUA is transferred in the clear. Consequently, each DSA that processes the request is able to understand what the user wants to do, without needing to decipher the signature (although it may do so if local security policy requires it). Only when the request finally arrives at the DSA holding the purported name, need authentication take place. Providing that this DSA has the public key of the DUA, it can authenticate the operation successfully. If it does not have the user's public key, there are several ways it can obtain it. Firstly, the user can send it in the request as a certification path (§ 7.7.2), secondly the DSA can read the user's public key (as a certificate - see § 7.7) from her Directory entry, and thirdly the DSA's administrator can enter into a bilateral agreement with the user's administrator for the public key to be made available by private means.

The next point to note is that the original request submitted by the user cannot be altered in any way by any intermediate DSA, otherwise the signature will be invalidated. Now as a DSA processes a request, it is likely to want to alter the request in some way, for example, if an alias is encountered and dereferenced, or as OperationProgress changes from notStarted to proceeding, or simply to add an element to the trace information. Any changes that need to be made therefore must be made to the Chaining Arguments, and not to the operation arguments. (Chaining Arguments are outside of the original request signed by the user.) Consequently, any values in the Chaining Arguments must override corresponding values in the operation arguments, otherwise the operation would not progress satisfactorily. So paradoxically, the final DSA must still trust intermediate DSAs not to have added spurious parameters to the Chaining Arguments. Never-the-less, even if they have, they will not invalidate the authentication of the user, only some of the parameters of the operation which the user wanted to perform.

DSAs can also operate on a point to point strong authentication basis. A chaining DSA can treat the original request and signature, plus the newly added Chaining Arguments, as a single message. This can be digitally signed by the chaining DSA and sent to the recipient DSA. The recipient DSA can validate that the message is authentic i.e. has not been altered and was actually sent by the chaining DSA, by checking the digital signature of the chaining DSA. If the message is authentic, then the signature added by the chaining DSA is discarded. The operation is progressed by the recipient DSA. If further chaining is required, this DSA now acts like the previous chaining DSA. It generates a new digital signature for the original signed request and the new Chaining Arguments.

The final DSA in the chain can check the digital signature of the sending DSA i.e. the penultimate DSA in the chain. It can also validate the original signature of the user. It can thus authenticate the sender of the Chaining Arguments, and the sender of the original request.

7.6.2 On the Incoming Response

In general, the final DSA in the chain generates the result. It may digitally sign the result, so that the user can authenticate the reply. This is not true for update operations and errors, which currently cannot be signed. Update operations generate null results, and errors are often single integers. Producing a digital signature of nothing, or of a single integer, potentially compromises the private key, and may allow it to be computed from knowledge of the public key. Hence the omission of signatures from these replies. Users therefore have to trust that errors and update results are genuine, and have not been tampered with by (other components of) the Directory. (In the worst case a genuine result could be discarded and replaced by an error - see w/w 7.7.)

Fig. 7.7 The merging of (unsigned) Search Results.

Multiple results generated by a set of DSAs in response to a Search or List operation, have their own added complications. Normally, the final DSA that holds the target entry is responsible for merging results that have come from subordinate DSAs, before returning the final result to the user (Fig. 7.7). If a subordinate DSA providing a fraction of the final result, digitally signs its own portion, then the final DSA cannot merge the signed portion with the other portions. This is because any manipulation of a signed portion would invalidate the signature. Consequently, the final DSA can only merge together unsigned portions of the final result (Fig. 7.8). The result that is eventually returned to the user could comprise of several portions, all signed by different DSAs, plus a partially merged result from several other DSAs, signed by the final DSA. Different combinations are also possible. The ASN.1 of List and Search results is therefore complex, and contains Uncorrelated List Results or Uncorrelated Search Results respectively, which is a set of signed List or Search results (§ 5.10.3). Each element in the set will be a portion of the final result, and each will be signed by the DSA that generated that part.

Fig. 7.8 The (non)merging of signed Search Results.

7.7 THE INFORMATION STORED IN THE DIRECTORY TO SUPPORT STRONG AUTHENTICATION

One could be excused for thinking that all the Directory needs to do in order to support strong authentication, is to define how and when a digital signature is produced, and to allow all Directory components (DUAs and DSAs) to store their public deciphering keys in their own Directory entries. DSAs and DUAs can then digitally sign their messages, using their private keys, and send them to other Directory components. The receivers can read the public keys of the senders from the Directory, and authenticate the enciphered messages. Although this is in essence what does take place, there is an added complication.

Most importantly, whoever reads a public key from the Directory, still has to trust that the Directory (or one of its users) has not altered the key in any way. For example, if an unscrupulous administrator of one DSA substituted other people's stored public keys with his own, he could then send a message to a recipient, encrypted with his private key, but saying that the message actually came from someone else (having substituted that person's public key with his own). The duped recipient would read the supposed sender's public key from the Directory, and would wrongly authenticate the message.

Remember, the reason for not using simple password authentication in the distributed Directory, was that one had to trust the (other components of the) Directory. Therefore we cannot simply store public keys in the Directory without protecting them in some way first. This protection must ensure that the public keys are authentic, i.e. that they are the keys of the objects in whose entries they are stored, and that they have not been tampered with in any way. From what we have already learned about digital signatures, it would seem that what needs to be done is to somehow digitally sign public keys before storing them in the Directory. We do not then need to trust the Directory when we read public keys from it. This is in fact what is done.

The protection given to public keys is called certification. This is the process whereby a trusted third party, called a certification authority, validates a user's public key, by digitally signing it. The validated key is called a certified public key, or certificate, for short. A certificate guarantees that a public key is valid, and that it cannot be altered without detection. It is certificates that are stored in the Directory.

7.7.1 Certificates

A certification authority (CA) is an organisation that is external to, and unconnected with, the Directory. Certification authorities might usually be organisations that specialise in offering security services and products. The main attribute of a certification authority is that it is trusted by a group of users to create certificates on their behalf. Quite often certification authorities may also be the organisations that produce key pairs for use with asymmetric encryption algorithms. In this case, the certification authority would produce the key pair. It would give the user his private key, and produce the certificate of the public key ready for storage in the Directory. (The certification authority would also destroy its knowledge of the private key.)

A certificate consists of:

All of this information is digitally signed by the certification authority, using its private key. The identifier of the algorithm(s) and any associated parameters used by the certification authority to sign the certificate, are stored with the certificate; see also w/w 7.6. Consequently, with knowledge of the public key of the certification authority, it is possible to check the validity of the certified public key of the user. Thus if a DSA and a DUA share the same certification authority, they may easily exchange signed requests and responses. Each only needs to send the other its certificate along with the request, since each can validate the other's certified public key by using the public key of their common certification authority. It is assumed that certification authorities always make their own public keys available to their clientele.

7.7.2 Certification Paths

But what happens if a remote DSA does not share the same certification authority as a user or their DSA? In this case, the user's certification authority and the remote DSAs certification authority would need to exchange their own certificates, signed by each other. In other words, the users certification authority certifies the public key of the remote DSA's certification authority, and the remote DSA's certification authority certifies the public key of the user's certification authority. This pair of certificates is called a cross certificate pair, and it is typically held by each certification authority in its Directory entry (Fig. 7.9).

Fig. 7.9 UserCertificate and CrossCertificatePair attributes.

In Fig. 7.9, B is the certification authority of User A, and D is the certification authority of DSA C. All four objects have entries somewhere in the DIT, the exact location is not important. The entries hold, amongst other things, certain certificates, as attributes of their entries. DSA C and User A hold UserCertificate attributes, and certification authorities B and D hold CrossCertificatePair attributes.
Note.The Standard defines the following attribute types:
- UserCertificate for use by a user (of a certification authority), to hold its own certificate; and
- CACertificate and CrossCertificatePair for use by certification authorities, to hold certificates and cross certificate pairs. A CACertificate is signed by one certification authority, and holds the public key of another certification authority. A cross certificate pair holds a pair of certificates, the signatory of one having its public key held in the other.

In order for User A to authenticate a response from the remote DSA C, User A would need to obtain the certificate of the remote DSA, {Certificate C}. However, this certificate is signed by certification authority D, and User A does not have the public key of that authority. User A only has the public key of its own certification authority B. Consequently, User A would also need the certificate of certification authority D. As this has been signed by User A's certification authority, User A is now alright. By using the public key of its own certification authority B, User A can validate the public key of the remote certification authority D. From this User A can validate the public key of the remote DSA C. The chain of certificates, {Certificate D}signed B {Certificate C}signed D is called a certification path. The DAP and DSP allow certification paths to be carried in both requests and results. So messages may have embedded within them all the information that the receiver needs to authenticate them. Thus a remote DSA can send you the certification path from you to it, embedded in its response.

In order to authenticate a request from User A, the remote DSA C would need a certification path from itself to the user. This would comprise: certification authority B's certificate, signed by the DSA C's certification authority D, and User A's certificate, signed by certification authority B. User A's DUA could embed this certification path {Certificate B}signed D {Certificate A}signed B in the outgoing request.

In practice, certification paths can be arbitrarily long. The first certificate in the path will be one signed by the receiver's certification authority. Each certificate in the path contains the public key of the certification authority of the next certificate in the path. The exception to this is the last certificate in the path, which contains the public key of the sender.

Each certificate in the path, excluding the last one, may be a cross certificate pair rather than a single certificate. Cross certificate pairs comprise of certificates for both the forwards and backwards paths. If the sender has cross certificate pairs available to it, then the sender already has most of the reverse certification path from itself to the receiver. The receiver need only return its own certificate (along with the result) in order for the reverse path to be complete. The sender will be able to authenticate the result, using the receiver's certificate and the backwards path from the cross certificate pairs.

The interesting point to note about certification paths is that prior to sending a request, a user or his DUA must know the certification authority of the remote DSA. (Either that, or his administrator has already made other arrangements for some certificates to be exchanged.) Clearly a certain amount of behind the scenes activity has had to take place before the request can be sent. Strongly authenticated requests will not usually arrive at a DSA from unknown DUAs. (With unauthenticated requests, such as those used in the current pilot projects, users do not need to know which DSAs will process their requests, and DSAs can expect to receive requests from unknown DUAs.) Strong authentication requires the user or his administrator to at least know the management domain that the target DSA is in (assuming that all DSAs in one domain use the same certification authority), so that the certification path can be built. Because of this, current research, e.g. Password (Roe, 1992), is looking at ways of hierarchically structuring CAs, so that certification paths can be dynamically built by DSAs without any administrative intervention.

The example in Fig. 7.9 assumed that no DIT relationships existed between users, DSAs and certification authorities. If hierarchical relationships do exist, then certification paths can be shorter. A full description of this is beyond the scope of this book.

Certification paths are also used by X.400, in order to authenticate signed electronic mail messages.

7.8 STRONG AUTHENTICATION PROCEDURES

Most components of a strong authentication procedure have now been presented, but the Standard does detail three different mechanisms for combining it all together.

7.8.1 One-way (Single Entity) Authentication

With this procedure, the initiator inserts authentication information into the outgoing message. This allows the recipient to validate: that the message was intended to be sent to him, that the initiator was the originator of the message, and that the message has not been tampered with or sent before. This is achieved as follows. The initiator inserts the name of the recipient into the message allowing the recipient to verify that he is the intended destination. The initiator also inserts a timestamp (this is the time up to which the signature is valid) and a random number (this number should be unique amongst all unexpired signatures) into the message ensuring that the message cannot be replayed. The initiator may also include his name in the message -this is only needed if the recipient has no other way of identifying the initiator. The initiator then signs the message with his private key to ensure that the message came from him, and that it has not been tampered with. Finally, the initiator attaches to the signed message: the identifier and associated parameters of the algorithms used to generate the signature, and a certification path from the recipient to himself. These allow the recipient to validate the signed message without having to retrieve additional information e.g. public keys, from other sources. Note that the certification path does not need to be inside the signed message, since each certificate in the path is itself signed, and so it cannot be tampered with. (The Directory operations do however include the certification path inside their messages before they are signed, but this is not essential from a security point of view.) Note also that the algorithm identifier and associated parameters do not have to be inside the signed message, since if they are tampered with, the signature cannot be validated correctly.

When a DUA Binds to a DSA using strong authentication, the DUA follows the above procedure, in that it includes as one argument (the strong authentication token) of the Bind operation (Table 5.2): the distinguished name of the DSA, its own distinguished name (at the time of writing this is not actually in the Standard, but an outstanding defect report proposes that it be added), a timestamp and a random number, and the identifier and associated parameters of the hash and signature algorithms used to sign this information (w/w 7.6). It may also send along with this signed information a certification path from the DSA to itself. Remember that the latter need only be the certificate of the DUA, if both the DSA and DUA have the same certification authority.

When a DUA invokes an operation on the Directory, using strong authentication, then it includes SecurityParameters in CommonArguments that contain (Table 5.5): the name of the DSA that it is has bound to, a timestamp and a random number, and optionally a certification path to itself from the DSA that will eventually evaluate the operation. Note that this is not necessarily the DSA that the DUA has bound to, but is the one in which name resolution will be completed. Remember that the DUA does not need to know the actual DSA that will evaluate the operation, but only its certification authority. The DUA also includes its own name in Common Arguments (Table 5.3). Finally the complete set of arguments for the operation is digitally signed.

When a DSA binds to another DSA, using strong authentication, the DSA includes as one (signed) argument of the Bind operation: the distinguished name of the remote DSA, its own distinguished name (subject to the outstanding defect report), a timestamp and a random number, and the identifier of the algorithms used to sign this information. It may also send along with this signed information a certification path from the remote DSA to itself (Table 5.2).

When a DSA chains an operation to another DSA, using strong authentication, then it includes SecurityParameters in ChainingArguments which contain: the name of the DSA that it is Bound to, a timestamp and a random number, and a certification path from that DSA to itself (optional) - see Table 5.5. (The optional argument was already sent previously in the Bind, and so may be omitted.) Finally the complete set of arguments for the chained operation is digitally signed. Remember that the operation embedded in the chained operation may already have been signed by the DUA, so that the original operation and signature are carried to the ultimate DSA without alteration.

7.8.2 Two-way (Mutual) Authentication

Two-way, or mutual, authentication allows the recipient to send authentication information back to the initiator. So, in addition to the guarantees of one-way authentication, this allows the initiator to validate that the intended recipient was the actual recipient. The information sent from the original recipient back to the original initiator is exactly the same as in the case of one-way authentication. The recipient sends the following information back to the initiator: a timestamp (after which its signature will not be valid), a random number (unique to all signatures it generated during the latter time frame), the name of the initiator, and, subject to the outstanding defect report, its own name. This information is then digitally signed by the recipient before transmission. The recipient may also optionally transfer to the initiator a certification path from the initiator to itself. This need only comprise of the certificate of the recipient, if they both share the same certification authority, or if the initiator originally sent cross certificate pairs to the recipient.

Two-way strong authentication may be used in the Directory Bind operation, either between two DSAs or between a DUA and a DSA. The information returned in a Bind result may contain exactly the same components as that sent in the Bind operation (Table 5.2).

Two-way strong authentication may be used for successful read-like and search-like Directory operations, but not for the update operations. Failed Directory operations may not be two-way strongly authenticated, since errors cannot be signed. Successful operations contain SecurityParameters in CommonResults, and the parameters are analogous to those in CommonArguments (Table 5.5). The only difference (and this is the subject of another defect report) is that the DSA generating the result inserts the name of the DUA into SecurityParameters, and not the name of the DSA that chained the request to it. In addition, the DSA generating the result inserts its name into CommonResults, and then digitally signs the complete result (Table 5.6).

A DSA that chains an interrogation result back to another DSA, may add SecurityParameters to ChainingResults, in the same way as ChainingArguments were used on an outgoing request. The entire chained result, comprising the signed result and the ChainingResults, is then digitally signed. ChainingResults and the outer signature will be discarded by the receiving DSA, and generated anew for passing back to the next DSA in the chain. The signed result will pass unaltered back to the DUA.

7.8.3 Three-way Authentication

Three-way authentication is an alternative method of mutual authentication, which doesn't require the transfer of timestamps. The difference between this and two-way authentication, is that only a random number is initially transferred from the initiator to the recipient, instead of a timestamp and a random number. (All other information is the same.) The recipient returns the initiator's random number, as well as its own, in its signed reply. (All other information is the same as in two-way authentication, except that the timestamp is missing.) This allows the initiator to verify that the intended recipient is actually communicating with it, and that replay is not taking place. Finally, the initiator returns just the recipient's random number, which it has digitally signed. This allows the recipient to verify that no one is replaying the initiator's messages.

Three-way authentication, although defined in the authentication framework, is not actually used by the Directory. It has been proposed for future use by Association Control.

7.9 REVOCATION LISTS

Strong authentication seems to provide a reliable, secure mechanism for authenticating users, but it is not infallible. What happens if a private key becomes compromised, so that it is no longer secret? We then have the possibility of a fraudster masquerading as the owner of the private key. In order to combat this, we need a mechanism for withdrawing and replacing a key pair. Clearly a new key pair can be obtained from the key generation authority. The new public key can be signed by the certification authority, and can replace the old certificate in the user's entry. But how can remote parties be notified that a public key has been withdrawn from circulation, and has been replaced by another one? Remote parties may well have kept local copies of the old certificate, and may continue to use them, oblivious of the fact that it is now the fraudster who is communicating with them. Hence the need for revocation lists.

Revocation lists are lists of withdrawn, or revoked, public keys. They are held by the certification authority in its entry. Every time a user asks a certification authority to provide it with a new public key certificate, the old public key may be added to the current revocation list. Actually, it is not the public key that is added to the revocation list, but the serial number of the withdrawn certificate.

However, what stops a revocation list from becoming infinitely long? Remember that certificates have an embedded validity time, and so when the validity time expires, the revoked public key can be removed from the revocation list. The certificate is not valid after this time anyway, and so anyone who has a copy of it would not use it after this time. Therefore key pairs that live their natural life without being compromised, will never need to be added to a revocation list.

Formally, each item in the revocation list comprises of:

Each item is signed by the issuing/revoking certification authority, so that users of the revoked item can be confident of its validity.

The entire revocation list is then timestamped, so that users of the list can easily determine when the list was last updated and new items were added to it. The entire list also contains the name of the certification authority publishing it, and is signed by this certification authority. (It is thus possible for a certification authority to publish the revoked certificates of other certification authorities in its own revocation list. Hence a common black list can be co-operatively published by all certification authorities.)

7.10 USING PUBLIC KEYS

Thus the user of a public key (actually DUA or DSA software) has a lot of hoops to jump through before it can simply use the key to authenticate a received message. It must first read the current revocation list of the certification authority who issued the certified public key. (Alternatively, a friendly certification authority may update the software with its current revocation list, every time it changes; although this has the weakness that if the certification authority cannot contact the application, it may still use a certificate that has just been withdrawn.) The software must validate the revocation list to ensure that it has not been tampered with, then check if the certificate it wants to use appears in the list or not. If it does not, the software must then check the validity of the certificate, that a) its time has not expired, and b) it is not a forgery. Finally the software may authenticate the received message using the validated public key. Quite a processing task. It is not really surprising that, at the time of writing, strong authentication is not yet in common use throughout the world.

WEIRD AND WONDERFUL

7.1 During the 1988 standardisation process, it was suggested that the DSP Chaining Arguments should carry an indication of which type of authentication (i.e. none, simple or strong) was originally carried out by the home DSA on the DAP Bind. This suggestion was turned down by the security experts then present, as they argued that all types of Bind authentication were purely local, and that differentiation between them was not meaningful in a distributed environment because they all required trust of the intermediate DSAs. It might lull people into a false sense of security to have this field present. The '88 version of the standard thus contains no indication about the initial type of authentication carried out on the Bind.
During the work on access controls, whilst preparing the '93 Standard, the usefulness of this indication was again raised by some experts. This time the parameter Authentication Level was added to the Chaining Arguments, with identical semantics to that suggested four years earlier. The only difference this time was that all the original security experts had stopped working on the Directory Standard in 1988.

7.2 The Directory Authentication Framework does not actually need to specify permutability, since for authentication all that is needed is for the sender's private key to do the encrypting, and its public key to do the decrypting. The additional property of confidentiality, whereby the public key is used for encrypting, and the private key is used for decrypting, is needed by X.400. It is used to encrypt symmetric keys for confidential transfer between two parties - see §10.2.6. The Directory Authentication Framework has therefore been made unduly complex by the MHS requirement for confidentiality, which really was outside its original scope.

7.3 The RSA algorithm (Rivest et al., 1978) is public domain in Europe, but copyright in the US. Thus US companies cannot use the RSA algorithm in their Directory products, without paying royalties to RSA Inc. who own the copyright. Whilst European companies can implement RSA without paying royalties to RSA Inc., they would not be able to export their products to the US without paying royalties. Thus all manufacturers are effectively trapped by the US copyright. No wonder the functional standards groups have spent considerable time and effort looking for an alternative to RSA. It is they that have suggested using the ElGamal algorithm. NIST expect to publish a non-permutable digital signature algorithm as a Federal Information Processing Standard (FIPS) in 1994.

7.4 The theory of how digital signatures work is as follows. Layer 7, the application layer, calls the BER in layer 6, and is given back the transfer octets. These transfer octets are then hashed in layer 7, enciphered in layer 7, and then given back to layer 6 for re-application of the BER ready for transfer. This caused a furore in 1987/88, with the purist ISO layer experts objecting strongly to the inclusion of this layer violation in the Directory. Layer 6 could not possibly give transfer octets back to layer 7, they could only be given to layer 5. The furore was so bad, that it nearly caused a split between ISO and CCITT, with ISO wishing to remove the ENCRYPTED MACRO (and hence digital signatures) from their version of the Standard. Fortunately a split was avoided.

7.5 Ironically, the new ASN.1 Distinguished Encoding Rules [4.4] remained incompatible with the 1988 Directory ones, right up until 1992. The Directory group tried hard for them not to be, and was only successful at the eleventh hour!

7.6 There was some confusion at the time of writing the Standard, as to how the identifier and associated parameters of the algorithm(s) used to compute the digital signature, were to be carried to the receiver. The SIGNED MACRO (Fig. 7.6a) automatically includes algorithm identifier and the digital signature along with the data value. But when the macro is applied (Fig. 7.6b) it is not immediately obvious that the algorithm identifier is present in the data values. Consequently one group of writers started to add algorithm identifier inside the data types that they were designating as being signed, with the net result that the identifier and associated parameters are now carried twice in some instances (once inside the signed data, and once outside it). This duplication led to confusion, as other experts thought that the two 'algorithm identifiers' might be for subtly different purposes. Consequently a defect report was raised, with the result that a clause was added to the Standard saying that the embedded algorithm identifier was identical to the one defined by the value notation of the SIGNED MACRO.

7.7 Unsigned errors and null results has long been recognised by the UK as a security loophole. It was one of the first defects to be raised on the '88 Standard. As yet no satisfactory fix has been agreed upon internationally, since some countries maintain that this is an enhancement to the Standard, and not a defect. Consequently a new ISO work item was raised in 1993, which will hopefully provide a solution to this problem by 1995.

7.8 It is not possible, using the basic '88 Standard, to authenticate callers who use protected passwords, and who are not in a DSA's local list or set of DIT entries. This is because the Compare operation cannot normally be used to pass the protected password to the actual DSA holding the caller's entry. The UserPassword attribute, as defined in the '88 Standard, only consists of an octet string. It cannot be used as a purported protected password in the Compare operation, since there is nowhere to put the identifier and associated parameters of the one-way algorithm(s), nor the timestamp(s) and random number(s). However, a recent defect report proposed the removal of this restriction. It worked as follows. The UserPassword attribute syntax was re-defined to be a choice between a clear password (still an octet string up to 128 octets), or a protected password. Only the clear password alternative could be used when storing and retrieving a password in to and out from an entry, but either option could be used in the Compare operation. The protected password alternative consisted of: the encoded password, the timestamps and random numbers (if any) used in the encoding, and the identifier and associated parameters of the one-way function(s) used to perform the encoding. Given this enhancement to the Standard definition of the UserPassword attribute, it would have been possible to use protected passwords for authenticating users in a much larger domain than a single DSA. If a DSA received a Bind operation containing a protected password, and it did not hold the password locally, it could chain a Compare operation, using the new protected password syntax, to other DSAs for validation.
Unfortunately the defect report was rejected, because the proposal was judged to be more of an enhancement than a defect. Never-the-less, the defect could still be adopted by any group of users who like it. The group can define their own Optionally Protected Password attribute type, having the same semantics and syntax as the one defined in the defect report. The only difference will be that the group will have to allocate their own object identifier to the attribute type definition, and this will be different to the object identifier that would have been allocated by the Standard, had the defect been accepted.