Context

An online application needs access to one or more Web services. The Web services require that the application presents proof of authentication, so that additional controls such as authorization and auditing can be implemented. The organization needs to use an Authentication Broker to issue security tokens that can be used for authentication.

Problem

How does the Web service verify the credentials presented by the requesting application?

Forces

Solution

Use the Kerberos protocol to broker authentication between online applications and Web services. The requestor first authenticates the subject with the Kerberos Authentication Service, which issues a Ticket Granting Ticket (TGT). The TGT is used for all requests by the requestor to the Ticket Granting Service (TGS). The requestor can then use the TGT to obtain a service granting ticket (SGT) from the TGS. The request message and SGT are sent to the Service Host. The Service Host receives the message and authenticates the Subject using the SGT.

Participants

• Requestor – the online application needing to access the Web service. Provides the Subject's credentials for authentication during the service request to the Service. 
• Subject - A user, application, or server that needs to be authenticated prior to accessing a service. 
• Service - The Web service that requires authentication of a Subject prior to making access control decisions.
• Key distribution center (KDC) - The Authentication Broker responsible for authenticating Subjects and issuing security tokens. One or more KDC's operate in a Kerberos realm, defined by a population of Subjects that share an Identity Provider. 
• Authentication Service (AS) - a component of the KDC responsible for authenticating subjects and issuing a Ticket Granting Ticket (TGT) to be used as proof of authentication. As Kerberos relates back to Trust Broker, a TGT is a type of Proof-of-Authentication Token (For more information, see Security Tokens in the Glossary) 
• Ticket Granting Service (TGS) - a component of the KDC responsible for issuing a Service Granting Ticket (SGT) used to negotiate trust between and authenticate Subject and a resource.  Subjects obtain an SGT from the TGS by presenting a valid TGT, obtained from the Authentication Service.

Kerberos is an Authentication protocol that requires the following additional components.

• Account database – An Identity Store with which the Kerberos KDC checks Subject credentials presented for authentication. For Kerberos operating on a Domain Controller running on Windows Server 2000 or 2003 this function is provided through the use of Active Directory. 
• Kerberos policy - Security policy to restrict user logon restrictions, service ticket lifetimes, user ticket lifetimes, clock synchronization, delegation etc

Process

The process of using Kerberos for authentication is shown in Figure 1.

Figure 1

Requestor Process of Kerberos Authentication

The steps of the authentication process depicted in the above diagram are described below:

1.  The Requestor presents the subject's credentials to the KDC's Authenication Service (AS) for authentication. The requestor creates a digest as a password equivalent for the shared secret, to protect it during transmission

2.  The Requestor receives a Ticket Granting Ticket (TGT) from the KDC's Authentication service that provides proof that the subject has successfully authenticated (proof of authentication).

3.  Requestor sends a message to the Ticket Granting Service (TGS), requesting access to the ServiceHost. The requestor presents the subject's TGT as proof of authentication.

4.  The TGS responds to the requestor, returning a Service Granting Ticket (SGT). The SGT is a type of session token that represents that trust has been negotiated between the Subject and Service Host by the KDC.

5.  A Request message is sent to service host, along with the SGT.

6.  The Service Host verifies that the session token has not been tampered with in transit and was issued by a trusted KDC. If so, then the Service Host allows the request to be processed by the Service

7.  The Subject's identity information within the SGT enables the Service Host or Service to establish a security context that will make authorization decisions about the Subject

8.  The Service returns a response to the Requestor.

Kerberos follows the basic pattern of Brokered Authentication, but has properties that differentiate it from other types of brokered authentication, including:

• The Kerberos protocol supports the notion of token renewal; but it does not support token revocation. By default, Kerberos security tokens are of a fixed lifetime of 10 hours and are not renewable, though the token lifetime and the ability to renew tokens are both configurable through Kerberos policy.
• Kerberos does not typically terminate a security token when an authenticated Subject is finished communicating during a session. Instead, it lets the security token expire at the end of its normal lifetime.

Kerberos can be used for brokering authentication at either the transport or message layer. Some implementations of Kerberos include:

• Transport-layer Kerberos
  • Windows Integrated Security 
  • IPSec 
• Message-layer Kerberos 
  • WSE 2.0 KerberosToken2

Resulting Context

The following benefits, liabilities, and security considerations are associated with the use of Kerberos as an Authentication Broker.

Benefits

• Kerberos provides single on capabilities, requiring a user to authenticate only once per session.
• Kerberos has broad acceptance as a brokered authentication protocol and is in use in the majority of large organizations that have centralized their authentication management infrastructure.
• Kerberos is closely integrated with the Microsoft Windows Operating System (Windows 2000 and above). This enables the operating system to provide security capabilities such as user impersonation, authorization and auditing.

Liabilities

• The centralized nature of Kerberos requires a KDC acting as a Trust Broker to be available at all times. If the KDC fails, Requestors and Services cannot establish new trust relationships, or validate existing trust relationships. You should consider using redundant KDCs or providing an alternative mechanism for authentication, such as X.509 Certificates, if the availability of the Trust Broker cannot be guaranteed. In the Kerberos implementation provided in Active Directory, KDC availability can be improved by establishing secondary domain controllers. This creates a redundant set of Kerberos KDCs.
• Mutual authentication occurs between the Subject and the Host Service through a trusted session, established by the Kerberos KDC. However, the Host Server does not positively identify itself to the Subject. The subject only knows that the Service Host is a valid object within the Kerberos realm. If the Subject's shared identity secret is ever compromised, a man-in-the-middle attack between the Requestor and KDC is possible.
• Kerberos does not implement authorization, although it is typically coupled with an Identity Provider that may store role information for a Subject. Resources can control access based on role information obtained from an external directory service from the Subject's unique identifier contained in the SGT. 

• Kerberos security is only useful for authentication and secure communication. Kerberos is not useful for long term-persistence, due to the limited lifespan of the shared secret.
• Proof-of-Authentication for a Subject cannot be established outside of the security domain, unless trust is explicitly established with the other security domain attempting to verify the Subject’s Proof-of-Authentication.
• Each host on the network must have a clock which is "loosely synchronized" to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection. The degree of "looseness" can be configured on a per-server basis. If the clocks are synchronized over the network, the clock synchronization protocol must itself be secured from network attackers.

Security Considerations

• Subjects must keep their secret keys secret. If an intruder somehow steals a Subject's key, it will be able to masquerade as that Subject or impersonate any server to the legitimate Subject.
• "Password guessing" attacks can occur with Kerberos against messages encrypted with a password equivalent, derived from the user's shared secret. Kerberos uses a derived key created from the subject's password to encrypt data in the authentication request. An attacker could mount an offline dictionary attack by repeatedly attempting to decrypt the data in the authentication request sent to the KDC in order to discover the subject's password.
• Kerberos cannot be used for non-repudiation, because the Subject's identity secret is shared with the KDC.

Related Patterns

Child Patterns

• Pattlet – Transport Layer Security using Windows Integrated Security with Kerberos on IIS 
• Implementing Message Layer Security with X.509 Certificates in WSE 2.0.

Alternative Patterns

• X509 PKI

Dependent Patterns

• Federation using Kerberos - KerberosCrossRealmTrust - Establishing trust across KerberosRealms (TBD if in scope)

References

• RFC 1510: The Kerberos Network Authentication Service (V5) at http://www.ietf.org/rfc/rfc1510.txt
• Kerberos Authentication Technical Reference at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/792ed95d-6f13-4181-a218-e4eaab361c1b.mspx

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.