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
Software#Kerberos is also a suite of free 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 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 central server. When the Kerberos server is down, new users cannot log in. This can be mitigated by using multiple Kerberos servers 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 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 cryptography adoption (Kerberos can work using symmetric or asymmetric (public-key) cryptography), since all authentications are controlled by a centralized key distribution center (KDC), compromise of this authentication infrastructure will allow an attacker to impersonate any user.
Each network service which requires a different host name will need its own set of Kerberos keys. This complicates virtual 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 domain 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 computer 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 Encryption.
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 locatio, the KDC. The corollary is that credentials are never stored on the host that the user uses to login. Once the initial Authentication exchange takes place the password must be discarded by that host.
- 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.
Client-Principal to Service Provider Authorization#When requesting services from the Service Provider, the Client-Principal sends the following two messages to the Ticket Granting Service TGS:
- TGT and the ID of the requested service.
- Authenticator Message - which is composed of the client ID and the timestamp, encrypted using the Client-Principal's TGS Session Key.
Upon receiving the messages, the Client-Principal's TGS retrieves TGS Session Key out of TGT. It decrypts the Client-Principal's TGT using the Client-Principal's TGS secret key and therefore the SP now has the Client-Principal's TGS Session Key.
- Client-To-Server Ticket - which includes the client ID, Client-Principal network address, validity period and Client-Principal's TGS Session Key encrypted using the Service's TGS Session Key.
- Client-To-Server Session Key encrypted with the Client-Principal's TGS Session Key.
Client Service Request#Upon receiving Client-To-Server Ticket and Client-To-Server Session Key from the TGS, the Client-Principal has enough information to authenticate itself to the Service Provider. The Client-Principal connects to the SP and sends the following two messages:
- Client-To-Server Ticket - encrypted using SP's TGS Session Key.
- Authenticator Plus 1 - which includes the Client-Principal ID, timestamp and is encrypted using Client-To-Server Session Key.
The SP decrypts the ticket using SP's TGS Session Key secret key to retrieve the Client-To-Server Session Key. Using the sessions key, SS decrypts the Authenticator and sends the following message to the Client-Principal to confirm its true identity and willingness to serve the Client-Principal:
- SP Confirmation - Which includes the timestamp found in Client-Principal's Authenticator Plus 1, encrypted using the Client-To-Server Session Key.
Identity Provider#The Kerberos 5 authentication back end does not contain a Kerberos Database 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 Kerberos Principal Name UPN. The identity provider configuration should contain an entry to specify this UPN.
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. 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:
- Apple Directory
- Authentication Protocol
- Best Practices for LDAP Security
- Client-To-Server Session Key
- Client-To-Server Ticket
- Generic Security Service Application Program Interface
- Identity Broker
- Initiate Kerberos
- JSON Identity Suite
- Kerberos Database
- Kerberos Delegation
- Kerberos Error Codes
- Kerberos Pre-Authentication
- Kerberos Principal
- Kerberos Realm
- Kerberos SSP
- Kerberos Tools
- 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
- Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
- Security Support Provider
- Security Support Provider Interface
- Service Provider
- Shared Secret
- Simple and Protected GSSAPI Negotiation Mechanism
- The Kerberos Version 5 GSS-API Mechanism
- The Simple Public-Key GSS-API Mechanism
- Ticket Granting Ticket
- Troubleshooting Kerberos
- Troubleshooting Kerberos SPN
- User-Account-Control Attribute Values
- Verify DNS Records
- Windows Integrated Authentication
[#1] From: http://en.wikipedia.org/wiki/Kerberos_(protocol)