Kerberos

PrivX vs Kerberos

At a system level Kerberos and PrivX solve different, albeit related problems that share a similar space. In the first instance you could be forgiven for thinking that they solve identical problems as both Kerberos tickets and Ephemeral Public Key Certificates provide short term statements that grant access to requested target resources.

However in many a case this is where the similarities end, PrivX uses a variety of user authentication mechanisms between User-to-PrivX and PrivX-to-Server with Kerberos potentially playing its part in the former (SSO into PrivX UI), so why would you switch to the use of PrivX and the use of its ephemeral certificates?

Firstly, Kerberos does a great job for mutual End-to-End Client-Server authentication within a managed domain where clocks can be assumed to be synchronized, however in today’s distributed, heterogeneous, and BYOD environments Kerberos really begins to show its age and thus its limitations as authentication requests will simply fail if Kerberos server and target hosts fall out of sync. This scenario is now ever more present because of modern day working practices, to further complicate matters Kerberos requires user accounts and services to have a trusted relationship to the Kerberos token server requiring additional configuration and administration overheads per host. Where hosts are located in isolated or remote networks (e.g. separate domains for test, pre-production and/or production environments) this may not be possible without adding even more complexity.

Where ownership of data or keys is a concern, Kerberos acts as a trusted third party which means it requires plain text access to all symmetric keys in its use. PrivX and Ephemeral Public Key Certificates in general, do not require such external trusted parties to have access to keys therefore meaning you and the services you control retain 100% ownership.

IAAA Security Framework coverage (Identification, Authentication, Authorization, Accountability)

PrivX: Full coverage

• Identification (who are you?): Username via local or directory service integration (e.g. AD) SSO
capable Integration with Kerberos via LDAP also available

• Authentication (prove who you are):
o User-to-PrivX (client side: Password + native MFA, Kerberos Tokens, SSH public keys
o PrivX-to-Server (server side): Password-less Ephemeral Certificates, SSH public keys, Vaulted
passwords

• Authorization (what are you allowed to access?): Zero Trust Role Based Access Control (ZTRBAC) + Contextual Access parameters (day, time and IP restrictions)

• Accountability (otherwise known as auditing): Audit trails, session recordings, mapping of shared account usage to individual ID’s

Kerberos: Covers Identification & Authentication only

• Identification (who are you?): Username via directory service integration (e.g. AD)

• Authentication (prove who you are): Client/Server side: Kerberos Tokens

• Authorization (what are you allowed to access?): None, Kerberos presents the entitlement/user
identified to the target host but does not handle authorization itself. This is left to server-side
mechanisms which can be centrally managed by 3rd party integrations but generally still require
per host configuration.

• Accountability (otherwise known as auditing): Limited to none, Kerberos server (KDC) logs all the granted and denied tickets however KDC is not aware if the requestor used the ticket i.e.
authenticated to the target resource.

Kerberos Summary:

• Centralized authentication
• SSO capable
• Lacks gated access control required for modern day security needs
• Lacks meaningful logging capabilities for security forensics
• Lacks authorization capabilities meaning granted access to end resource is often managed on a
per target basis
• Usage and visibility of shared accounts is limited as Kerberos is unable to map their use back to
specific entitlements/users