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 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. 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 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)
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.
- 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.
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.LDAP can distinguish them by providing multiple return codes. 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).
More Information#There might be more information for this subject on one of the following:
- AS Exchange
- Active Directory Functional Levels
- Apple Directory
- Authentication Protocol
- Best Practices for LDAP Security
- Cipher Suite
- Client-Server Exchange
- Client-To-Server Session Key
- Client-To-Server Ticket
- Dynamic Access Control
- Generic Security Service Application Program Interface
- Golden Ticket
- How passwords are used in Windows
- Identity Broker
- Implementing Universal Password
- Initiate Kerberos
- JSON Identity Suite
- Kerberos Authentication Service
- Kerberos Database
- Kerberos Delegation
- Kerberos Encryption Types
- Kerberos Error Codes
- Kerberos Forged Ticket
- Kerberos Pre-Authentication
- Kerberos Principal
- Kerberos Realm
- Kerberos SSP
- Kerberos Tools
- LAN Manager authentication level
- LDAP Authentication
- LDAP Server Standards and Specifications
- Local Security Authority
- Local Security Authority Subsystem Service
- NDSD Loadable Module
- NT LAN Manager
- NT LAN Manager Vulnerabilities
- Negotiate SSP
- PDC Emulator FSMO Role
- Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
- Public Key Cryptography Based User-to-User
- RFC 3244
- RFC 3961
- RFC 3962
- Security Support Provider
- Security Support Provider Interface
- Service Provider
- Shared Secret
- Simple and Protected GSSAPI Negotiation Mechanism
- TGS Exchange
- The Kerberos Version 5 GSS-API Mechanism
- The Simple Public-Key GSS-API Mechanism
- Ticket Granting Service
- Ticket Granting Ticket
- Token Revocation
- Troubleshooting Kerberos
- Troubleshooting Kerberos SPN
- User-Account-Control Attribute Values
- Verify DNS Records
- Why is Time Important
- Windows Integrated Authentication
- Windows Logon
- [#1] - From: http://en.wikipedia.org/wiki/Kerberos_(protocol)
- [#2] - Kerberos: The Network Authentication Protocol - based on information obtained 2018-01-07-