But today we're talking about Kerberos. So we'll do a very quick overview of what Kerberos is, how it works, the internal infrastructure, the new features we're adding to Kerberos and Panther, and how you can add Kerberos to your application. We will do a question and answer period at the end, and we'll want to know whether or not you're a user or developer. So what is Kerberos? It's a secure network authentication system. One of the things that is worthwhile to understand that there is a difference between authentication and authorization. We have an authorization lab down on the first floor. I encourage you that if you're interested in doing authorization or rights management on Mac OS X, that you go check out the lab and talk to the folks there.

We've got a really good auth system on the Mac. It proves, Kerberos proves who you are, and it uses a trusted third party security model to do this. Who uses Kuberos? Well, certainly the government does and education. Large corporations are starting to use it. And we built a lot of it in a Mac OS X. It's in Windows, of course, but I don't really care too much about that.

The reason that they use it is because it factors the security problem. It is consistent with the central authentication goals. It provides single sign-on. It's ubiquitous. across a variety of platforms, including Xbox. When they talk about having different realms on Xbox, we're not talking about EverQuest. And it's time tested, the source code's freely available. So to talk about Kerberos for the Macintosh, Marshall Vale.

Thank you, Craig. Good morning, all. My name is Marshall Vail. I am the project manager of Kerberos development at MIT. I have a lot to talk about, so let's get started. First, Kerberos was developed as part of Project Athena in the early 1980s. Athena was a project started by MIT, DEC, and IBM to create a ubiquitous computing infrastructure for an academic environment. Of course, when you turn in a paper as a student, you want to prove who you are. And thus, Kerberos was developed to solve network authentication. Kerberos 5 became an IETF-proposed standard in 1993, and it's become very popular in a wide variety of markets, including the corporate market, in the last few years, thanks to Microsoft's use of it as the native authentication method in Windows 2000 and later. And as has been announced this week, Apple has been using Kerberos as the single sign-on solution for Panther and Mac OS X going forward.

There are two forms of Kerberos protocols in common use. The first is Kerberos version 4. It was actually the original version. It's no longer being developed, but still in use at many other sites. You may want to know what happened to the other versions, but they never really quite got out of the lab. The current version is Kerberos version 5. It was designed to solve many of the security deficiencies and other problems in Kerberos 4.

Now let's take a look at some of the Kerberos terms so we have an understanding of what we're talking about. First is a realm. The realm is an administrative unit protected by a KDC, or key distribution center. A ticket is the base authentication token in Kerberos. Different types of tickets exist for different purposes. They have a finite lifetime as they expire. They're also known as credentials, and I may use tickets and credentials interchangeably.

So let's take a look at specific types of tickets. One is a ticket granting ticket, or a TGT. It's the initial ticket that grants permission to get service tickets. You can sort of think of it as your all amusement park pass. The service ticket is a ticket that authenticates a user to a particular service, such as FTP, email, whatnot.

I'll take a look at a couple of the terms a little more in depth. A realm looks similar to an internet domain to a user. For example, at MIT, we have athena.mit.eu. It defines your namespace. All your user names have to avoid collision within that realm. Unlike DNS, which causes some consternation with folks, a Kerberos realm is, in fact, case-sensitive. You can exchange keys between different realms, and a realm can support any combination of v4 and v5. An organizational recommendation is to have as few realms as possible, and for those folks who may be setting up Kerbos for the first time, it's not best to do it along political boundaries. You should at best have one. Your users will be thankful for it. Now, a ticket-granting ticket is also called an initial ticket. It's the first ticket you get. It proves that the client is allowed to get tickets for other particular services. It acts as a substitute for a password, and it's the mechanism by which single sign-on behavior for the user is achieved.

Now, as I mentioned, the tickets are only valid for a limited period of time, but TGTs can in fact be renewed. So let's look at a simple TGT request exchange. First, the client sends a TGT request to the KDC. The KDC returns a TTT and a session key to the client encrypted in the client's key.

Then the client uses a one-way hash of the password, this is where the user sits and types their password, to extract the TGT. Now, at this point, you can see that the password has not actually traveled over the network. Now, I've done a bit of a simplification here. You actually want to do something else called pre-authentication to make sure the exchange is secure, but for the purposes of this session, making it go quicker. So what's it look like to a user? Well, in this example, if you can see it, the user has retrieved two TGTs, one for V4 and one for V5. Most of the time, users don't actually go in and need to investigate the tickets, but people wonder what they look like. And unfortunately, we don't have any whizzy OpenGL demos of tickets flying around.

Now, a service ticket. Service tickets are tickets that clients use to access a particular service, as I said. It contains a session key that is shared between the client and the server and can be used to encrypt data exchanges. It also expires but is not renewable. But that's not actually that important. TTTs take care of that for you. So let's take a look at a service ticket exchange. First, the client presents the TTT to the KDC with a request for a service ticket.

The KDC returns an encrypted service ticket to the client. The client uses the TGT to extract the service ticket. Now, at this point, this client can authenticate to the server in one of two ways. One is one-way authentication, the other is mutual authentication. For completeness' sake, we're going to show both, although in all circumstances you really want to try to use mutual authentication. So in the one-way example, the client presents the service ticket to the server. The server then receives the service ticket and authenticates the client. At this point, the client and server can actually encrypt the data by using the session key.

In the mutual authentication case, the client sends the service ticket containing the session key to the server, just like in the one-way. However, at this point, it's pretty critical, the server essentially authenticates back to the client. It returns a response encrypted with session key from the service ticket, authenticating the server to the client. It's very important that all the paths, all the servers and clients in the machine are authenticating to each other. Thus, the trust relations are established. The server should also use session key to encrypt the subsequent traffic, just like in the one-way authentication example.

Now, that was an example sort of in the abstract case of how Kerberos fundamentally works. Now, let's take a look at a more specific example for the application developers so you can get an idea of how to add it to your application. In this case, we're going to look at IMAP because it has a number of good standards and the source code is out there for looking at it as an example. So IMAP uses SASL, the Simple Authentication and Security Layer, for its negotiation of authentication methods. SASL will imply the use of the GSS API, which I'll get into a little bit later, for accessing Kerberos 5. And then eventually the authentication tokens that are passed around are Base64 encoded. So let's see how the negotiation happens.

First, the client sends a request to the server asking what its capabilities are. In this case, the server listed it, hey, I do GSS, amongst many other things. Client says, I want to do GSS. The server sends back a simple, let's go ahead. And then the client sends the Curbless Authenticator as part of a GSS API token.

The server then sends mutual authentication response as part of another GSS API token, thus the client and server authenticating to each other. The client responds with a simple acknowledgment. At this point, the server sends back some security options, including buffer size, more importantly, whether encryption should be used. The client then, at this point, actually is sending in who it wants to log in as and selects encryption.

The server sends back whether the client was in fact authorized and whether encryption was selected. Notice that Kerberos was doing authenticating of the user, whereas at this point the server is now actually doing the authorization of whether the user can actually log in. And it's using a different mechanism other than Kerberos, as Craig said, is refactoring the problems. So some points to remember about connecting to a service. After all this negotiation is done, your base protocol in the example IMAP will proceed as normal. However, encryption will protect the data stream.

You can use the session keys to negotiate your actual encryption keys. So essentially, as a byproduct of the Kerberos authentication, you can get encryption. All these ticket exchanges that I just presented, and all the arrows going back and forth, are basically invisible to the user. The connecting to the service is essentially automatic for them.

They don't need to type in the password when they're connecting to an IMAP or FTP server or whatnot. These negotiations, these Kerberos features are often all automatically. This is sort of the behavior for the end user to get the single sign-on. They're entering their password once when they're logging into the system, and they don't have to enter it anywhere else, hence single sign-on.

What do service tickets look like? In this example, the user's logged into a variety of services, including a v4 service and a variety of v5 services. To the user, they just launched a bunch of apps. They don't even know that this app is v4 based or this one is v5 based. To them, they just launched the app and got their data. And all this authentication happened for them behind the scenes automatically.

So let's take a look at some Kerberos infrastructure examples. This will be quickly going over some KDC setups, including MIT, MIT KDC with Active Directory, and Apple KDC, and then some general KDC recommendations. I know a lot of folks are just looking in at deploying Kerberos at their sites, so we thought it was a good idea to go over some of these points. Now, an MIT stock KDC from the MIT distribution provides best support for a wide cross-platform environments from older clients to current clients. It provides flexibility for special deployments such as AFS, the Andrew file system. However, and we'll be honest here, it's a wee bit complex to manage, configure, build, install. But that's why source code is available. So but a lot of people are really interested in Active Directory. And a lot of people are interested in putting Active Directory with their existing MIT KDC infrastructure.

So briefly show a little bit of how you can possibly lay this out. By no means is this the only way you can lay it out, but this is a little example. We get asked this question quite a bit. First why would you do it? Well, it provides good support for Windows integration.

There's a cross-domain trust between the Windows Active Directory and the MIT KDC. Now, an important interesting point here is that if you have two MIT KDCs, you can exchange keys between them, and users can use what's called cross-realm authentication. However, that doesn't actually imply trust between the realms. Whereas Windows Active Directory actually has an important concept of trust between its multiple domains. So when you actually set up Active Directory and MIT KDC to communicate with each other, there's relationship of trust between the realms.

Now, in this example, the MIT KDC will contain the canonical list of user accounts and the host keys for the non-Windows machines and services. There are mappings of the user accounts in an MIT KDC to the accounts in the Active Directory domain. So, just a quick little diagram. You can see that the trust relationship exists between the MIT KDC and the Active Directory, and that's where the account mapping happens. A user would authenticate to the MIT KDC and then get information automatically out of Active Directory. The non-Windows application services are stored, the host keys are stored in the MIT KDC, and the Windows specific application services information is stored in the Active Directory.

Now, as you may have heard in Dave O's session on Tuesday, Apple is introducing a KDC and Panther server. Why might you want to use it? Well, unlike the MIT KDC, it's easy to set up and configure. You probably didn't even know you actually installed it once you've gone through the setup assistant. It takes advantage of Apple's open directory, so if you're setting up an infrastructure for the first time in a small site, you get a nice directory with it. An interesting implementation detail of the Panther server is KDC is that the password server actually contains the Kerberos keys and other passwords for the legacy clients to connect to it.

Now, in this case, for Panther server KDC, the machines talk to the directory to get Kerberos configuration information automatically. And then, of course, machines will talk to the Apple KDC for their Kerberos authentication. station. So general KDC recommendations no matter which KDC you're setting up. Use triple DES with an extra P for extra security. And RC4 instead of DES keys. DES probably that G5 is that they introduced, we can crack DES faster than you can throb a button. Set the preauth required flag on an user principles. That helps secure the actual TGT exchange.

Run as few other services as possible on your KDC. You don't want these other services to have vulnerabilities that compromise your KDC data. Avoid Kerberos 4 as much as possible and at all costs. I'll get into that a little bit later. Deploy client configuration files with as few, as little specific information as possible. This allows you to take advantage of new encryption level features that we add into Kerberos. You deploy the libraries and deploy the new KDCs, then the clients can take advantage of that. When settings are explicitly set, that usually overrides the new functionality and new security level. And of course, securely backup your KDC, And that is left up as an exercise to the user.

Now, I don't normally go into distributed file systems, but due to some recent issues with Kerberos 4, we thought it was warranted discussing it. Andrew file system is a popular distributed file system used by many sites. I mention it because it uses Kerberos v4 as its fundamental authentication. There's been a number of improvements to AFS and to MIT Kerberos to allow the use of v5 to do as much of the authentication as possible. You can get a new v5 AK log from MIT. The URL is above, mit.edu/openafs. You should run a curb 5 to 4 on your KDC, curb 5 to 4D. And you should only use curb 4 for the AFS principle, and do not globally enable v4 for all users.

Now, at this point, we'll talk a little bit about Kerbos for Macintosh, the Kerbos implementation in Mac OS X. Now, in Jaguar, we shipped the first full-featured client version of Kerberos in a Mac OS X, and we're really excited about it. We included KFM 4.5. We managed to ship with Apple a Kerberos ticket management application, Kerb 5.1.2.6, number of performance enhancements, improvements to the command line utilities, and 5.2.4. And thanks to bug reports that you filed in 10.2.3, we shipped KFM 4.5.1, and most people didn't even notice. But, you know, a few people did, so we're happy. Now, at Panther, we're introducing Kerbos from Macintosh 5.0. We've included a real host of nice new features.

Most importantly is Kerberos v5 1.3. It includes a number of improved Windows interoperability features. We have a new Kerberos login dialog that fits in better with Mac OS X authorization dialogs. We have a UI for getting address list tickets, so Kerberos 5 will work better behind a NAT, and we all know NATs are out there. We have DNS support for KDC lookups, and we have renewable ticket granting ticket support.

On the server side, we actually now include all the server components. A standard stock MIT KDC is included and related daemons. And the common tools to operate an MIT KDC, KAdmin and KDutil. We have many requests for those. And of course, I'll also plug that Apple includes a more integrated KDC as part of Panther Server, but you have your choice. You can take an MIT stock KDC or you can use the Panther Server KDC.

So let's take a look at the Kerberos for Macintosh 5 architecture. It's a little different than Kerberos and other implementations. First, we have the application layer and standard Maco applications. They access the Kerberos libraries directly. Now, for command line applications, they actually go through symlinks and userlib to access the main Kerberos libraries in the system directory. In Jaguar, if you were compiling stuff, you needed to install the BSD SDK headers, DevTools, which was turned off by default, although it looks like Apple has fixed that with Panther. And that stymied a number of people reporting their applications. We also have support for CFM Carbon applications through CFM Shub libraries that MIT distributes.

And the system directory in Mac OS X contains the Kerberos framework. It has a library file containing all the various Kerberos libraries, and plus many others not listed. And different than Kerberos in other environments is the C cache server. It contains the tickets in memory. And it uses Mach-I PC to communicate with the Kerberos library.

Lastly, we have the Kerberos login server. This is the actual component that presents the login, Kerberos login dialogue for you, and it communicates with the Mac IPC to the Kerberos framework. A lot of people think that's actually a part of the Kerberos application, but it's actually stored in the Kerberos framework itself.

So the Curve 4 included in KFM includes the KClient API compatibilities, just like on Jaguar Kerberos. However, a significant change we've made is that the Curve 4 library comes from the v4 compatibility library in the stock MIT Curve 5 distribution. We previously had based it on a separate library from an older Cygnus distribution. So now more of the platforms in the MIT Kerberos code share the same v4 library.

Now, applications can use either KClient or the straight V4 APIs for their V4 support. However, new code shouldn't be developed using V4. Why, you might ask? Well, it only supports DES. As we know, DES isn't very secure these days. You cannot get addressless tickets if it's not part of V4.

Tickets do not support a variety of various feature flags, such as forwarding. Microsoft has no native support in their Windows products for v4, so that makes integration components much more difficult. Oh, and there's this little teensy problem that there's some fundamental problems with the protocol in an encryption level. If you really want to go read up the fun, there's the cert vulnerabilities that we released a few months ago. Kerberos v4 is pretty much dead and busted. But there is a solution, and I'll give everyone one guess.

Kerberos 5. So everyone really should be migrating to Kerberos 5. And in KFM 5.0, as I said, we have Kerberos 5.1.3. An enhancement is that we have support for the current IETF draft of Kerberos clarifications. We also include the GSS APIs, application level API for accessing the Kerberos functionality.

Let's take a look at some of the features of v5 1.3 in depth. As I said, we have improved Microsoft Windows interoperability. That specifically means we've added TCP support for communication in the client libraries and KDC. We have support for the RC4 crypto system. And we have support to the Microsoft Set Password protocol.

We've also added improved support for IPv6. We could use a lot of help testing this out, so get your Panther seeds and try it out. We have initial AES support. Now it's not complete, and we're still working with Microsoft to define some of the standards for AES support, but Mac OS X Panther may be one of the first out of the gate with AES. We also now have support for building on pure Darwin systems. If you do this, you'll get a stock Unix Curb 5 installation, but we know a few people out there like to run on pure Darwin systems, so we now have support from that.

And of course, many bug fixes and future improvements from previous Curb5 releases. We get asked this all the time. In fact, before the keynote, we got asked this question. Do you interoperate with Microsoft? So yes, Active Directory can be used as a Curb5 KDC to a Mac OS X client, a Kerberos client.

Windows also has a GSS mechanism called Simple and Protected GSS API negotiation mechanism, not SPNEGO. However, unfortunately, it doesn't have a public counterpart on Mac OS X right now in Panther, but we are trying to work on it with a variety of vendors. Also, there's SSPI, an application interface that Windows promotes.

Fortunately, it's very similar to GSS. Microsoft even publishes a document which we reference later in the session to help you map the APIs. If you're writing as a Macintosh developer and you want to perhaps port over onto Windows, you should write to GSS and you should hopefully be able to move it, create a shim layer to write on top of SSPI. As I mentioned, TCP and RC4 support are there. Now, going back to the architecture slide, the credentials cache, the tickets on Kerberos from Macintosh are stored in memory. This allows us to be more flexible in how we manage our tickets, supporting multiple credentials in multiple realms more easily.

The Kerberos login library is unique to Kerberos for Macintosh, and it simplifies getting both v4 and v5 initial tickets. You can get and acquire and destroy the initial tickets with a single call. It provides an API for programmers to change the settings that come up in the Kerberos login dialogue if you want. And it mostly is used by sort of administrative apps or those that are trying to do sort of login behavior on the Macintosh and perform actions on TGTs.

Other libraries that are also provided include ComError for error handling and ProfileLibrary for reading elements out of the Kerberos configuration file, such as your default realms and whatnot. The Kerberos application is an end user application for obtaining, getting information, destroying tickets. Also provides UI for setting things such as the Kerberos login dialogue defaults in your favorite realm. Also the dock icon presents information to the user about the status of the Kerberos tickets, when they expire, and a dock menu if the user holds down the mouse button, they'll see a menu of actions they can perform on the Kerberos tickets. People often ask about a menu in the menu bar, however the menu is already provided in the Kerberos application.

For KFM 5.0, we've included a number of new features in the Kerberos application, including editing the settings for the new login dialog defaults, improved performance and appearance. Now you get your blurry text. Enter realms for DNS in your favorite realms. New time ranges for setting renewable ticket options. And even more importantly, while it's running, it will auto-renew your TGTs when applicable. Then when you get the renewable TGTs, if Kerberos app is running, then it will automatically renew your tickets. However, if you put the machine to sleep and your tickets expire, you cannot renew expired tickets. But if you're on a 36-hour coding marathon, you don't have to enter your password at all. Kerberos app will keep auto-renewing your tickets.

So let's take a look at the new Kerberos login dialog. As you can see, we've changed it to look more like the standard Mac OS X authentication authorization dialog. It even tells you which applications requesting Kerberos access, in this case, Mail app has been trying to do Kerberos authentication. You can also see the Realm field is now in editable text, so you can better support with the DNS lookup with the KDC Realm.

If you show options, and this may be a little difficult to see, we've expanded the dialog, and you can see there's a checkbox for the address list tickets, so it's no longer hidden in a configuration file, and you can configure how long you want your tickets to be renewable for.

So, now there are some changes in Panther Kerberos that you should be aware of. First, due to the change in the application framework that we're using for the login dialog, the login dialog's password field has been changed from Mac Roman to UTF-8. Now, internationalization in Kerberos passwords is one horrible mess, and we're sorry to make it a little bit worse. But if a user has a password that uses hybrid characters in Mac Roman encoding, they'll have difficulty logging on. Now you have your administrator can reset their password, or they can use the terminal, change the character set, and change the password from there.

New CFM bridge libraries are unfortunately required, however they are available to you today. And the new bridge libraries will work both on Jaguar and on Panther, so you just need to do one distribution. Command line clients will no longer automatically prompt when no tickets are available. The behavior now is identical to on the other Unix environments.

Curve 5 to 4 authentication now requires a valid V4 configuration to be available. Jaguar would always try 5 to 4, and that was a problem for a number of sites. And sudo and su will now get an empty ticket cache, not have access to the logged in user's cache due to changes in interoperating with the new security server.

Let's take a look at developing for Kerberos. How do you Kerberos your application? Well, it's kind of easy. Well, hopefully. Find the protocol specification, RFCs, whatnot. To bring which API to use, if you had to add some support for v4, you could use kclient or gssapi or Kerberos 5, depending on the application's need.

And you figure out how to connect the API to the protocol. This means that the data returned by the various APIs needs to be solidified in some form that the base protocol understands. Typically, this is base 64. Take a quick look at Curb Rising FTP, because it has a couple of nice RFCs defining how it works. One for v4 and one for GSS and K5. You would use, in this case, KClient API for v4 support and GSS for Curb 5.

I'm skipping the v4 point to make-- we're not supporting v4 anymore, right? Right? Yeah. So GSS API. First, you start with some session management and authentication. I've done through GSS in its set context. You do some base encryption and decryption of the data stream through GSS wrap and GSS unwrap. And the way, as an example, to connect the API to the protocol is through base64.

Let's look a little bit more in GSS API programming in depth, the basics. Now, GSS exchanges are messages and things called tokens. At the beginning of the program, GSS exchanges context tokens to perform the authentication and to set up the encryption. Later, the program actually calls GSS wrap and GSS unwrap to do the encryption and decryption of the application data.

In general, to hammer the point home, all application data should be encrypted. There are a number of applications out there that still just do authentication, and our users tend to think that even all the data stream is still encrypted when they're using Kerberos, and we need to make sure all the applications are, in fact, encrypting the data. Users like security. Application choices. Applications must select GSS API security services that they want. Most applications want to explicitly turn on following features: integrity protection, confidentiality, replay detection, and sequencing. They're not as scary as they sound. GSS API also provides a facility to forward credentials from one system to another.

Now the program flow of GSS programming essentially requires multiple round trips for authentication, potentially. An application does not necessarily know how many round trips are going to be required ahead of time. So the application loops waiting for the authentication to finish. So let's take a look at the GSS client loop. The input token, you set it up, set it to null. You then go into a do loop with GSS and its set context.

If the output token is there, then you send the output token. And then you check the major status, GSS status. If you continue as needed, you essentially continue doing the loop. On the server side, you sit there looping, trying to receive a GSS token. Let's see if that's accept set context. If it's there, you send a response back.

And you check to see whether continuation is needed. And if it is, you continue looping in the do loop to receive all of the data. Thank you. So Kerberizing suggestions for developers. Use SASL if you're adding Kerberos to your own proprietary protocol. That'll help handle a lot of the negotiations of the various authentication methods you have available to you, not just Kerberos, but other ones. Using SASL includes using GSS API for your Curb-5 functionality.

The GSS API helps isolate applications from differences in the Curb-5 APIs. The Curb-5 APIs actually aren't any real standard, and different implementations have different API semantics. So GSS is actually an RFC C-binding, so that helps make your application more portable to different environments. Again, to drive home, point home, do not add additional v4 support. At this point, v4 is very insecure, and we need to make sure everyone's migrating off to v5.

So in summary, as was mentioned in other sessions, Kerberos is simply a powerful solution to authentication and single sign-on. Provides an unobtrusive authentication experience to the user. It's available on a wide variety of platforms. Site should be moving from Kerberos 4. Have I gotten the point across? Panther and Panther Server will provide a wealth of Kerberide services. And Apple, as has been mentioned in a previous session, is committing very heavily to Kerberos. And they will be driving adoption of Kerberos throughout their operating systems.

If you need to report a bug about Kerberos and Mac OS X, since there are so many people, its family is very large, report the bugs to Apple. It's nice we like to hear from the bugs at MIT. However, in order to get your bugs fixed and back in the OS, they need to be filed at Apple. If you feel that your bug is not getting attention, please bring the issue up with Apple. They're the ones who ship it. So if you need to get it into a software update, you need to raise the issue with your Apple representative.

So to wrap up, here's the roadmap. Most of these sessions have already happened. However, there's a security feedback forum on Friday. You can contact Craig or myself or also Skip Levins, who is the server technology evangelist, and a lot of his folks are doing a lot of the Kerberos integration.

For information, we have a variety of URLs. The documentation that's available for MIT is in a couple of places. And all these URLs are available from Apple. Apple has a knowledge base article about Kerberos and Jaguar. And Microsoft has a number of interoperability web pages, including frequently asked questions.

There are a number of RFCs for-- you might want to look at, like IMAP authentication mechanisms is a great example of how to use SASL and GSS. And a lot of people don't know this, but we actually did publish the source code as much as we could, legally allowed, in--to Kerberos for Macintosh 451 in Jaguar. It's on the Darwin Kerberos page, and that's available under the developer site at Apple.