Good afternoon. I'd like to welcome you to session 814, Kerberoos in Mac OS X. My name's Tom Weier from developer relations. I've probably seen many of you in a variety of sessions thus far. I have the distinction of being able to introduce a session that in many ways has been a personal crusade for quite some time. And it's good to see that with each passing year, the adoption of Kerberoos within Apple OS X, it's been a personal crusade. And in the shipping, OS has improved year after year. So with that, I'd like to introduce John Hurley, the security policy architect at Apple.

Thanks, Tom. Okay, we have some great stuff to talk about today. As Tom said, we've really been making some great progress. So we're going to talk today about what Kerberoos actually is, the Kerberoos authentication system, and a little bit about how it works. Marshall is going to talk about some of the libraries that are available to developers and how you might go about Kerberizing your application.

We're also going to tell you about where it's used within the system. We've added a lot of things to a lot of system services that are Kerberized. We'll tell you how you can put that into your applications and make use of it. So what is Kerbero? Kerbero has been around for a while. It's a great setup for authenticating users to a server and to other servers.

One of the things that I wanted to point out is the difference between authentication and authorization. Michael gave a session yesterday about the authorization APIs, and Kerbero is an authentication system. So it's kind of proving who you are. It's a way of identifying a user to other services on the system.

It's not particularly granting you rights to do things, although you can get service tickets that allow you to talk to servers, and they will allow you to do things. It assumes that you have a trusted third party, which is a server that knows the passwords for your users, and you can talk to that server, and you have to assume that that's trusted.

Okay, so Kerbero is really pretty widely used now. There are a lot of different areas in technology that are using it. It's used by government, large corporations. Very, very widely used in higher education. That's kind of where it got its start. It's probably one of the biggest areas where it's deployed. Certainly in Windows, it's all over the place. The Passport service uses it. It's in Windows 2000. Kerberoos is really pretty ubiquitous.

Okay, so what are some of the reasons for using Kerbero? It does provide mutual authentication of client and server. So it's not, for example, like SSL or how SSL is usually used, which is just to authenticate the server. In Kerbero, you know who your server is, and then the servers know who the clients are.

It does add the ability to do a certain amount of single sign-on. So you're providing, the user is providing their credentials once, their password, and then they can access other system services without having to provide these credentials again. And that's really very nice for the users because they're not constantly entering their passwords. And as we've Kerberized more system services within Mac OS X, that's made it easier for people in a Kerbero environment.

So they log into the system, and then they can access all these different services. It allows you to centralize your authentication decisions so you have one server set up that actually knows who your users are and it protects their passwords on that server so they're not being sent over the network. It is possible to extend it.

Okay, because the password itself is never sent over the wire, it's really a pretty good setup. I mean, that means that you're not going to be able to do dictionary attacks. It does assume that the server itself is in a locked room somewhere because the passwords are actually on the server. So you want to protect that.

There are Kerbero implementations for lots and lots of different platforms. Mac OS X, Windows, Solaris, pretty much everywhere. As I mentioned before, it has been around for quite a long time. It's developed in the 80s. I don't know if Tom was looking at it back then, but I know he's been thinking about it for a long time. and the source code for this is available.

So Apple has been doing more and more with Kerberoes. And that's largely because we know that it's very, very important to our markets. As we mentioned, it's very common in higher education, and that's a real key market for us. At a developer conference two years ago, we talked about the relationship that we had with MIT, which has been absolutely great for Apple.

We've really seen lots of progress on that, and it's really been great being able to put that in and see that get leveraged throughout the system. This is probably a good time to sort of provide a round of applause for Marshall and his team from MIT. They've done a fantastic job of getting that stuff. Thank you.

They've had very interesting times working with Apple, but we've really been glad to see this stuff moving forward. One of the other things to mention probably at this time, too, is I think we are at the point now, certainly one of the goals that we're trying to achieve is we're trying to make the Kerberoes that's installed in Mac OS X to be usable out of the box. So traditionally, Kerberoes has been, because the source code's available, particularly universities will take it and customize it, and it's very hard to move the standard forward there because everyone's afraid of breaking what's out there.

But we really think that the version that we have that we're shipping with Jaguar is the kind of release where hopefully people can just set their machines up with configuration rather than having to do lots of source changes or any source changes. That's certainly our goal, and we're hoping that Jaguar will get us a long way there. So there's certainly a lot of users out there already. It has shipped on OS X, 10.0, and I think we'll see a lot more users of it as we go forward.

So, talking about some of the components that have been Kerberized in Jaguar. And I think everything we're talking about right now is actually on the CD that you have. The base for this is Kerbero for Mac 4.5 from MIT. So those are the libraries that we're building on.

On the client side, some of the things that have been Kerberized, AFP, some of the UNIX utilities, the mail application has been Kerberized so it can talk to the mail server and use Kerbero authentication. We've also put Kerbero authentication into the login window. We did a lot of changes for Jaguar for login. The login window calls the authorization API and asks for the right system.console or .login.console. If it's configured properly, you can configure it to use Kerbero authentication to login. That credential works. The credentials you obtain then can be used by the user throughout the session.

On the server side, we've Kerberized the AFP server, mail server, and FTP server. There are other components that are in the works. If there are other system services that you'd like to see Kerberized, then please let Tom Weier know about those. Okay, so I'm going to ask Richard Murphy, who's the manager of data security, to come up and do a demo for us. Thanks, Mark. Hi there.

So, as John mentioned, there were a lot of people that actually were working on this. Originally, we were given the task of kind of coordinating the Kerberoos project, both John and I. There were a lot of people involved with that. There was Marshall and his team out at MIT. The BSD team hired a person specifically to do that.

We got him out here, told him all about California, and the first thing we did was we took Nikolai and we shipped him out to Massachusetts for a winter. Great way to just win him over. Nikolai did a lot of great work out there, helped coordinate getting builds in to the campus and work with their team. The MIT team was great working with him in coordinating getting builds through our builds process in a remote situation.

We also had the login window work done by the security team. Conrad Sauerwald and Gary Hu. And then there's the AFP team. Leland Wallace working on being able to get the Apple share AFP mounts going. So my key role in this was going to meetings week after week and going, "Is it done yet?" They knew me rather well.

Are we done yet? When is this going to be done? So this last week, everything kind of fell together. Made my whole day. So here we go. We have the login panel. What I'm going to do here is I'm going to log into the local machine here, and I'm going to get a Kerberoes ticket. Nothing up my sleeves.

And we've logged in. So what does this tell us? I'm going to bring up the Kerbero app. And you'll notice we have a ticket granting ticket here. Okay, good. Okay, next thing, mail. I have lots of mail. We set up this demo so I would. We won't read any of it right now.

And back to the Kerberoes app. Here we are, a second line. We've got the Kerberoes ticket that actually authenticated me to the IMAP server. Okay, okay, you like that? Okay, cool. Here comes the tricky part. So I'm going to connect to a server and we choose really wonderful names for servers around here.

We have an AFP-mounted home directory and yet another ticket. There you go, guys. It's there. It's working. So the challenge is left to you guys. When is it going to be done? Okay. Use this stuff. It's cool stuff. Take care. I'll just go ahead. Here's Marshall. Hi, all. I'm Marshall Vale from MIT.

I'm the project manager for Macintosh and Kerbero's development. Thanks to the nice demo Murph showed you, you've seen Kerberoos in action. Let's take a look about what's going on under the hood. Kerbero out there deployed in sites is made up of two protocol versions, Kerbero version 4 and version 5. You may wonder what happened to versions 1 and 2 and 3. They did in fact exist, but never got out of the lab. Kerbero version 4 is the original version of the Kerbero protocol.

It's still widely used in many higher ed sites. They've been using Kerbero for probably over a decade. If you're writing a new app, we don't suggest that you support Kerbero v4, but only if you find that your key markets really need it. The current version of the protocol is Kerbero version 5. It's designed to fix many of the security deficiencies of version 4. Version 5 is what Microsoft adopted for their version of Kerbero in Windows 2000 and XP. It's the suggested version of Kerbero you should use in your protocols.

Now we'll probably toss around, we've already tossed around, a few acronyms for you. So let's take a review of what they are. First is a Kerberos Realm, which defines the administrative unit that is protected by a KDC, or Key Distribution Center. The tickets are the little magic beasts that go around.

They're the authentication tokens that authenticate you to various services. For types of tickets, we have two primary types of tickets. A ticket-granting ticket, also called an initial ticket. It's used to seamlessly get service tickets. Now the service tickets are used to authenticate you to a particular service, such as FTP, email, printing, whatnot.

The ticket training ticket, or TGT, is also called the initial ticket because it's usually the first ticket that a user gets. It proves that the client is allowed to get tickets for the other services. It acts as a substitute for a password in the sense that the TGT is presented around and allowing the user to get the access to the other services without having to provide a separate password to the Apple share server or the FTP server or the email server.

It's also the mechanism by which single sign-on is achieved due to the seamless acquisition of service tickets. All Kerbero tickets, including a TTT, are only valid for a limited period of time. They expire. A typical deployment usually does them in a work period such as eight to ten hours, although they can be shorter in some stronger security sites or longer if you really like to work longer than that. So let's see how we get a TGT. First, the client will ask a KDC for a TGT. Next, the KDC returns the TGT and a session key to the client encrypted in the client's key.

The client then uses the client's key, which is the one-way hash of the password the user just entered, to extract the TGT. You can see that there, at no point did the password actually go over the wire in any encrypted form. And that's what brings a real inherent level of security to the typical Kerberoos exchange.

Now the service tickets are the type of tickets used by a client to access a particular service, an FTP mail, as I mentioned before. It contains a session key, which is shared between the client and the server, and can be used to subsequently encrypt the data exchanges to make them a little more secure and not just for authentication. Like a TGT, a service ticket also expires. So I'll see how we get a service ticket. First, the client presents a TGT to the KDC with a request for a service ticket. The KDC returns the encrypted service ticket to the client.

and then the client uses the TTT to extract the service ticket. From here, the client can authenticate to the server in one of two ways. First ways with one-way authentication. Here the client presents the service ticket to the server. The server receives the service ticket and authenticates the client.

The server can use the session key to encrypt subsequent traffic. This is used in a variety of some of the older protocols that aren't considered as wonderful, such as K-pop. A better way of doing service authentication is mutual authentication. Here the client sends a service ticket containing the session key to the server.

The server returns a response encrypted with the session key from the service, from the service to get, authenticating the server to the client. and like with one-way authentication, the server may use the session key to encrypt subsequent data. So now we've seen how the protocol works in BASIS, let's take a look at the implementation. Earlier this year, MIT released Kerberoes for Macintosh 4.0. We've been working on this for about a year and a half, and we were very happy to finish it. And over a year and a half, we supported three versions of Mac OS X, all different.

A pre-release version of KFM 4.0 was included in Mac OS X. That was the very first step of our wonderful collaboration with Apple. The version number of the package, Kerberoos for Macintosh, may be a little confusion, but it does in fact include both Kerberoos version 4 and version 5 libraries. These libraries are available to a variety of application environments, including Carbon, Cocoa, and BSD command line apps.

Also in KFM 4.0, we introduced live ticket sharing between Mac OS X and classic Mac OS 9, which was a real boon to sites as they needed to migrate their customers and they had both classic and native applications running at the same time. This way, users on classic didn't need to enter a password again. The tickets were automatically sent over to classic and were kept in sync between the two environments. As was alluded in the keynote, we're all moving on to Mac OS X, so Kerberoos for Macintosh 4.0 and 4.0 derivatives will be the last release for classic Mac OS, Mac OS 8 and 9.

As John mentioned earlier, our new version included with Jaguar is Kerberoes for Macintosh 4.5. A big change from previous releases is that the only way you'll be able to get this version is in the box. It will provide only as part of Jaguar. New features that we've added to Kerberoos for Mac OS 4.5 are improved loading times and reduced memory storage. We are able to be prebounded to the system and applications can pre-bind to us.

We also have a first version of a supportable Kerberoos v5 API, and I will touch on that later. We also have added 5-to-4 support. 5-to-4 is an interesting technology allowing you to generate version 4 credentials in a version 5 only environment. This is predominantly in use in sites that use the Andrew file system implementation such as OpenAFS or Arla, which use version 4 for their inherent authentication. We've also introduced a new command line application called kswitch, which sets the default user. First seen on Mac OS X. There will be no release of Kerberoes for Macintosh 4.5 for Mac OS 9 or 8. But don't worry, Classic Ticket Sharing will still work with KFM 4.0 working under Classic.

The Kerberoos for Macintosh 4.5 architecture is a bit different than on other UNIXs or on Windows. It's good if you write applications in different layers to take a look at how it all works. The top layer, we support the variety of application environments. Natively, we support the Mac OS application space of Carbon, Cocoa, and BSD apps. We provide shim libraries. They are not going to be provided by Apple.

MIT is traditionally distributed them directly from MIT, but that allows us to support CFM Carbon applications. The core library in the system is the Kerberoos framework comprised of a multitude of libraries. There used to be all individual and a big change in Jaguars, and they've now all been combined down to one single library.

Underneath that, the credential cache server stores all the tickets in memory. That's a big difference from most other UNIXs where the tickets are stored on disk. Even on UNIXs that store in memory, we use the credential cache API suite, which is shared between Windows. This API is also available on Windows and Mac OS 9, although Mac OS X has got the latest version. We use Mach IPC to communicate between the framework and the server. We also have the Kerberoos login server, which presents the UI that allows the user to enter a username, change the realm, and enter the password.

The Kerbero version 4 libraries include Kclient 3.1. Kclient is an API for Kerbero 4 that was invented at Cornell and became the dominant version on the Macintosh. This provides compatibility libraries for old Kclient 1.0 APIs, including also new version 3 APIs, which I know some applications have started to support. Underneath KClient, we have the Cygnus Kerbero version 4 implementation. It's the last release from Cygnus and includes a variety of changes to support the Kerbero login library.

Applications can use either API for v4 support. We strongly encourage you to use the KClient API because it is an API. The historic v4 libraries can be best described as a random collection of functions. Only use them if you happen to be porting code that hasn't been changed in years. If you find that you have to write to support v4 for your customer base, we highly encourage you to use the KClient APIs.

The Kerberos 5 implementation in KFM 4.5 is based on MIT Kerberos v5 version 1.2.5, which just was released a couple of weeks ago. Its primary feature for Jaguar is our first crack at a new cross-platform API suite. Kerberos v5 has not exactly had the best designed and cross-platform API in the world. It puts a lot of effort to try to make sure that we have a list of APIs that we can support going forward.

Right now that is in the Jaguar builds and we've also, on Kerberos for Windows, are using that subset. On UNIX we have declarations in the headers for deprecated and private, although due to a lot of the legacy apps we still have to export them. But we are moving forward with this basis of APIs. If you find that we have removed APIs that you may have relied on in the past, we'd like to hear what functionality you do need so we can design APIs that are supportable.

Also in the suite is the GSS API, the generic security service API. That is the recommended layer that you should actually be talking to, rather than the v5 API, to access Kerberoos 5. That actually has an RFC with a standard API, whether you like it or not. At least standard. The general recommendation is when you want to support Kerberoos v5, you use GSS as the API to access it.

So getting back to how the implementation works, the credential cache in the libraries is the bottom layer where the tickets were stored. It's stored in memory as opposed to on disk and many other platforms. This allows us to handle multiple credential environments a lot easier. This is true of many sites out there who have KDCs not one per environment but one per many small units such as various colleges at a university may have their own KDCs.

And a student has classes in both environments and they need to authenticate to both to do their work. It also provides an API for accessing the core v4 and v5 credentials. So if you happen to be writing a tool like the Kerbero app that needs direct manipulation of the credentials, you would write to the credential cache API.

The Kerbero's login library is a very powerful and special library in Mac OS X. It simplifies the process of acquiring TGTs, allows you to destroy all the tickets and acquire tickets with a single call, and most importantly, it transparently handles acquisition of v4 and v5 tickets no matter what the site has. It determines based on the configuration file whether the site supports v4 or v5 or both and handles acquiring them seamlessly for you so you don't have to worry about what the site uses.

It has also an API for adjusting the login library dialogue options. Applications used in this tend to be things like KNIT or a login window or, for example, a screensaver. That's not an announcement. Other libraries in the implementation include ComAir, which is how you access error codes in the Kerberos environment, and the Profile Library. This is the API which you use to read information contained in the Kerberos configuration file, such as library defaults and Realm information.

The Kervos application is a special tool for UI for obtaining and destroying listing, displaying information about the tickets. It's good for debugging. It allows the user to see how long their tickets are going to last for. The application changes when it's in the dock. It provides a dock menu.

Also allows settings for defaults in the login library. You may notice on your Jaguar CDs that it is not included. If you would like to see this included in Jaguar, we recommend you send a gentle and calm email to Apple suggesting that or give it to various feedback forms.

So now we've seen a bit about how Kerberos works. How do we Kerberize an application? It's awfully simple. Find the protocol specification. RFCs are the best place to look. There are also a few protocols that are de facto standards. Determine which API you're going to use. This may be determined by your market, whether you want to support v4 or v5, or it's determined in the spec, including K-client or GSS. You need to figure out how to connect the Kerbero APIs to the protocol. This usually means that the data returned by the Kerbero APIs need to be massaged into a form for the internet protocol.

So let's take a look at FTP. It's one of the nicest to look at because it has good standard RFCs for both v4 and v5. The standard for supporting with v5 is though via GSS and on Mac OS X and Mac OS we suggest using KClient for your v4 support as KClient over the base v4 APIs has better support for multiple sessions.

To support v4, you follow a generic process for Kerberoos. First, you want to set up a new client session. Then you want to do authenticate for the service. You do that with Kclient getAuthenticatorForService. Then you want to, for mutual auth, you call Kclient verify protected service reply to check the reply from the server.

FTP, Kerberos FTP, supports encryption of the data stream. User can actually toggle it on and off on the fly. This we use Kclient encrypt and Kclient And then the way, in this example, we're connecting the API to the protocol is through base64 encoding. That's a very common way of connecting Kerberoos to base internet protocols.

GSS API, we had to call, you can see different folks designed the different APIs. We call GSS init set context to do the session management authentication. Encryption and decryption is through GSS wrap and GSS unwrap. Just like with v4, connecting the API to the protocol is through base64 encoding.

So, how do you get started Kerberizing your apps? Well, start with Kerberos for Macintosh 4.5 provided in your Jaguar CDs. It's a development version, but it's very good and stable. Use the online resources, web documentation, extensively on the mailing lists also. You'll get a lot of help. And there's even a news group out there, too.

Reporting bugs. Some subtle differences here. If you have bugs about KFM 4.0, send it to MIT. Address is listed there. [email protected]. However, if you have bugs you want to report against the Kerberoes in Jaguar, please report them to Apple. Many of the mailing lists involving Kerberoes out there tend to be open in public. You're not supposed to be commenting about Jaguar until it's released in the open in public. Please report them to Apple. That also helps Apple prioritize what things we need to fix and what things we need to roll out to you.

So for more information, a list of URLs. The predominant place you might want to get on if you would like help in Kerbero is the Kerbdev mailing list. They're listed at the bottom. Send mail to kerbdev-request. Unlike last year, we finally automated this so it's not just a human reading it. If you want to contact the development team privately, if you're considering Kerberizing your application and you don't want messages going out to everyone and their friends, you can contact the Mac Dev team directly at [email protected].

Good place for hunting down internet RFCs to find out what already has a Kerberized protocol standard. This is there at the IETF. and Microsoft. There's the URL for Microsoft document describing GSS with SSPI. All of these URLs will be published by Apple someplace, I believe, on the web. And Comp's protocols Kerbero is also gateway with [email protected] and actually really doesn't have anything talking about the protocol much these days. Mostly application usage and programming issues.

But if you prefer using a news reader instead of an email client, you can still hang out If you have any questions concerning Apple's use of Kerbero in Mac OS X, you can contact Tom Weier. If you have questions pertaining to the Kerbero itself in Jaguar, you can contact myself or Mac Dev. And if you have any questions about security other than Kerbero, you can contact Craig Keithley.