Most information systems are constructed with multiple systems, resources and data that users will require access to. Each necessitates access control which entails ongoing renewal of passwords, although users will often use the same password rather than creating numerous codes, or write them down to keep track of the information which can compromise security.
Single sign-on handles this problem by requiring users to authenticate once to a single authority, then allowing them access to all other protected systems and resources without having to re-authenticate. This type of set-up has a couple of disadvantages:
- It’s expensive.
- If an unauthorized individual is able to gain access, that person then has open access to all system resources.
Passwords should never be stored or sent in clear-text. Systems such as Kerberos, NetSP / Krypto-Knight can be used to implement single sign-on.
Kerberos
Kerberos is the preferred single sign-on authentication system in many medium and large information systems. It’s designed to centralize the authentication information for any user or entity requesting access to resources.
Kerberos uses symmetric key cryptography and assigns tickets to the entity that requests access. When a user attempts to access the local system, a local agent or process dispatches an authentication attempt to the Kerberos ticket-granting server (TGS). The TGS delivers the encrypted credentials for the user attempting to access the system. The local agent decodes the credentials using the user-supplied password. If the right password has been delivered, the user is validated and assigned authentication tickets, allowing access to other Kerberos-authenticated services.
A user is also assigned a set of cipher keys that can be used to encrypt all data sessions. All services and users in the system are given tickets from the TGS and are authenticated by an authentication server (AS). This provides a single source of authority to track and authenticate users. Realms can trust one another, which helps ensure the scalability of Kerberos systems.
Kerberos is applied by a Key Distribution Center (KDC) holding the data that allows Kerberos clients to authenticate. The information is stored in a database that permits single sign-on. The KDC’s database operates differently than other databases. The KDC and the client establish trust relationships using public key cryptography. Through the trust relationship, KDC is able to verify which services a host and user can access.
Kerberos addresses the sensitivity and integrity of information, but not its availability. All the secret keys are logged on the TGS and authentication is performed on Kerberos TGS and the authentication servers. A client’s secret key and session keys are temporarily stored on the client workstation as well.
There is risk of exposure to harmful agents such as malicious code, and because passwords are used to access Kerberos to request service, an unauthorized user could try to decode the password to forge access.
Secure European System and Applications in a Multivendor Environment (SESAME)
The Secure European System and Applications in a Multivendor Environment (SESAME) project was formed to counteract weaknesses in Kerberos system.
SESAME uses public key cryptography to deliver secret keys as well as MD5 and CRC32 one-way hash functions and two certificates or tickets. One certificate verifies authentication, as in Kerberos, and the other certificate monitors the access privileges assigned to a client.
SESAME is similar to Kerberos in that it has inherent weaknesses. SESAME authenticates using only a portion of a message, not the entire message. It is also vulnerable to password guessing.
KryptoKnight and NetSP
KryptoKnight, a system developed by IBM, provides single sign-on, key distribution, and authentication services for computers with widely varying functions and capabilities. KryptoKnight employs a trusted Key Distribution Center (KDC) that logs the secret key of each party.
The difference in functionality between Kerberos and KryptoKnight is the user-to-user relationship among the parties and the KDC, instead of the standard server/client relationship. To apply single sign-on, the KDC has a party’s secret key that is a password hash. Introductory communication from the party to the KDC is the user’s name and a value, which is a function of a nonce, a randomly-generated one-time use authenticator, and the password. The KDC verifies the user and allocates a ticket encrypted with the user’s secret key. The ticket is then decoded by the user and applied for authentication to access services from other servers on the system.
NetSP is based on KryptoKnight. It uses a workstation as an authentication server.