Kerberos Concepts

Kerberos is a computer network authenticationprotocol that works on the basis of 'tickets' to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. The protocol was named after the character Kerberos (or Cerberus) from Greek mythology, the ferocious three-headed guard dog of Hades (hellhound). Its designers aimed it primarily at a client–servermodel and it provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.
Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication.^[1]Kerberos uses UDP port 88 by default.

Microsoft Windows

Windows 2000 and later uses Kerberos as its default authentication method. ^[3]Some Microsoftadditions to the Kerberos suite of protocols are documented in RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols". RFC 4757 documents Microsoft's use of the RC4cipher. While Microsoft uses the Kerberos protocol, it does not use the MIT software.

Kerberos is used as preferred authentication method: In general, joining a client to a Windows domain means enabling Kerberos as default protocol for authentications from that client to services in the Windows domain and all domains with trust relationships to that domain. ^[3]

In contrast, when either client or server or both are not joined to a domain (or not part of the same trusted domain environment), Windows will instead use NTLM for authentication between client and server. ^[3]

Intranet web applications can enforce Kerberos as an authentication method for domain joined clients by using APIs provided under SSPI.

UNIX and UNIX-like operating systems

Many UNIX and UNIX-like operating systems, including FreeBSD, Apple's Mac OS X, Red Hat Enterprise Linux, Oracle's Solaris, IBM's AIX and Z/OS, HP's HP-UX and OpenVMS and others, include software for Kerberos authentication of users or services. Embedded implementation of the Kerberos V authentication protocol for client agents and network services running on embedded platforms is also available from companies.

Protocol

Description

The client authenticates itself to the Authentication Server (AS) which forwards the username to a key distribution center (KDC). The KDC issues a ticket-granting ticket (TGT), which is time stamped, encrypts it using the user's password and returns the encrypted result to the user's workstation. This is done infrequently, typically at user logon; the TGT expires at some point, though may be transparently renewed by the user's session manager while they are logged in.

When the client needs to communicate with another node ("principal" in Kerberos parlance) the client sends the TGT to the ticket-granting service (TGS), which usually shares the same host as the KDC. After verifying the TGT is valid and the user is permitted to access the requested service, the TGS issues a ticket and session keys, which are returned to the client. The client then sends the ticket to the service server (SS) along with its service request.

Kerberos negotiations

The protocol is described in detail below.

User Client-based Logon

1. A user enters a username and password on the client machine(s). Other credential mechanisms like pkinit (RFC 4556) allow for the use of public keys in place of a password.
2. The client transforms the password into the key of a symmetric cipher. This either uses the built-in key scheduling, or a one-way hash, depending on the cipher-suite used.

Client Authentication

1. The client sends a cleartext message of the user ID to the AS (Authentication Server) requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.) The AS generates the secret key by hashing the password of the user found at the database (e.g., Active Directory in Windows Server).
2. The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:
• Message A: Client/TGS Session Key encrypted using the secret key of the client/user.
• Message B: Ticket-Granting-Ticket (TGT, which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.
3. Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user. If the user entered password does not match the password in the AS database, the client's secret key will be different and thus unable to decrypt message A. With a valid password and secret key the client decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS's secret key.) At this point, the client has enough information to authenticate itself to the TGS.

Client Service Authorization

1. When requesting services, the client sends the following messages to the TGS:
• Message C: Composed of the TGT from message B and the ID of the requested service.
• Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.
2. Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the "client/TGS session key". Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client:
• Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service's secret key.
• Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.

Client Service Request

1. Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the Service Server (SS). The client connects to the SS and sends the following two messages:
• Message E from the previous step (the client-to-server ticket, encrypted using service's secret key).
• Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using Client/Server Session Key.
2. The SS decrypts the ticket (message E) using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:
• Message H: the timestamp found in client's Authenticator (plus 1 in version 4, but not necessary in version 5^[4][5]), encrypted using the Client/Server Session Key.
3. The client decrypts the confirmation (message H) using the Client/Server Session Key and checks whether the timestamp is correct. If so, then the client can trust the server and can start issuing service requests to the server.
4. The server provides the requested services to the client.

Kerberos Explained

By Mark Walla

Article from the May 2000 issue of Windows 2000 Advantage magazine
Although this article is billed as a primer to Kerberos authentication, it is a high technical review. Kerberos is an integral part of Windows 2000 Active Directory implementations, and anyone planning to deploy and maintain a Windows 2000 enterprise must have a working knowledge of the principals and administrative issues involved in this front-line security technology.
Since many other operating system vendors are also adopting this MIT-developed authentication protocol, Kerberos Version 5 will increasingly become a centerpiece of enterprise-level interoperability. Kerberos provides secure user authentication with an industry standard that permits interoperability. The Active Directory domain controller maintains user account and log-in information to support the Kerberos service.
The process of authenticating the identity of users during log-in is the first step in gaining system access. For local machines that aren't actively participating in a domain, Windows NT LAN Manager protocol is still utilized to verify a user's name and password before granting system access. However, in domain environments, Microsoft has coupled Active Directory closely with Kerberos. Once access is granted, tickets that permit specific access to other system resources within the domain are exchanged.

On This Page

Kerberos 101
Understanding Kerberos concepts
Further Clarification of the Log-in Process
Postscript

Kerberos 101

Underlying Windows 2000 security is the concept of user authentication. The centralized account management supported by Active Directory Services requires a corresponding authentication protocol for network log-on. Based on RFC 1510, the Kerberos Version 5 protocol provides enhanced authentication for the distributed computing environment and standardization to interoperate with other operating systems.
Defaulting to Kerberos
NT LAN Manager is the authentication protocol used in Windows NT and in Windows 2000 work group environments. It is also employed in mixed Windows 2000 Active Directory domain environments that must authenticate Windows NT systems. At the stage Windows 2000 is converted to native mode where no down-level Windows NT domain controllers exist, NT LAN Manager is disabled. Kerberos then becomes the default authentication technology for the enterprise.

Top of page

Understanding Kerberos concepts

Kerberos Version 5 is standard on all versions of Windows 2000 and ensures the highest level of security to network resources. The Kerberos protocol name is based on the three- headed dog figure from Greek mythology known as Kerberos. The three heads of Kerberos comprise the Key Distribution Center (KDC), the client user and the server with the desired service to access. The KDC is installed as part of the domain controller and performs two service functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS). As exemplified in Figure 1, three exchanges are involved when the client initially accesses a server resource:

1.      AS Exchange

2.      TGS Exchange

3.      Client/Server (CS) Exchange

Figure 1:

Let's take a closer look at this exchange process and its component parts.

AS Exchange

When initially logging on to a network, users must negotiate access by providing a log-in name and password in order to be verified by the AS portion of a KDC within their domain. The KDC has access to Active Directory user account information. Once successfully authenticated, the user is granted a Ticket to Get Tickets (TGT) that is valid for the local domain. The TGT has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter his password. The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network. The following is a discussion of the TGT retrieval process.

Example AS Administration

The AS request identifies the client to the KDC in plain text. If preauthentication is enabled, a time stamp will be encrypted using the user's password hash as an encryption key. If the KDC reads a valid time when using the user's password hash (stored in the Active Directory) to decrypt the time stamp, the KDC knows that request isn't a replay of a previous request. The preauthentication feature may be disabled for specific users in order to support some applications that don't support the security feature. Access the user account from the Active Directory users and the computers will snap-in and select the account tab. From the account options: slide window, check mark the "Do not require Kerberos" preauthentication option (Figure 2).

Figure 2: Disable Kerberos Preauthentication

If the KDC approves the client's request for a TGT, the reply (referred to as the AS reply) will include two sections: a TGT encrypted with a key that only the KDC (TGS) can decrypt and a session key encrypted with the user's password hash to handle future communications with the KDC. Because the client system cannot read the TGT contents, it must blindly present the ticket to the TGS for service tickets. The TGT includes time to live parameters, authorization data, a session key to use when communicating with the client and the client's name.

TGS Exchange

The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user's TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, is then cached locally on the client machine.
The TGS receives the client's TGT and reads it using its own key. If the TGS approves of the client's request, a service ticket is generated for both the client and the target server. The client reads its portion using the TGS session key retrieved earlier from the AS reply. The client presents the server portion of the TGS reply to the target server in the client/server exchange coming next.

Client/Server Exchange

Once the client user has the client/server service ticket, he can establish the session with the server service. The server can decrypt the information coming indirectly from the TGS using its own long-term key with the KDC. The service ticket is then used to authenticate the client user and establish a service session between the server and client. After the ticket's lifetime is exceeded, the service ticket must be renewed to use the service.

Client/Server Exchange Detail

The client blindly passes the server portion of the service ticket to the server in the client/server request to establish a client/server session. If mutual authentication is enabled, the target server returns a time stamp encrypted using the service ticket session key. If the time stamp decrypts correctly, not only has the client authenticated himself to the server, but the server also has authenticated itself to the client. The target server never has to directly communicate with the KDC. This reduces downtime and pressure on the KDC.

Further Clarification of the Log-in Process

A TGT and a service ticket are needed to access services on remote computers, but they are also required to successfully log on to a local system. When the log-on window appears, password encryption using a one-way hash algorithm occurs immediately and negotiations commence with the KDC for a valid TGT and service ticket. The process is the same as accessing a remote service. An access token is created for the user containing all security groups to which they belong. This access token is attached to the user's log-on session and is subsequently inherited by any process or application the user starts.

Referral Tickets

The AS and TGS functions are separate within the KDC. This permits the user to use the TGT obtained from an AS in his domain to obtain service tickets from a TGS in other domains. This is accomplished through referral tickets.
Once a trust has been established between two domains, referral tickets can be granted to clients requesting authorization for services in other domains. When there is a trust established between the two domains, an interdomain key based on the trust password becomes available for authenticating KDC functions. This can best be explained by example of a user/client seeking services in another domain. As illustrated in Figure 3, a user client in Entcert1.com requests authority for a server in Entcert2.com. He utilizes referral tickets. The numbers in Figure 3 correspond to the following numbered explanations:

1.      The client contacts its domain KDC TGS using a TGT. The KDC recognizes a request for a session with a foreign domain server and responds by returning a referral ticket for the KDC in the foreign domain.

2.      The client contacts the KDC of the foreign domain with the referral ticket. This ticket is encrypted with the interdomain key. Given that the decryption works, the TGS service for the foreign domain returns a service ticket for the server service in Entcert2.com.

3.      The client performs the client/server exchange with the server and begins the user session with the service.

Figure 3: Domain Referrals

When more domains are involved, the referral process extends and involves the transitive properties between Windows 2000 domains. Maintaining individual two-way trusts between all domains creates a complex administrative nightmare. The use of Kerberos transitive domains cuts down on interdomain administration. This can best be explained by example of a user/client seeking services in another domain. As illustrated in Figure 11-4, Entcert1.com has a trust relationship with Entcert2.com. Entcert2.com has a trust relationship with Entcert3.com. There is no trust between Entcert1.com and Entcert3.com. A client from Entcert1.com accessing a service on a server in Entcert3.com would obtain a service ticket through the following steps (the numbers appearing in Figure 4 correspond to the following numbered explanations):

1.      Use the TGS service in Entcert1.com to obtain a referral ticket for a KDC in Entcert2.com.

2.      Use the referral ticket with the TGS service on the KDC in Entcert2.com and obtain a referral for Entcert3.com.

3.      Use the second referral ticket with the TGS service on the KDC for Entcert3.com and obtain a service ticket for the server in Entcert3.com.

4.      Use the Client/Server Exchange to open a session with the service in Entcert3.com.

Figure 4: Transitive Domain Trusts

Delegation with Forwarding and Proxy

Some server services require access to a second server, such as a back-end database. In order to establish a session with the second server, the primary server must be authenticated on behalf of the client's user account and authority level. This is common in a three-tier client/server model. This activity is commonly accomplished with proxy or forwarding authentication.

Postscript

The authentication process implemented by Kerberos is highly effective, but a few hundred words cannot do the subject justice. That is why I recommend that this article be used as a primer and that you seek more in-depth technical white papers, books or consulting services prior to actual implementation. Once you understand Kerberos and how it can serve both a pure Windows 2000 and mixed operating environment then your investment should pay high dividends.

What Is Kerberos Authentication?

What Is Kerberos Authentication?

In this section

• Kerberos Authentication Benefits
• Kerberos V5 Protocol Standards
• Supported Extensions to the Kerberos V5 Protocol
• Technologies Related to Kerberos Authentication
• Kerberos Authentication Dependencies

The Kerberos version 5 authentication protocol provides a mechanism for authentication — and mutual authentication — between a client and a server, or between one server and another server.
Windows Server 2003 implements the Kerberos V5 protocol as a security support provider (SSP), which can be accessed through the Security Support Provider Interface (SSPI). In addition, Windows Server 2003 implements extensions to the protocol that permit initial authentication by using public key certificates on smart cards.
The Kerberos Key Distribution Center (KDC) uses the domain’s Active Directory directory service database as its security account database. Active Directory is required for default NTLM and Kerberos implementations.
The Kerberos V5 protocol assumes that initial transactions between clients and servers take place on an open network in which packets transmitted along the network can be monitored and modified at will. The assumed environment, in other words, is very much like today’s Internet, where an attacker can easily pose as either a client or a server, and can readily eavesdrop on or tamper with communications between legitimate clients and servers.
Microsoft’s implementation of the Kerberos V5 protocol is:

The default authentication package for Windows Server 2003.

The Kerberos V5 protocol became the default authentication package with Windows 2000. Windows Server 2003 still supports NTLM for non-Kerberos clients such as the Windows NT Server 4.0 operating system.

Based on RFC 1510 and draft revisions.

The Kerberos protocol is a mature, widely used, open standard. Microsoft’s implementation of the Kerberos V5 protocol adheres to the defined RFC standards, and thus provides interoperability with other implementations.

Extensible.

Kerberos architecture allows you to specify additional or alternate security methods. Also, the default shared secret key process can be supplemented with private/public key pairs by using smart cards.

Kerberos Authentication Benefits

The Kerberos V5 protocol is more secure, more flexible, and more efficient than NTLM. The benefits gained by using Kerberos authentication are:

Delegated authentication.

Windows services impersonate a client when accessing resources on the client’s behalf. In many cases, a service can complete its work for the client by accessing resources on the local computer. Both NTLM and the Kerberos V5 protocol provide the information that a service needs to impersonate its client locally. However, some distributed applications are designed so that a front-end service must impersonate clients when connecting to back-end services on other computers. The Kerberos V5 protocol includes a proxy mechanism that enables a service to impersonate its client when connecting to other services. No equivalent is available with NTLM.

Interoperability.

Microsoft’s implementation of the Kerberos V5 protocol is based on standards-track specifications that are recommended to the Internet Engineering Task Force (IETF). As a result, the implementation of the Kerberos V5 protocol in Windows Server 2003 lays a foundation for interoperability with other networks in which the Kerberos V5 protocol is used for authentication.

More efficient authentication to servers.

With NTLM authentication, an application server must connect to a domain controller in order to authenticate each client. With the Kerberos V5 authentication protocol, on the other hand, the server is not required to go to a domain controller. Instead, the server can authenticate the client by examining credentials presented by the client. Clients can obtain credentials for a particular server once and then reuse those credentials throughout a network logon session. Renewable session tickets replace pass-through authentication. For more information about what renewable session tickets are and how they work, please see “How the Kerberos Version 5 Authentication Protocol Works.”

Mutual authentication.

By using the Kerberos protocol, a party at either end of a network connection can verify that the party on the other end is the entity it claims to be. Although NTLM enables servers to verify the identities of their clients, NTLM does not enable clients to verify a server’s identity, nor does NTLM enable one server to verify the identity of another. NTLM authentication was designed for a network environment in which servers were assumed to be genuine. The Kerberos V5 protocol makes no such assumption.

Kerberos V5 Protocol Standards

The Kerberos authentication protocol originated at MIT more than a decade ago, where it was developed by engineers working on Project Athena. The first public release was the Kerberos version 4 authentication protocol. After extensive industry review of that protocol, the protocol’s authors developed and released the Kerberos version 5 authentication protocol.
The Kerberos V5 protocol is now on a standards track with the IETF. The implementation of the protocol in Windows Server 2003 closely follows the specification defined in Internet RFC 1510. In addition, the mechanism and format for passing security tokens in Kerberos messages follows the specification defined in Internet RFC 1964.
The Kerberos V5 protocol specifies mechanisms to:

• Authenticate user identity. When a user wants to gain access to a server, the server needs to verify the user’s identity. Consider a situation in which the user claims to be, for example, Alice@tailspintoys.com. Because access to resources are based on identity and associated permissions, the server must be sure the user really has the identity it claims.
• Securely package the user’s name. The user’s name — that is, the User Principal Name (UPN): Alice@tailspintoys.com, for example — and the user’s credentials are packaged in a data structure called a ticket.
• Securely deliver user credentials. After the ticket is encrypted, messages are used to transport user credentials along the network.

Note

• Although the Kerberos protocol authenticates the user's identity, it does not authorize access. This is an important distinction. Tickets in other contexts, such as drivers' licenses, often both prove identity and authorize actions or access. A Kerberos ticket only proves that the user is who the user claims to be. After the user’s identity is verified, the Local Security Authority will authorize or deny resource access.

Keys: Privacy Through Encryption

Kerberos messages are encrypted with various encryption keys to ensure that no one can tamper with the client’s ticket or with other data in a Kerberos message.
Possible Kerberos keys include:

Long-term key.

A key — known only to the target server and the KDC — with which the client’s ticket is encrypted.

Client/server session key.

A short-term, single-session key that is created by the KDC and used to encrypt the client-to-server and server-to-client messages after identity and authorization have been confirmed.

KDC/user session key.

The KDC and the user share a secret encryption key as well, which is used, for example, to encrypt the message to the client containing a session key.

The Kerberos V5 protocol can use both symmetric and asymmetric encryption

Because most Kerberos encryption methods are based on keys that can be created only by the KDC and the client, or by the KDC and a network service, the Kerberos V5 protocol is said to use symmetric encryption. That is, the same key is used to encrypt and decrypt messages.
Microsoft’s implementation of the Kerberos protocol can also make limited use of asymmetric encryption. A private/public key pair can be used to encrypt or decrypt initial authentication messages from a network client or a network service.

Kerberos Authenticator Prevents Packet Replay

The Kerberos authentication mechanism creates and securely delivers an authenticator — usually based on unique timestamps — along with the client’s ticket. The authenticator is unique and valid for only one use. This limited use minimizes the possibility of someone obtaining and re-using (replaying) the client ticket, perhaps in an attempt to steal and use the client’s identity.

Supported Extensions to the Kerberos V5 Protocol

Windows Server 2003 implements extensions to the Kerberos V5 protocol. The extensions enable initial authentication by using public key certificates instead of conventional shared secret keys. This enhancement enables the protocol to support interactive logon with a smart card. The extensions for public key authentication are based on a draft specification being worked on by the IETF working group.

Technologies Related to Kerberos Authentication

The following diagram shows how Kerberos authentication fits with other technologies in Windows Server 2003. Depending on whether the client or server applications are user-mode or kernel-mode applications, they use either Secur32.dll or Ksecdd.sys, respectively, by means of SSPI calls to communicate with the Local Security Authority Subsystem (LSASS).
Kerberos Architecture

The following table is a description of the components that participate in Kerberos Authentication.
Security Subsystem Components Used in Digest Authentication

 

Component	Description
Kerberos.dll	The SSP that implements an industry-standard protocol that is used with either a password or a smart card for interactive logon. It is also the preferred authentication method for services in Windows 2000 and Windows Server 2003.
Kdcsvc.dll	The Kerberos Key Distribution Center (KDC) service, which is responsible for providing ticket-granting tickets to clients.
Ksecdd.sys	The Kernel Security Device Driver is used to communicate with LSASS in user mode.
Lsasrv.dll	The LSA Server service, which both enforces security policies and acts as the security package manager for the LSA.
Secur32.dll	The Secur32.dll component is the multiple authentication provider that implements SSPI for user mode applications.

Windows Server 2003 implements the Kerberos V5 authentication protocol as an SSP, which is a dynamic-link library (DLL) supplied with the operating system. The system uses the Kerberos SSP, Kerberos.dll, as its first choice for authentication. After the LSA establishes a security context for an interactive user, another instance of the Kerberos SSP can be loaded by a process running in the user’s security context in order to support the signing and sealing of messages.
Because the Kerberos protocol is the preferred authentication protocol for Windows Server 2003, all domain services support the Kerberos SSP, including:

• Active Directory queries that use the Lightweight Directory Access Protocol (LDAP).
• Remote server or workstation management using RPC calls.
• Print services.
• Client-server authentication.
• Remote file access that uses Common Internet File System/server message block (CIFS/SMB).
• Distributed file system management and referrals.
• Intranet authentication to Internet Information Services (IIS).
• Security authority authentication for Internet Protocol security (IPSec).
• Certificate requests to Certificate Services for domain users and computers.

Kerberos Authentication Dependencies

This section reviews dependencies and summarizes how each dependency relates to Kerberos authentication.

Operating System

Kerberos authentication relies on client functionality that is built in to the Windows Server 2003 operating system, the Microsoft Windows XP operating system, and the Windows 2000 operating system. If a client, domain controller, or target server is running an earlier operating system, it cannot natively use Kerberos authentication.

TCP/IP Network Connectivity

For Kerberos authentication to occur, TCP/IP network connectivity must exist between the client, the domain controller, and the target server. For more information about TCP/IP, see “TCP/IP Technical Reference.”

Domain Name System

The client uses the fully qualified domain name (FQDN) to access the domain controller. DNS must be functioning for the client to obtain the FQDN.
For best results, do not use Hosts files with DNS. For more information about DNS, see “DNS Technical Reference.”

Active Directory Domain

Kerberos authentication is not supported in earlier operating systems, such as the Microsoft Windows NT 4.0 operating system. You must be using user and computer accounts in the Active Directory directory service to use Kerberos authentication. Local accounts and Windows NT domain accounts cannot be used for Kerberos authentication.

Time Service

For Kerberos authentication to function correctly, all domains and forests in a network should use the same time source so that the time on all network computers is synchronized. An Active Directory domain controller acts as an authoritative source of time for its domain, which guarantees that an entire domain has the same time. For more information, see “Windows Time Service Technical Reference.”

Service Principal Names

Service principal names (SPNs) are unique identifiers for services running on servers. Every service that uses Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. If an SPN is not set for a service, clients have no way of locating that service. Without correctly set SPNs, Kerberos authentication is not possible. For more information about user-to-user authentication, see “How the Kerberos Version 5 Authentication Protocol Works,” and search for “The User-to-User Authentication Process.”

Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. A free implementation of this protocol is available from the Massachusetts Institute of Technology. Kerberosis available in many commercial products as well

Kerberos lets a user request an encrypted "ticket" from an authentication process that can then be used to request a particular service from a server. The user's password does not have to pass through the network. A version of Kerberos (client and server) can be downloaded from MIT or you can buy a commercial version.

Kerberos is a secure method for authenticating a request for a service in a computer network. Kerberoswas developed in the Athena Project at the Massachusetts Institute of Technology (MIT). The name is taken from Greek mythology; Kerberos was a three-headed dog who guarded the gates of Hades.

Kerberos is primarily a UDP protocol, although it falls back to TCP for large Kerberos tickets. This may require special configuration on firewalls to allow the UDP response from the Kerberos server (KDC). Kerberos clients need to send UDP and TCP packets on port 88 and receive replies from the Kerberos servers.

Kerberos is a network authentication protocol created by MIT, and uses symmetric-key cryptography ⁠ to authenticate users to network services, which means passwords are never actually sent over the network.

Share on FacebookPlus on Google+

SUBSCRIBE MORE CONTENTS