Local Login - When a user performs a local login he usually also receives a ticket that will permit him to be authenticated to the services offered. The user, while logging in locally, is requesting a ticket-granting-ticket from the key-distribution-center (KDC) to use when requesting services from a particular server. This ticket-granting-ticket is presented to the ticket-granting-server (TGS) and the TGS issues a server-specific ticket. The server-specific ticket is then presented by the user for authentication to the server.
In version 4, message 4 is: KDC 
C:
.
The change results from a performance issue of the ticket
being doubly encrypted (once in step 3 and again in step 4)
when being sent from the KDC to the
client. This forces the client to have to decrypt the ticket
before presenting it to the server. There is no need to
encrypt the ticket in the message from the KDC to the client,
and doing so can be wasteful of processing time if encryption is
computationally intensive (as will be the case for most software
implementations. [Koh91,p4].
Not having to perform this
``extra'' encryption that results in more ciphertext alleviates
some degradation of performance, without increasing risk
significantly.
The client now possesses a session key for use between the client and the ticket-granting-service, along with a ticket-granting-ticket to present to the ticket-granting-service. For any further service requests, the client communicates with the ticket-granting-service, rather than the key-distribution-center. Also of note is that the user password is not needed for any further authentication. The ticket-granting-ticket in conjunction with the session key between the client and the ticket-granting-server are used for authenticating the client, who is acting on behalf of the user.
Remote Login and Client/Server Requests - These two types of accesses are treated the same. The user presents credentials and an authenticator to the ticket-granting-service requesting a ticket for a particular service. This may be for example, the telnet service, use of an ``r-command'' (rlogin, rsh, etc.).
The client makes a request to the ticket-granting-server by sending the ticket-granting-ticket, an authenticator encrypted under the session key shared between the client and the ticket-granting-server, and the server/service request. After verifying the authentication of the client, the ticket-granting-server sends to the client a session key to be shared between the client and requested server that will be used to encrypt the authenticator, and a ticket (encrypted under the server's secret key) that is required to be presented to the server. The client can now use these for the life of the ticket (or login session) to authenticate the user when server/service requests are made.