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.