markwilson.it

Authentication and authorisation are often thought of as a single process but the two are actually distinct operations that may even use separate storage locations for the authentication and authorisation data.

Authentication is about verifying identity, based on one or more factors, for example something that someone knows (e.g. a password), something that someone holds (e.g. a smart card), something that someone is (e.g. biometric information). Obviously the use of multiple-factor identification increases security.

Authorisation is about controlling access to a resource based on access control lists and other policies; however secure authorisation is dependant on authentication in order to ensure that the security principle requesting access is who they say they are.

Kerberos is the industry standard for authentication (not authorisation), featuring mutual authentication (cf. NTLM, which uses one-way authentication), faster connection times (session tickets are effectively pre-authentication) and delegation (e.g. one server accessing resources on another server on behalf of the original request).

For some reason, Kerberos has always seemed complicated to me, but over the last couple of months I’ve attended two events where the speakers (John Howard from Microsoft, and John Craddock from Kimberry Associates) gave excellent explanations of the Kerberos authentication process, which I have attempted to repeat here for the benefit of others.

Even though it is not a Microsoft standard, Kerberos is the default authentication protocol in Windows 2000, XP and Server 2003, although these all support NTLM for legacy clients. RFC 1510, which defines the Kerberos network authentication service (version 5) actually specifies six messages (five mandatory and one optional), grouped into three pairs of sub-protocols:

• The authentication service (AS) exchange.
• KRB_AS_REQ.
• KRB_AS_REP.
• The ticket granting service (TGS) exchange.
• KRB_TGS_REQ.
• KRB_TGS_REP.
• The client/server (AP) exchange.
• KRB_AP_REQ.
• (KRB_AP_REP).

Central to the Kerberos process is the key distribution center (KDC), which in a Windows implementation is installed on all domain controllers. All parties within the Kerberos transaction are said to be part of the same realm, which really means that they have a common shared secret in order to communicate with trust. All messages are encrypted using keys (symmetric – not PKI). A user key is generated from the logon password, a host key is generated when the computer joins the realm and the KDC is effectively a database of security principles.

The AS exchange takes place at logon and is concerned with giving clients the right to request tickets to access resources (avoiding the need to hold logon factors). In this process, the client sends an KRB_AS_REQ request to the KDC and, if approved, the KDC will generate a ticket granting ticket (TGT) which is returned to the client as part of the KRB_AS_REP reply. The TGT allows the client to request service tickets and is analogous to a passport – i.e. it is valid for a certain period after which it expires; however once the TGT has been issued, there is no further use of passwords or other logon factors.

When the client requires access to a resource, the TGS exchange will commence, whereby the client sends a KRB_TGS_REQ service ticket (ST) request to the KDC with the name of the service to which access is required. The KDC will validate the authentication token within the TGT and if permitted, will return a service ticket which is valid for the requested service as part of the KRB_TGS_REP reply; however at this stage the client is still not authenticated. The service ticket is only valid between the user and the service but provides mutual authentication and speeds up connection times by eliminating the need for the service to perform authentication.

Only after the client has sent a KRB_AP_REQ request to the service server and there is mutual authentication, will the client be authenticated and allowed access to the requested resource. The service server may, or may not, send a KRB_AP_REP reply.

At all stages, only the KDC can read the TGT and only the service can read the ST.

Looking in further detail at the AS exchange, the KRB_AS_REQ includes:

• Client principal name.
• Timestamp.
• Kerberos target principle name (realm).
• Requested lifetime.

The KDC checks for the existence of the user and constructs an encrypted reply, based on the user’s password-based key so that only the real user will be able to decrypt it. This KRB_AS_REP is in two portions:

• The first part is encrypted using the user’s key, containing:
• User-TGS key (generated by the KDC).
• Kerberos target principle name (realm).
• Ticket lifetime.
• The second part is the TGT, which is 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:
• User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
• Client principal name.
• Ticket lifetime.
• KDC timestamp.
• Client IP address (taken from the initial KRB_AS_REQ).

Because the KRB_AS_REQ is sent in clear text, pre-authentication may be required to stop spoofing of KRB_AS_REQs – this can be controlled on a per-user basis but is automatically enabled on Windows 2000/2003 KDCs. Pre-authentication encrypts the KRB_AS_REQ with the user’s password-based key and avoids offline dictionary and brute force attacks because the timestamp within the KRB_AS_REQ must match the current time (within an allowed skew, which is 5 minutes by default).

Moving on to the TGS exchange, the service ticket request (KRB_TGS_REQ) contains:

• Service principal name.
• Requested lifetime.
• TGT (still encrypted with the TGS key).
• Authenticator (encrypted with the user-TGS key and containing a client timestamp)

The authenticator guarantees that the request originated from the client.

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:
• Service principal name.
• Ticket lifetime.
• User service key (encrypted with a user-TGS session key, generated by the KDC).
• Part two is the service ticket, encrypted using the service-TGS key and contains:
• User service key (encrypted with a user-TGS session key, generated by the KDC)..
• Client principal name.
• Ticket lifetime.
• KDC timestamp.
• Client IP address.

Finally, when the client requires access to the service, the AP exchange KRB_AP_REQ contains the service ticket (still encrypted using the service-TGS key) and an authenticator (encrypted with the user-service key). Kerberos does not define an encryption protocol for the service request.

A client can forward its credentials to a service, forwarding a copy of its TGT so that the service can transparently authenticate on the user’s behalf.

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 the 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).
• Because messages are encrypted, only the KDC can read the TGT and only the service can read the ST.