HP 635n Practical IPsec Deployment for Printing and Imaging Devices - Page 131

exist in the same domain as Jetdirect. Time synchronization in Kerberos is also very important to maintain. The protocol relies on time synchronization to reduce the opportunities of certain types of attacks. Kerberos Basics Kerberos is primarily used to provide authentication within a realm. In an AD environment, you'll typically see Kerberos used to authenticate and then LDAP used to authorize. In other words, a principal named Tom "logs into the directory" via Kerberos which verifies that "Tom" knows Tom's password and that Tom is a user object in the AD and that the KDC knows Tom's password too. Once successfully authenticated, LDAP can be used to check group membership for Tom; is Tom a member of Domain Admins for instance? Tom's group membership allows AD to determine authorization to perform certain functions. For IPsec, we won't worry about LDAP authorization. What we care about is using Kerberos to authenticate IPsec endpoints. Throughout this section, we will be referring to a computer whose principal name is "Vista" and an MFP whose principal name is "Jetdirect" in a realm called "EXAMPLE.INTERNAL" (which is the domain example.internal). Although the principal name is Vista, Kerberos authentication for IPsec works with a variety of operating systems, XP and 2003 included. For Kerberos authentication to begin to get off the ground, two items are required for any principal • The principal must be a user or computer object in the AD • The principal must know their password and it must match the KDC's password database for that principal In order to verify these two items, the principal will communicate with a service on the KDC called the Authentication Service. The principal will indicate who they are and what realm they belong to. The principal will also encrypt a timestamp using a key derived from the principal's password. This last step is required to prevent certain types of attacks against the KDC and the Authentication Service in particular. Based upon the previous description, before beginning to use Kerberos, a principal needs to know a few things: • The principal needs to know what name the KDC knows it by • The principal needs to know what realm it belongs to • The principal needs to know the network address of the Authentication Service • The principal needs to know he current time - via a time server or the principal's clock both of which have to be synchronized to the clock that the KDC is using. • The principal obviously needs to know its password Of course the KDC needs to know about the principal name and its corresponding password too. Okay, let's assume that the principal knows everything it needs to know and so does the KDC. The principal contacts the Authentication Server of the KDC and provides its credentials which the KDC internally proves are valid. Now what? All that the principal has done is told the KDC who it is and the KDC has said "Yep, that's who you are!" To use a previous analogy, this is like a person who owns a driver's license from the DMV walking to the DMV office and presenting their license and saying "I'm driver Tom" and the DMV, who issued the drivers license says "Yep, that's who your are!". This doesn't really help us too much. One of the key items for Kerberos to solve is "How do authenticated principals prove their authentication to each other?" Proving it to the KDC for valid principals isn't a problem. Proving it to other valid principals needs more work. Let's go into an analogy to explain how Kerberos solves this problem. 131