Most of us have heard of the Kerberos network authentication protocol, but what is it? What is its roll in an identity and access management (IAM) program, and how can it be leveraged for access control initiatives like single sign-on (SSO) and custom application authentication?
Designed to provide strong authentication for client/server applications by using secret-key cryptography, Kerberos defines a typical key-exchange mechanism; it's a way of proving an identity to a system (the Kerberos server) and having that system then authenticate the identity to other systems for the duration of the session. It is well suited for authentication on physically insecure networks.
Features of Kerberos
Kerberos offers several important features, such as providing a secure, reliable means of authentication, authenticating to multiple applications in a way that is transparent to the user, and accommodating any organization by way of a scalability model. It is a mature and industry-accepted protocol that can support cryptography as well.
These features entail more robust controls to prevent eavesdropping and malicious attacks on the network, a friendlier end-user experience, and the ability to expand use of the protocol to a broad spectrum of applications. It also prevents unauthorized reading of communications through encryption.
Each application that is setup to use Kerberos trusts the Kerberos server to authenticate the user, so the user isn't asked for a username and password on each application. Kerberos provides secure communication between two parties by manufacturing secret keys on an open network and providing a mechanism for those keys to be securely communicated to the appropriate parties.
Because single sign-on relies on a centralized and trusted authentication mechanism, Kerberos is a natural fit. A well-designed implementation should have a means of confidently authenticating users to the Kerberos server and communic...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
ating those credentials securely to all applications participating in the Kerberos implementation.
Implementing single sign-on with Kerberos across core applications and intranet sites in an enterprise can also offer huge cost savings in several ways:
- Custom applications can leverage the enterprise Kerberos single sign-on system to authenticate users, reducing development time.
- Password-reset requests will drop dramatically if users are only required to remember one set of credentials.
- Access management is simplified by providing a single point to terminate access. (This means fewer hours required to manage the account through its life cycle.)
- Kerberos is a non-proprietary technology, so it supports interoperability of multiple vendors' products, from Apple Inc. to IBM.
Businesses tend to have several enterprise-wide applications that fulfill distinct business needs. With their own processes, GUIs, databases, business abstraction layers, Web servers, etc., the structures of these applications may inhibit them from leveraging existing authentication mechanisms like Active Directory or TopSecret. Implementing Kerberos single sign-on across these various applications means that users who access more than one of them can now authenticate once and aren't asked for separate credentials for each application.
Kerberos: Drawbacks and limitations
There are limitations to Kerberos that should be considered and understood before implementation. For instance, Kerberos does not provide authorization or accounting, although it is possible for applications to use their secret keys to perform those functions securely.
There are also concerns about centralizing all of the application passwords on one system. If an attacker gains root access to a Kerberos server, he or she will have access to the database of encrypted passwords of the applications leveraging Kerberos. If the Kerberos server is compromised, the attacker could also modify the Kerberos software and configuration files to make the system perform authentications that should not otherwise be successful.
There are also two different distributions and versions of Kerberos available: Versions 4 and 5. Version 5 (v5) is the newest, introduced in 1995. There are several distributions of it, including a freeware version from MIT as well as a commercially available distribution from the Open Group called OSF DCE (Distributed Computing Environment) Security.
Be aware that v4 and v5 are completely different protocols and are not compatible. Different distributions don't always implement together well either. There may be tweaks and customization required if the company chooses to run multiple distributions in the same organization. I strongly recommend against this because the support issues involved may be problematic.
Where to use Kerberos
Kerberos should be considered if an organization is looking for a mature means of authenticating users to multiple applications across a variety of technologies.
It is also worth considering if a company has a Web presence that directs end users to a portal with several different applications providing underlying functionality. A bank is a great example of this: users could have a combination of a checking account, a savings account, an IRA or a mortgage from the same bank. It would be a much better user experience to have a single set of credentials for conducting business than to log in to each of these accounts separately.
Kerberos is intended to help enable centralized authentication to simplify the user experience and the system administrators' account management process. It can be a useful technology and is worth examining by any organization exploring single sign-on systems.
About the author:
David Griffeth is the Vice President of Business Line Integration and Reporting at RBS Citizens Bank, a financial institution that is one of the 10 largest commercial banking companies in the United States ranked by assets and deposits. As part of his responsibilities, David manages the Enterprise Identity and Access Management group and is charged with supporting the bank's growth model while maintaining compliance with several regulatory bodies. Prior to his current position, David consulted on major information risk management projects with large companies such as Fidelity Investments and CIGNA. David earned a bachelor's degree in computer science from Framingham State College and holds several certifications including CISSP and CISA.
