Basic concepts
The Kerberos authentication system is built on top of tickets (sometimes also called credentials). The core idea behind Kerberos is that you don't hand out your account password to each service you want to use. Instead, you keep all of your tickets on your local system and only show each service a ticket specifically for that service, one that can't be used for any other purpose.
When you first start using your system (when you log in to Kerberos for Windows or Kerberos for Macintosh, or when you run kinit on a UNIX system), you use your password to get a master ticket called a TGT (ticket-granting ticket). This master ticket expires in 25 hours, after which you will need to enter your password again to get another one.
Whenever you go to a service that uses Kerberos, you show that master ticket to the Kerberos server and get a ticket specifically for that service. Then, you show the ticket just for that service to the service to prove who you are. All of those tickets are stored on your local system in what is called a ticket cache.
Using your password is like using a birth certificate, citizenship, or immigration papers to prove who you are. It's annoying to have to type, not well-protected against forgery, and contains all the information required to steal your identity. You don't want to present those papers every time someone needs to identify you. Instead, you use those papers to get an identification card (a passport, a driver's license, a state ID card, or a Stanford ID card). That ID card is like a Kerberos TGT. It is still very powerful, but it's more convenient and has better anti-forgery protection. You can then use that ID card to prove your identity and get other identifiers intended for specific situations: a movie ticket or a pre-paid phone card, for example. Single-purpose identifiers like movie tickets are similar to Kerberos service tickets.
The obvious advantage of this system is that each service gets only the ticket for that service. You don't hand over your ID card, and therefore the service doesn't have an opportunity to grab your ID card and use it to impersonate you. Used as designed, Kerberos not only protects against someone trying to access your mail or your files directly. It also protects against someone pretending to be your mail server to steal your identity and use it somewhere else.
Kerberos and WebAuth
WebAuth is a Kerberos authentication system for web applications. Most most web applications don't understand Kerberos directly. WebAuth handles the Kerberos authentication and translates the results into what web applications expect.
By default, WebAuth also asks you for your password the first time you use it each day. It then stores your Kerberos credentials in a browser cookie and uses them to get new authentication tickets, very similar to the regular Kerberos ticket cache, for each authenticated web site you visit. All of those tickets are stored as cookies in your browser. WebAuth works this way by default because it works with all browsers and doesn't require any software be installed on your local system.
If you are using a Mac OS X or UNIX system, or are using a Windows system that is part of the Active Directory domain (some staff but almost no students currently), and have your computer set up with Kereros software, you can use WebAuth like any other regular Kerberos application with some minor browser configuration. The next time you get the WebAuth login screen, click on the Advanced Settings link and read the instructions. If you're comfortable doing that configuration, you can then authenticate to WebAuth using a regular Kerberos ticket. This means that you won't have to type your password into WebAuth and you won't have to send your password off your local computer.
Services without native Kerberos support
Unfortunately, some services and some clients don't support Kerberos directly. For example, many mail clients don't understand Kerberos and only understand passwords. When using those services or those clients, you may have to enter your password, which is then sent to the server. The server uses your password to get a master ticket for you and verifies that master ticket is correct.
This works, but it's not ideal. It's like handing over your birth certificate and social security number to every service you want to use, rather than just showing your driver's license or a ticket specifically for that service. Almost all the services are trustworthy, but doing this is always a risk. We try to minimize the number of services that require passwords and try to use real Kerberos tickets every place we can.
Question any application that asks for your password. Asking for a password is not the best or most secure way to use Kerberos. Ideally, you should only have to type your password into your personal computer, once, at the beginning of the day. Look for software that supports Kerberos and you save time typing your password and make your account more secure at the same time. Be particularly suspicious of any web site other than WebLogin (or Stanford.You when changing your password) that asks you for your account password.
Stanford staff will notice one unfortunate exception: Kronos (for time and leave reporting) will force you to enter your SUNet ID and password into its web interface. Limitations in the vendor application underlying Kronos have to date prevented it from using WebAuth correctly.
Further reading
For more information about Kerberos, see the MIT Kerberos web site, particularly the collection of papers about Kerberos, and the Kerberos Consortium web site.
