LDAPWiki: Kerberos

Overview [1]#

Kerberos is a computer network authentication protocol, in other words, which allows nodes communicating over a non-Transport-layer Security Mechanism to prove their identity to one another in a secure manner.

Kerberos designers aimed primarily at a client-server model, and it provides mutual Authentication.

Kerberos protocol messages replay attacks.

Kerberos uses Symmetric Key Cryptography and requires a trusted third party. Extensions to Kerberos can provide for the use of Public Key cryptography during certain phases of authentication.

Standards#

The Kerberos Network Authentication Service (V5) was defined within RFC 1510

which was obsoleted by RFC 4120
and augmented by adding negotiation capabilities but do not change the base protocol.
- RFC 4537
- RFC 5021 both of which add negotiation capabilities but do not change the base protocol.
RFC 6649 - Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos DES

Kerberos Authentication and Access to a Resource #

Kerberos Authentication and Access to a Resource is performed in various Exchanges:

Software#

Kerberos is also a "free" and Open Source software published by Massachusetts Institute of Technology (MIT) that implements this protocol.

Kerberos is used within Microsoft Active Directory as the preferred Authentication Protocol.

Kerberos is Legacy Protocol #

Kerberos was created to accomplish authorization when no-one used a secure network connections. Today, everyone should be using a secure connections.

Kerberos was created to keep from passing username and clear-text passwords over the network. Today, everyone should be using a secure connection.

Kerberos is complex to set-up and maintain.

Kerberos cannot be used in scenarios where users want to connect to services from unknown/untrusted clients as in a typical Internet or cloud computer scenario, where the authentication provider typically does not have knowledge about the users client system. This implies Kerberos does not work well with Modern REST applicaitons and Authentication Methods:

Advantages and Disadvantages of Kerberos#

Advantages of Kerberos#

Most conventional network services use password-based authentication schemes. Such schemes require a user to authenticate to a given network server by supplying their username and password. Unfortunately, the transmission of authentication information for many services is un-encrypted. For such a scheme to be secure, the network has to be inaccessible to outsiders, and all computers and users on the network must be trusted and trustworthy.

Any attacker who gains access to the network can use a simple packet analyzer, also known as a packet sniffer, to intercept usernames and passwords sent in this manner, compromising user accounts and the integrity of the entire security infrastructure.

The primary design goal of Kerberos is to eliminate the transmission of un-encrypted passwords across the network. If used properly, Kerberos effectively eliminates the threat packet sniffers would otherwise pose on a network.

Passwords are not exposed to eavesdropping
Password is only typed to the local workstation
- Password never travels over the network
- Password is never transmitted to a remote server
Password guessing more difficult
Single Sign-On - Any service that is Kerberized, only one password, entered once
Stolen tickets hard to reuse - Need authenticator as well, which can NOT be reused
Easier to recover from host compromises
Centralized user account administration

Disadvantages of Kerberos#

Currently, kerberized services do not make use of Pluggable Authentication Modules (PAM) ? kerberized servers bypass PAM completely.

However, applications that use PAM can make use of Kerberos for authentication if the pam_krb5 module is installed. The pam_krb5 package contains sample configuration files that allow services like login and gdm to authenticate users as well as obtain initial credentials using their passwords. If access to network servers is always performed using kerberized services or services that use GSSAPI, such as IMAP, the network can be considered reasonably safe.

Some other known Disadvantages of Kerberos:

Migrating user passwords from a standard UNIX password database, such as /etc/passwd or /etc/shadow, to a Kerberos password database can be tedious, as there is no automated mechanism that will consistently perform this task.
Kerberos assumes that each user is trusted but is using an un-trusted host on an un-trusted network.
For an application to use Kerberos, its source must be modified to make the appropriate calls into the Kerberos libraries. Applications modified in this way are considered to be kerberized. For some applications, this can be quite problematic due to the size of the application or its design. For other incompatible applications, changes must be made to the way in which the server and client side communicate. Again, this may require extensive programming. Closed-source applications that do not have Kerberos support by default are often the most problematic.
Kerberos is an all or nothing solution. Once Kerberos is used on the network, any un-encrypted passwords transferred to a non-kerberized service is at risk.
Single Point of Failure - Kerberos requires continuous availability of a Key Distribution Center. When the Key Distribution Center is down, new users cannot log in. This can be mitigated by using multiple Key Distribution Center and fallback authentication mechanisms.
Kerberos has strict time requirements, which means the clocks of the involved hosts must be synchronized within configured limits. The tickets have a time availability period and if the host clock is not synchronized with the Kerberos server clock, the authentication will fail. The default configuration per MIT requires that clock times be no more than five minutes apart. In practice Network Time Protocol (NTP) daemons are usually used to keep the host clocks synchronized. Note that some servers (Microsoft's implementation being one of them) may return a KRB_AP_ERR_SKEW result containing the encrypted server time in case both clocks have an offset greater than the configured maximum value. In that case, the client could retry by calculating the time using the provided server time to find the offset. This behavior is documented in RFC 4430.
The administration protocol is not standardized and differs between server implementations. Password changes are described in RFC 3244.
In case of Symmetric Key Cryptography adoption (Kerberos can work usingSymmetric Key Cryptography or Asymmetric Key Cryptography ), since all authentications are controlled by a centralized Key Distribution Center (KDC), compromise of this authentication infrastructure will allow an attacker to perform impersonation of any user. (Kerberos Forged Ticket)
Each network service which requires a different hostname will need its own set of Kerberos keys. This complicates Virtual Machine hosting and clusters.
Kerberos requires user accounts, user clients and the services on the server to all have a trusted relationship to the Kerberos token server. All must be in the same Kerberos Realm or in domains that have a trust relationship between each other.
Kerberos cannot be used in scenarios where users want to connect to services from unknown/untrusted clients as in a typical Internet or cloud computing scenario, where the authentication provider typically does not have knowledge about the users client system.
The required client trust makes creating staged environments (e.g., separate domains for test environment, pre-production environment and production environment) difficult. Either domain trust relationships need to be created that prevent a strict separation of environment domains or additional user clients need to be provided for each environment.
Each client must have Kerberos client installed which on many Mobile Devices and ChromeBook Devices would be problematic.

Kerberos Information#

Kerberos uses port 88 by default.
We will refer to Kerberos 5 unless otherwise noted.
Kerberos makes extensive use of Symmetric Key Cryptography.

Network Security#

Kerberos generally distrusts the security of the underlying network. Kerberos does, however, assume that application hosts and especially hosts used in the operation of the Kerberos Key Distribution Center (KDC) are secure. Specifically Kerberos:

Never sends passwords or credentials across the network.
Mandates that password/credential information is stored only in a single secure location, the KDC. The corollary is that credentials are never stored on the host that the user uses to login. Once the initial AS Exchange takes place the password MUST be discarded by that local device. (Alas it is not really done as seen in password-hash attacks)
Application hosts/servers must be able to prove their identity to anyone requesting such proof.
All communication between Authenticated Clients and application SP must be capable of being encrypted. Various bulk cipher algorithms (all symmetric) are supported and may be negotiated.

Kerberos Security Advisories #

The list of Kerberos Security Advisories

Kerberos Principal #

Kerberos defines two different types of accounts (or Principals). The two different names given to these types of accounts are UserPrincipalName (UPN), and Service Principal Name SPN. We would typically relate these two types of principals to Active Directory users and computers.

Identity Provider (IDP)#

The Kerberos 5 authentication back end does not contain a Kerberos Database (Identity Provider (IDP)) and MUST be paired with one in order to function properly.

Some information required by the Kerberos authentication back end must be supplied by the Kerberos Database, such as the user's UserPrincipalName (UPN), and Service Principal Name (SPN) for each entity to work in Kerberos.

Kerberos Anomalies #

Kerberos CANNOT distinguish between 'Account Disabled', 'Account Locked out' and 'Account Expired'. They share the same Kerberos error code 18. LDAP can distinguish them by providing multiple return codes.

Kerberos vs LDAP #

LDAP was designed as a directory access protocol. Kerberos was designed as an authentication protocol.

LDAP has multiple authentication mechanisms including:

simple bind - The typical username and password combination.
SASL Mechanisms (SASL) - The Simple Authentication and Security Layer (SASL) is an extensible framework that is primarily used for Authentication users, but in some cases it may also be used for protecting the underlying communication channel.
GSSAPI - The GSSAPI SASL mechanism provides a way for clients to authentication to a LDAP Directory Server using a Kerberos V5 session.

Kerberos with extensions can provide some limited additional information.

Microsoft Active Directory supports:

GSSAPI (Kerberos)
GSS-SPNEGO (Windows negotiate authentication which selects between Kerberos and NTLM),
Digest and External (for client cert auth).

Thus, if the client understands any of those SASL Mechanisms, it can actually use that for the authentication. As such, Kerberos may be used by an application during an LDAP Bind Request if the client understands this.

Troubleshooting Kerberos #

Some tips on Troubleshooting Kerberos.

More Information#

There might be more information for this subject on one of the following:

[#1] - From: http://en.wikipedia.org/wiki/Kerberos_(protocol)
[#2] - Kerberos: The Network Authentication Protocol - based on information obtained 2018-01-07-