Aug 29 ’13
Cross-Platform Security: How Kerberos Works With LDAP
As computers become more interconnected, administrators are often charged with providing security for other platforms across various types of network. Providing effective security across these connections is a challenge.
This series examines common problems and approaches to cross-platform security, some basic underlying principles, and provides recommendations to make this security easy and effective.
In the first article, which appeared in the Winter issue of Enterprise Tech Journal (available at http://entsys.me/u4eqv), we discussed some of the options and obstacles to implementing cross-platform information security. We provided some simplifying guidelines and suggested Lightweight Directory Access Protocol (LDAP) and Kerberos as part of any optimum solution. The second article, which appeared in the May issue of Enterprise Tech Journal (available at http://entsys.me/vwfm5), explained what LDAP is and how it contributes to effective cross-platform security.
Here we describe how Kerberos works with LDAP to prove users’ identities and provide encryption over the network automatically. We will show you two risks it protects against and how it works. Note that in this series of articles, we treat the mainframe as just another server or platform in the network.
The Value of Kerberos
To understand the value of Kerberos, it helps to understand the first risk—sniffer programs. Imagine our example from the previous articles of a programmer’s workbench, a Windows desktop computer that connects through a Local Area Network (LAN) to TSO and CICS on an IBM mainframe. LANs rely on a special circuit board called a Network Interface Card (NIC) that’s added to each Windows computer in order to connect that computer to the network. Most of the time, each NIC ignores all messages on the network except ones that come from, or are addressed to, the NIC itself.
However, a sniffer program running on the desktop computer gives the NIC an instruction, telling it to show every message on the network. The sniffer program can then read every message on the network or network segment, including sign-on requests to the mainframe containing userids and passwords. A hacker running a sniffer program could then use this information to sign on to the mainframe, assuming the identity of that user.
You might think that encrypting the sign-on request could provide protection against sniffer programs, but it doesn’t. The sniffer doesn’t have to decrypt the sign-on request; it can instead record it and then play it back (sending the recording to the mainframe).
When the mainframe receives the recording of the encrypted sign-on request, it decrypts it. (Of course, at this point, the mainframe is expecting sign-on requests it receives to be encrypted, just as the original copy of the sign-on request needed to be decrypted.)
The mainframe then uses the sign-on request to sign on the user. The hacker running the sniffer program would then be signed on as that user. This recording and playback is called a “playback attack.” This is the source of the adage that the greatest security risk to mainframes can be Windows.
A second, related risk is that once the user is signed on and connected to whatever server he wants to work with, his data flows unencrypted, not only over the LAN, but also over any other networks involved.
How Kerberos Protects Against These Attacks: An Example
Kerberos can protect against both these types of risk. It protects against sniffer attacks by adding a timestamp to the sign-on request, so it can detect such playback attacks. To see how it works, imagine a user named Charlie using a Windows computer to sign on to the mainframe. Imagine further three computers:
• The client computer used to sign on (the Windows desktop computer connected to the LAN in our example)
• The target computer where the user wants to connect (the mainframe in our example or possibly a UNIX server with an Oracle database)
• The Kerberos server computer, which verifies a user’s identity and produces a “session ticket” that is proof of who that user is. (Note that this could be the Windows Active Directory server managing the LAN.)
The Kerberos server has a database of clients and target servers, assigning a unique encryption key to each. Each encryption key is known only to Kerberos and to the client or server with which it corresponds. To keep things simple in our example, we will call the encryption key that’s unique to Charlie, the RED encryption key. Let’s call the encryption key that’s unique to the target server, the GREEN key. In real life, these wouldn’t be colors, but rather, long, random numbers.
There’s a third encryption key involved that’s used only one time for communication between Charlie’s computer and the Kerberos server. It’s used once and then discarded. We will call it the Charlie-Kerberos-One-Time-Only key.
The Kerberos server can accept a request from a user at a client computer to sign on to the target computer. It verifies the user’s identity by means of the unique encryption key that’s known only to that user. Kerberos then sends back to the user a “session ticket,” or proof of the user’s identity. The client computer then sends the session ticket to the target computer as his sign-on request. The target computer uses the session ticket to sign on the user.
Suppose Charlie, sitting at his Windows computer, wants to sign on to the mainframe. Charlie types his userid and password into the Windows computer. This isn’t the password used by mainframe security software (RACF, ACF2 or Top Secret); it’s his Kerberos password. A small piece of software running on Charlie’s desktop does some special mathematics on Charlie’s Kerberos password to produce the RED encryption key that’s unique to Charlie.
Software on Charlie’s computer now sends just his userid to the Kerberos server. The Kerberos server looks up Charlie’s userid in its database, sees that his unique encryption key is the RED key and then invents a random number that will be used as the Charlie-Kerberos-One-Time-Only encryption key. Kerberos puts together a special message and sends it to Charlie’s computer. The message is encrypted with the RED encryption key, so only Charlie’s computer can decrypt it. The message includes the Charlie-Kerberos-One-Time-Only key, Charlie’s userid and network address and other information.
Charlie’s computer uses the RED key to decrypt the special message. Now Charlie’s computer knows the Charlie-Kerberos-One-Time-Only encryption key and can safely erase the RED key from its memory.
Charlie’s computer now constructs his request for a session ticket and sends it to the Kerberos server. This request contains Charlie’s userid, the name of the target computer Charlie wants to sign on to and the current time and date, along with the original special message.
When Charlie’s computer creates the request for a session ticket, it includes yet a fourth encryption key. This is a long, random number that will be used to encrypt and decrypt all messages between Charlie’s computer and the target computer for this one sign-on session. This encryption key is called the session key. For our example of this very random, very long number, we will use 1234. Much of the request is encrypted with the Charlie-Kerberos-One-Time-Only encryption key.
The Kerberos server uses the Charlie-Kerberos-One-Time-Only key to decrypt the request. If it decrypts properly, the Kerberos server concludes this must have come from Charlie, since only he could have produced the encryption key used to encrypt the request. (Charlie’s computer knew this key was the Charlie-Kerberos-One-Time-Only key, which it learned from decrypting the special message.)
The Kerberos server then checks the timestamp to make sure it’s within a window of say 10 minutes of the current time. If it isn’t, the Kerberos server rejects the request. Otherwise, the server then saves a copy of the request to protect against playback attacks. (If the server receives an identical request within the next 10 minutes, it will then know the second request is a playback attack.)
The Kerberos server now creates the session ticket, which Charlie’s computer will use as a sign-on request to the target computer. The Kerberos server received the session key (1234) from Charlie’s computer, along with the rest of the request for a session ticket. Kerberos puts the session key into the session ticket.
The Kerberos server now encrypts the session ticket with the GREEN key (unique to the target server). The Kerberos server sends the session ticket back to Charlie’s desktop computer. His computer decrypts the message with the Charlie-Kerberos-One-Time-Only key. Charlie’s computer then sends the session ticket to the target computer, still encrypted with the GREEN key. Charlie’s computer sends, along with the session ticket, a message that says “This is Charlie.” This message is encrypted with the session key (1234).
When the mainframe (target) computer receives the session ticket, the target decrypts it with the GREEN key. Now the target computer knows the session key (1234) and uses it to decrypt the message “This is Charlie.” The target computer concludes that if the session ticket decrypts properly with the GREEN key, then it must come from the Kerberos server, since the Kerberos server is the only other one who knows the GREEN key. So the target computer now trusts the session key (1234), since it came from the trusted Kerberos server.
If the “This is Charlie.” message decrypts properly using the session key, then the target computer trusts it. Since the target computer trusts the session key, and the session key decrypts the message that this is Charlie, the target computer accepts this as Charlie’s sign-on. The target computer also verifies the timestamp and other values.
You might think all this processing would use large amounts of CPU time. Microsoft found that Kerberos used fewer resources and was faster than the protocol Windows previously used.
Addressing the Second Risk
Now suppose that in addition to providing reliable verification of a user’s identity, you wanted Kerberos to provide encryption for all communication between the client computer and the target computer. This addresses the second risk and is easy with Kerberos.
Both Charlie’s computer and the target computer now know the session key (1234). They can use it to encrypt and decrypt all messages between them. When their session is over, they discard the session key.
You may be wondering how easy it is to install Kerberos. With Windows, it’s already installed as part of Active Directory. For mainframes, Kerberos is installed with z/OS. It works well with RACF, ACF2 and Top Secret, using the LDAP server that also comes with z/OS to synchronize passwords. With UNIX, you can add Kerberos easily for free.
The concluding article in this series will examine the important questions and steps to address when implementing cross-platform security.