This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Kerberos
Kerberos

Version management

Difference between version and

At line 1 added 132 lines
!!!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.
[{$pagename}] designers aimed primarily at a [client-server] model, and it provides [mutual Authentication].
[{$pagename}] [protocol] messages [replay attack]s.
[{$pagename}] uses [Symmetric Key Cryptography] and requires a trusted third party. Extensions to [{$pagename}] 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|Obsolete] 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]
!! [{$pagename}] [Authentication] and Access to a [Resource]
[{$pagename}] [Authentication] and Access to a [Resource] is performed in various Exchanges:
* [AS Exchange]
* [TGS Exchange]
* [Client-Server Exchange]
!! Software
[{$pagename}] is also a "free" and [Open Source] software published by [Massachusetts Institute of Technology] ([MIT]) that implements this [protocol].
[{$pagename}] is used within [Microsoft Active Directory] as the preferred [Authentication] [Protocol].
!! Kerberos is Legacy [Protocol]
[{$pagename}] was created to accomplish [authorization] when no-one used a [secure network connections|Secure connection|Transport-layer Security Mechanism]. Today, everyone should be using a [secure connections].
[{$pagename}] was created to keep from passing username and clear-text passwords over the network. Today, everyone should be using a [secure connection|Transport-layer Security Mechanism].
[{$pagename}] is complex to set-up and maintain.
[{$pagename}] 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 [{$pagename}] does not work well with Modern [REST] applicaitons and [Authentication Methods]:
* [Security Assertion Markup Language] ([SAML])
* [OAuth 2.0]
** [OpenID Connect]
** [User-Managed Access]
!! Advantages and Disadvantages of [{$pagename}]
! Advantages of [{$pagename}]
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 [{$pagename}]
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 [{$pagename}]:
* 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.
* [{$pagename}] 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.
* [{$pagename}] 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] - [{$pagename}] 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 using[Symmetric 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.
* [{$pagename}] 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.
!! [{$pagename}] Information
* [{$pagename}] uses [port] 88 by default.
* We will refer to [{$pagename}] 5 unless otherwise noted.
* [{$pagename}] makes extensive use of [Symmetric Key Cryptography].
!! Network Security
[{$pagename}] generally distrusts the security of the underlying network. [{$pagename}] 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|http://web.mit.edu/kerberos/advisories/ |target='_blank']
The list of [Kerberos Security Advisories|http://web.mit.edu/kerberos/advisories/ |target='_blank']
!! [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 [{$pagename}] 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 [{$pagename}] [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|Anomaly]
Kerberos __CANNOT__ distinguish between 'Account Disabled', 'Account Locked out' and 'Account Expired'. They share the same [{$pagename}] error code 18. [LDAP] can distinguish them by providing multiple return codes.
!! [{$pagename}] 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|Simple Password] - 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 [{$pagename}] V5 session.
[{$pagename}] with extensions can provide some limited additional information.
[Microsoft Active Directory] supports:
* [GSSAPI] (Kerberos)
* GSS-[SPNEGO] (Windows [negotiate|Negotiate SSP] [authentication] which selects between [Kerberos] and [NTLM]),
* [Digest|Digest SSP] 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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [From: http://en.wikipedia.org/wiki/Kerberos_(protocol)|http://en.wikipedia.org/wiki/Kerberos_%28protocol%29]
* [#2] - [Kerberos: The Network Authentication Protocol|http://web.mit.edu/Kerberos/|target='_blank'] - based on information obtained 2018-01-07-
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop