Kerberos
From CCGB
Kerberos is a security and authentication system used to verify your identity and allow you access to services at BX. It's what accepts your password when you log in. The best place to start with understanding Kerberos is to read the official User's Guide. The most relevant sections are the Introduction and the Kerberos V5 Tutorial, up to (but not including) the section on Kerberos V5 Applications (since we don't use Kerberized FTP/RCP/Rlogin/etc.).
There are a few things specific to BX to be aware of.
Contents |
Tickets
You'll automatically obtain Kerberos Tickets (and AFS Tokens, but this is covered on the AFS page) when you log in to your workstation. You can see this by opening up a Terminal and running klist:
% klist -f
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: nate@BX.PSU.EDU
Valid Starting Expires Service Principal
05/30/07 12:25:06 05/31/07 12:25:06 krbtgt/BX.PSU.EDU@BX.PSU.EDU
renew until 06/06/07 12:25:06, FPRIA
05/30/07 12:25:06 05/31/07 12:25:06 afs@BX.PSU.EDU
renew until 06/06/07 12:25:06, FPRAT
As you can see from the flags (refer to User's Guide or man klist), this ticket is forwardable and renewable. This means that it can be used to authenticate me to any other system at BX without a password, and I can use kinit -R to renew the ticket without a password. It expires 24 hours after it was issued, and can be renewed for 7 days. After 7 days, I will need to enter my password again to get a new ticket.
Most of the time, you won't need to worry about acquiring or renewing tickets. Typing your password in to the screen saver will get you new tickets good for another 24 hours (and renewable for another 7 days).
Why??
Feel free to skip this if you aren't interested in WHY we're moving to Kerberos authentication.
Password Hashes
BX has previously used NIS for authentication. NIS has been around for a very long time, and was conceived before network security was a high priority. It allows any client on the local network to read any user's encrypted password (aka password hash), for example:
% ypmatch nate passwd nate:ZZFlkx2B.NdVo:2048:2048:Nate Coraor,507 Wartik,865-8808,,:/home/nate:/bin/bash
With a decently fast computer, it would not take long to crack that password. Kerberos stores its passwords so they are not publicly readable, and as such it is not susceptible to password cracking attempts.
No Central Authority
With Kerberos, you are granted a ticket when you authenticate. These tickets allow other systems to confirm that you are who you say you are.
For example, let's say I'm logged in to a workstation (wynton) and I want to access my home directory on a server (coltrane). coltrane trusts wynton to verify that I am a user named nate. It gives access to the files in nate's home directory to nate on wynton because of this trust. But what if wynton is compromised? Worse, what if someone writes their own NFS client claiming that they are nate. coltrane happily continues serving files to "nate" on wynton without knowing it's been duped.
Kerberos tickets solve this problem. They're distributed by the server (coltrane) to a specific user on a client. When I want to access my home directory on coltrane, I first acquire Kerberos tickets from coltrane. As long as I have those tickets, coltrane can safely believe that the user nate on wynton is indeed authorized to access nate's home directory because it verified my identity itself. This removes the level of host-based trust and moves to user-based trust, which is a key point of secure computing.
Secure Network Filesystem
In order to use AFS, switching from NIS to Kerberos was a requirement (AFS depends on Kerberos to verify your identity).
