Two Protocols

Secure RPC

Here Anna is trying to authenticate herself to the server Server. She is logging into the client Client. Client and Server 
communicate. The protocol as implemented by Sun Microsystems and other vendors uses Diffie-Hellman for the key 
exchange, but this protocol would actually work with any symmetric key exchange protocol.

1.	Client sends Anna's name to Server.

2.	Server sends the Server's public key, Anna's public key, and Anna's private key enciphered under the DES with 
her password as the key to the Client.

3.	Client obtains Anna's password and deciphers Anna's private key using that password.

4.	Client computes the conversation key (the protocol's term for an interchange key) using Anna's private key and 
Server's public key.

5.	Server computes the same conversation key using Server's private key and Anna's public key.

6.	Client generates a 56-bit random session key, appends a Validator in fixed form, enciphers the result using the 
conversation key, and sends it to Server.

7.	Server uses its computed conversation key to decipher message.

8.	Server checks Validator for presence of specific information (bits in specific places, etc.) If the Validator is cor-
rect, Server believes Anna has correctly authenticated herself, and both parties use the session key for further 
messages. If the Validator is incorrect, Server believes Anna has not correctly authenticated herself, and rejects 
the attempt.

Kerberos

Kerberos is an authentication protocol requiring one or more trusted authentication servers. The authentication server 
stores the user's password. In what follows, Tn,x is a ticket identifying the user n to the service x, An is an authenticator 
identifying the user n, Kn,x is a session key that n and x can use to communicate, and Kx is a cryptographic key (pass-
word) that user or service x and the authentication server share. The ticket  Tn,x  contains the session key Kn,x. The 
notation {x}y means the message x enciphered with cryptographic key y (using the DES).

Logging in

1.	Client sends user name and request for a ticket to use the ticket granting service to the authentication server.

2.	Authentication server responds with {{Tuser,tgs}Ktgs,Kuser,tgs,-}Kuser.

3.	Client uses locally entered user password Kuser to decipher message and obtain {Tuser,tgs}Ktgs and Kuser,tgs. If the 
password is incorrect, none of the messages between the authentication server and the user will decipher cor-
rectly, nullifying the use of any services.

Obtaining a Ticket for a Service

1.	Client sends message: service,{Tuser,tgs}Ktgs,{Auser}Kuser,tgs to the ticket granting service tgs.

2.	The ticket granting service uses its key Ktgs to obtain the ticket Tuser,tgsand, from that, the session key Kuser,tgs. It 
uses the session key to obtain the authenticator Auser. It then verifies that the ticket was issued to the entity named 
in the authenticator.

3.	The ticket granting service replies to the client with the message  {{Tuser,service}Kservice,Kuser,service}Kuser,tgs.

4.	The client uses the session key Kuser,tgs to obtain the session key Kuser,service to use with the desired service, and 
an enciphered message {Tuser,service}Kservice to send the service.

Using a Service

1.	Client sends message: {Auser}Kuser,service,{Tuser,service}Kservice to the server.

2.	The service uses its key Kservice to obtain the ticket Tuser,service and, from that, the session key Kuser,service. It uses 
the session key to obtain the authenticator Auser. It then verifies that the ticket was issued to the entity named in 
the authenticator.

3.	The server obtains the timestamp t from Tuser,service and replies with {t + 1}Kuser,service.