Kerberos: Authentication in Windows

Kerberos (v5) is a Network Authentication Service used by Microsoft Windows Server since 2000 that provides Single Sign On (SSO) where the user only enters their password once to access the network of servers.

The name is taken from the three headed dog in Greek mythology, due to its three pronged nature of Client, Authentication server (KDC) and Resource Server.

Kerberos assumes and protects against an open network in which packets can be sniffed and altered.

The full specification can be found here: http://tools.ietf.org/html/rfc4120

Benefits

• Mutual authentication
• Faster connections between client and servers, thanks to SSO (through the use of session tickets)
• Delegation aka Impersonation

Stages

There are three stages to Kerberos in Windows, each with their own request/response message:

• Authentication Service (AS) exchange
• Ticket Granting Service (TGS) exchange
• Client/Server (CS) exchange (messages are known as AP: Application Privilege)

Authentication Service (AS) exchange

1. The user providing a username and password.

2. The password is one way hashed and stored locally as the secret key.

3. KRB_AS_REQ message sent from client to KDC Server, consisting of:

• Username (Client Principal Name / User Principal Name).
• Timestamp (for pre-authentication, it's use can be disabled for a user on the AD server).  Its use prevents Replay attacks.  Client clock is sync’d with server, with the allowance of 5 min skew.
• Kerberos target principle name (realm, a Kerberos grouping that uses the same key [the users password]).
• Requested life time.
• Nonce, a random message number to prevent replay attacks.

4. KRB_AS_REP message sent back from server to client, consisting of:

• Part one: Encrypted with the users password containing:

1. User-TGS key (generated by the KDC).
2. Kerberos target principle name (realm).
3. Ticket lifetime.

• Part Two: The TGT, encrypted using a TGS key generated by the KDC so that only the server can open it (even though it is stored by the client for use during further transactions), containing:

1. User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
2. Client principal name.
3. Ticket lifetime.
4. KDC timestamp.
5. Client IP address (taken from the initial KRB_AS_REQ).

Part one of the message can only be used if successfully decrypted by the client using their password.

Ticket Granting Service (TGS) exchange

1. The service ticket request (KRB_TGS_REQ) from client to server containing:

• Service principal name.
• Requested lifetime.
• TGT, still encrypted with the TGS key.
• Authenticator, encrypted with the user-TGS key and containing a client timestamp, guaranteeing that the request originated from the client.

2. The KRB_TGS_REP service ticket reply is again in two parts:

• Part one is encrypted with the user-TGS key (taken from the TGT by the KDC) and contains:
  1. Service principal name.
  2. Ticket lifetime.
  3. User service key (encrypted with a user-TGS session key, generated by the KDC).
• Part two is the Service Ticket (ST), encrypted using the service-TGS key and contains:
  1. User service key (encrypted with a user-TGS session key, generated by the KDC).
  2. Client principal name.
  3. Ticket lifetime.
  4. KDC timestamp.
  5. Client IP address.

Client/Server (CS) exchange

(messages are known as AP: Application Privilege)

1. When the client requires access to the service, the AP exchange KRB_AP_REQ contains:

• The service ticket (ST), still encrypted using the service-TGS key
• An authenticator (encrypted with the user-service key). 

Conclusion

So that's how Kerberos works.  The key points to remember are that:

• AS exchange occurs at logon, providing the client with a TGT.
• The TGT allows the client to enter a TGS exchange (which authenticates the client), returning an ST.
• The ST identifies the authenticated client to a service following which the service will provide access (but only if the client passes the service's own authorisation criteria).
• Messages are encrypted so only the KDC can read the TGT & only the service can read the ST.