RPC Authentication: Per-Request Authentication

In RPC authentication, each client request that server services receives requires authentication to ensure continuous secure and authorized access. While an authentication server (AS) initially issues credentials like service tickets, the server providing the RPC service validates these credentials with every incoming request, rather than the AS directly authenticating each subsequent call.

This per-request validation is critical for several security reasons:

• Ongoing Authorization: It ensures the client maintains the necessary permissions for the specific operation requested at that moment. User privileges can change, so validating each request prevents unauthorized actions if access is revoked mid-session.
• Protection Against Replay Attacks: By incorporating unique or time-sensitive elements, such as timestamps or nonces, within an authenticator sent with each request, the server can detect and reject replayed requests. For example, in Kerberos, a client sends an authenticator encrypted with a session key. The service server verifies the authenticator's timestamp to prevent replays, as detailed in Joseph Migga Kizza's Guide to Computer Network Security, Chapter 11.2.3.1.
• Session Integrity and Non-repudiation: Authenticating each request verifies its origin from the legitimate client and confirms it has not been tampered with during transmission. This maintains communication integrity and supports non-repudiation, making it difficult for a client to deny having sent a request.
• Mitigating Credential Compromise: Should a client's session token or key become compromised after initial authentication, per-request validation using fresh or unique authenticators limits the attacker's ability to impersonate the client over an extended period.

For instance, in a Kerberos system, after a client obtains a service ticket from the Key Distribution Center (KDC, comprising the Authentication Server and Ticket Granting Server), it presents this ticket along with a unique authenticator for each subsequent RPC call to the service server. The service server then validates this combined package for every request, confirming identity and preventing replays, without needing to contact the KDC for each individual RPC call. The fundamental trust for this validation originates from the KDC.