Third Party Authentication in the Institutional File System

One-line summary: Indirect authentication using Kerberos, but with the twist that the client is used as a service by the "proxy" device.

Overview/Main Points

• The paper is definitely related work. It describes a proxy-like mechanism for acquiring access to Kerberized services via a proxy on behalf of a client, just like Charon. Their approach is almost the opposite of ours (which is good for us).
• In their system, the proxy (they call it a "translator") acts as a principle, and the client as a service. The proxy gets a ticket for the "client service" using the usual Kerberos mechanism. It also acquires the TGT for the client (but cannot decrypt it since it doesn't have the client's secret key).
• The proxy passes the "client service" ticket to the client, so now it and the client share a session key Kc,proxy. The proxy then passes the client's TGT to the client, the client decrypts it, and sends back the decrypted TGT and the key Kc,tgt to the proxy using the session key Kc,proxy. The proxy can now independently access services on the client's behalf, since it has the client's TGT and the client's TGS session key. (!!)
• Strengths of their system:
  • clients' interaction with the system is minimal
  • services and Kerberos infrastructure remain unmodified
  • clients' secret keys are never revealed

Relevance

Flaws

• clients' require a large part of the full-blown kerberos implementation (decrypting tickets, extracting ticket components, verifying authenticators, ...)
• proxies, if subverted, can request further services on behalf of the clients' without the clients' permission, since clients' have no control over proxies once they reveal their TGT/TGS credentials.