The present invention relates to the field of communication systems and more specifically to a system for automatically recovering from service key changes.
Third party authentication is used for validating an entity's identity in a communication network. As an example, if a client wishes to access an application server, a third party authentication service can validate the client's identity to determine whether the client is authorized to access the application server. Validation is possible because both the client and the server initially pre-register with the third party authentication service. Upon registration, the third party authentication service issues a secret key to the client and another secret key to the application server. These keys are saved by the authentication service and later employed for identity validation.
An example of a conventional third party authentication protocol is Kerberos. In Kerberos, a ticket is issued to a client by the KDC (Key Distribution Center) and is used to provide a client with access to an application server. The ticket contains the client's name, network address, the application server's name, a timestamp, and a secret session key. Before the ticket is delivered to the client, the ticket is encrypted with the application server's service key (shared between the KDC and the application server). The client is also provided with a copy of the session key that is encrypted with the client's key (shared between Kerberos and the client). The client creates an authenticator and encrypts it with the session key. The client then presents the encrypted ticket along with the authenticator to the application server.
The authenticator is an additional credential for further validating the client's identity. The authenticator contains the client's name, a timestamp, and other information. Note that this authenticator is encrypted with a copy of the same session key provided in the ticket. The KDC provides this copy separately from the ticket because the client cannot decrypt the ticket.
After the ticket and the authenticator are received, the application server uses its service key to decrypt the ticket, and to retrieve the clear information including the session key. This session key is used to decrypt the authenticator, and to retrieve the clear information from the authenticator. Next, the application server compares the information in the authenticator with the information in the ticket, the client's network address with the address the request was sent from, and the timestamp with the current time. If the information matches, then access to the application server is provided to the client.
Problems, such as disruption of service, can occur when an application server service key that has been compromised is changed. If the client is unaware of the change in service key, the client will continue to use the stale ticket, thus resulting in loss of service.
The application server may respond in several ways to the client's continuing use of a stale ticket. One way is to remain silent and to refrain from acknowledging the access request. This technique results in a temporary disruption of service. The client, unaware of the service key change, continuously uses the stale ticket to request access to the application server. After a number of unsuccessful attempts, the client requests a new ticket from the Kerberos KDC (key distribution center). A new ticket encrypted with a new service key is issued to the client. The client employs the new ticket to request service from the application server and service is thus continued.
Another way the application server denies service is by sending an error message to the client. The error message indicates that the service key has been compromised. The client can respond in a number of ways. First, it may ignore the message, and continue to request access to the application server. This is a typical client reaction because, in existing systems, error messages are not authenticated and may have been sent by a third party interested in disrupting service. Thus, the client continues to request access until its ticket expires.
Another way for the client to respond is to request a new ticket from the KDC. The client can use this new ticket to request application server access. A problem with a client requesting a new ticket in response to an error message is that an inauthentic error message may be received by the client from a third party interested in disrupting service. The third party could duplicate a first error message and replay to send a second error message. If the client returns to the KDC for a new ticket, receives the ticket and presents the new ticket to the application server, again, an inauthentic error message can be sent. This cycle can be continued and the KDC may be kept too busy to respond to legitimate ticket requests from other clients.
The KDC may notice the multiple requests from the same client to access the same application server before a current ticket expires. Accordingly, the KDC may deny all further ticket requests. Since this action denies further service to the affected client, a third party has disabled a client without any cryptographic key knowledge.