But today, we're talking about Kerberoes. So we'll do a very quick overview of what Kerberoes is, how it works, the internal infrastructure, the new features we're adding to Kerberoes and Panther, and how you can add Kerberoes 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 Kerberoes? It's a secure network authentication system. One of the things that is worthwhile to understand is 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.

Kerberoes proves who you are, and it uses a trusted third-party security model to do this. Who uses Kerbero? Well, certainly the government does, and education. Large corporations are starting to use it, and we built a lot of it into 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. crossed 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 is freely available. So to talk about Kerberoes for the Macintosh, Marshall Vale.

Thank you, Craig. Good morning, all. My name is Marshall Vale. I am the project manager of Kerbero development at MIT. I have a lot to talk about, so let's get started. First, Kerbero 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 Kerbero was developed to solve network authentication.

Kerbero V became an IETF-proposed standard in 1993, and it has 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 Kerbero as the single sign-on solution for Panther and Mac OS X going forward.

There are two forms of Kerberoes protocols in common use. The first is Kerberoes 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 Kerberoos v5. It was designed to solve many of the security deficiencies and other problems in Kerberoos 4.

Now let's take a look at some of the Kerbero 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 Kerbero. 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 Kerberoos 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 Kerberoos 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 and they 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.

That was an example in the abstract case of how Kerbero 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 source code is out there for looking at as an example. So IMAP uses SASSL, a simple authentication and security layer, for its negotiation of authentication methods.

SASSL will imply the use of the GSS API, which I'll get into a little bit later, for accessing Kerbero S5. And then eventually the authentication tokens that are passed around are Base64 encoded. So let's see how the negotiation happens. SASSL 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. Server sends back a simple, let's go ahead, and then the client sends the Kerberoos 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 acknowledgement. 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 Kerbero 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 Kerbero, 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 and 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 Kerbero authentication, you can get encryption. All these ticket exchanges that I just presented, 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, Kerbero's 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? Well, in this example, the user is 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 Kerbero 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 Kerbero 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's available.

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 I'll briefly show a little bit of how you can possibly lay this out. By no means is this the only way. There's only one 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 an implicit relationship of trust between the realms. Thank you.

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 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 that the password server actually contains the Kerbero 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 Kerbero's configuration information automatically. And then, of course, machines will talk to the Apple KDC for their Kerbero authentication.

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 that they introduced, you can crack DES faster than you can throb a button. Set the pre-auth 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 back up 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 Kerbero4, 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 Kerbero4 as its fundamental authentication. There's been a number of improvements to AFS and to MIT Kerbero4 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. You should run a Kerbero4 on your KDC, Kerbero4D. And you should only use Kerbero4 for the AFS principle, and do not globally enable v4 for all users.

Now, at this point, we'll talk a little bit about Kerberos for Macintosh, the Kerberos implementation in Mac OS X. Now in Jaguar, we shipped the first full featured client version of Kerberoos in a Mac OS X. And we're really excited about it. We included KFM 4.5. We managed to ship with Apple a Kerberoos ticket management application, Kerb 5.1.2.6, number of performance enhancements, improvements to the command line utilities, and 5 to 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 a few people did. So we're happy. Now at Panther, we're introducing Kerberoos from Macintosh 5.0. And we've included a real host of nice new features.

Most importantly is Kerbero's v5.1.3. It includes a number of improved Windows interoperability features. We have a new Kerbero's login dialog that fits in better with Mac OS X authorization dialogs. We have a UI for getting address list tickets, so Kerbero 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, K-Admin 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 Mac OS 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, the dev tools, 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.

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

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

So the Curb 4 included in KFM includes the KClient API compatibilities, just like on Jaguar Kerberos. However, a significant change we've made is that the Curb 4 library comes from the v4 compatibility library in the stock MIT Curb 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 and encryption level. If you really want to go read up the fun, there's the cert vulnerabilities that we released a few months ago. Kerberoos v4 is pretty much dead and busted. So, but there is a solution, and I'll give everyone one guess.

Kerberoos 5. So everyone really should be migrating to Kerberoos 5. And in KFM 5.0, as I said, we have Kerberoos 5.1.3. An enhancement is that we have support for the current IETF draft of Kerberoos clarifications. We also include the GSS APIs, application level API, for accessing the Kerberoos 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, Kerberoos clients.

Windows also has a GSS mechanism called Simple and Protected GSS API negotiation mechanism, Spanego. 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 Kerberoes 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 Kerberoos login library is unique to Kerberoos from 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 Kerberoos 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 ComAir for error handling and Profile library for reading elements out of the Kerberoes configuration file, such as your default realms and whatnot. The Kerberoos application is an end user application for obtaining, getting information, destroying tickets. It also provides UI for setting things such as the Kerberoos login dialogue defaults in your favorite realm.

Also, the dock icon presents information to the user about the status of the Kerberoos 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 Kerberoos tickets. People often ask about a menu in the menu bar. However, the menu is already provided in the Kerberoos application.

For KFM 5.0, we've included a number of new features in the Kerberoos 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. When you get the renewable TGTs, if KerberoSAP 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. KerberoSAP will keep auto-renewing your tickets.

So let's take a look at the new Kerberoos 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 Kerberoos access-- in this case, Mail App is trying to do Kerberoos authentication. You can also see the Realm field is now in editable text, so you can better support with the DNS lookup of 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 Kerberoes 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, internet authorization in Kerberoes 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 high-bit 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.

Kerb 5-4 authentication now requires a valid v4 configuration to be available. Jaguar would always try 5-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 Kerbero. 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 GSS API or Kerberoos 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 Kerberizing 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 Kerber5.

I'm skipping the v4 point, because 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 Kerberoes, 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 the following features: integrity protection, confidentiality, replay detection, and sequencing. They're not as scary as they sound. GS SAPI 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 NetSec 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. With CSS Accept SecContext.

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. So Kerberizing suggestions for developers. Use Sassl 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 Zassal includes using GSS API for your Kerber-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, Kerbero 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 Kerbero. 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 Kerberoos in Mac OS X, since there are so many people, his 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 Levens, who is the server technology evangelist, and a lot of his folks are doing a lot of the Kerbero integration.

For more 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 Kerberoos and Jaguar. And Microsoft has a number of interoperability web pages, including frequently asked questions.

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