Advanced Protocol Features of XKMS 2.0

In XKMS 1.1, all operations consisted of a single request message followed by a single response. XKMS 2.0 specifies additional protocol options that allow a client to make multiple XKMS requests simultaneously, allow an XKMS service to queue XKMS requests for later processing, and make it possible to defend against denial of service attacks.

Note

XKMS was one of the first Web Services to be designed. It is likely that some, possibly all, of the “advanced features” of the XKMS protocol will eventually find their way into the SOAP specification itself or one of the associated security specifications at a future date.

Compound Requests

A compound request allows a client to make multiple XKMS requests in a single request message. This allows for faster processing than would be possible if the client had to make each request individually, waiting for the result to be returned before making the next request.

Compound requests were only supported in XKMS 1.0 for the register operation and only as a separate specification called X-Bulk, which was intended to support issuing of public key pairs and certificates to smartcards and other embedded devices.

During the design of XKMS 2.0, it was argued that the ability to make multiple requests at the same time is useful in many other cases. In particular, an e-mail client sending an encrypted message to 25 recipients is likely to be unacceptably slow if the public key of every recipient has to be retrieved individually. Compound requests were introduced to fill this need.

Asynchronous Processing

In some situations, an XKMS service may not be able to respond to a request immediately.

Asynchronous processing may be required because some form of operator inter- vention is required to complete an operation. For example, a registration procedure might require some form of offline authentication procedure to be completed before a credential is issued. Manual intervention is frequently required in key recovery operations; in some cases, a key recovery procedure may require authorization by more than one administrator.

Asynchronous processing is also desirable in cases where the request may take a long time to complete. For example, a manufacturer of smartcards might make a compound request to register 10,000 service-generated public key pairs at a time. Generating such a large number of keys is likely to take a significant amount of time. If the client has to wait for the service to complete processing the request before a result of any kind is returned, it might be waiting 20 minutes or more—the client has no way to know if the service is simply slow or has failed. Such long delays are likely to result in unreliable behavior due to dropped connections, timeouts, and other network issues that cause unexpected behaviors.

Asynchronous processing involves two separate request/response pairs (see the illustration). The client makes the first request specifying the ResponseMechanism type xkms:Asynchronous. The service may return the actual response immediately or signal that the response will be returned asynchronously using the ResultMajor code xkms:Pending. Once the service has completed processing the request, the client obtains the result by issuing a pending request message.

The means by which the client determines that the service has completed processing the request is outside the scope of the XKMS specification. A client may suggest a notification mechanism to the service in the original request, which the service may choose to support or ignore. Alternatively, the client may poll the service to determine whether processing has completed.

Two-Phase Request Protocol

A successful denial of service attack against an XKMS service may result in the services that rely upon it becoming unavailable. It is important, therefore, that an XKMS service is able to protect itself against a denial of service attack by refusing spurious requests.

Rejecting spurious requests is difficult, however, because an attacker may forge the source address of the IP packets containing the request. If the XKMS service simply refused service after an unacceptable number of spurious requests, the denial of service measures intended to protect the service would instead make it easier for the attacker to deny service to users. Moreover, the attacker could choose to deny service to individual users of the XKMS service without causing a complete loss of service likely to attract wider attention.

The two-phase protocol provides protection against denial of service attacks by checking that the requestor can read IP packets sent to the purported source of the request.

The client sends an initial request to the service. Unless the service has reason to believe that the request is part of a denial of service attack, the service may respond with an immediate result.

If, however, the service has determined that it is under a denial of service attack and the request may be a part of that attack, it returns a response with the ResultMajor code xkms:Represent that contains a nonce value. The term “nonce” is used in the description of cryptographic protocols to refer to an apparently random value that is hard for another party to guess. In order for the service to act on the request, the client must represent the request together with the previously issued nonce value (see the illustration). The ability to present the nonce demonstrates that the request comes from a source that can read messages sent to the purported source IP address, thus providing a very high degree of confidence that the purported source address is genuine. The service may therefore distinguish between requests that actually originate from that address and packets forged to appear to originate from that address.