Good afternoon. I'd like to welcome you to session 814, Kerberos 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 Kerberos within Apple 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 Kerberos actually is, the Kerberos 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. And we'll tell you how you can put that into your applications and make use of it. So what is Kerberos? Kerberos has been around for a while. It's a great setup for authenticating users to a server and to other servers. It's a great setup for authenticating users 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 Kerberos 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.

Okay, so Kerberos 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. the very, very widely used in higher education. That's kind of where it got its start, and it's probably one of the biggest areas where it's deployed. And certainly in Windows, it's all over the place, right? The Passport service uses it. It's in Windows 2000. So Kerberos is really pretty ubiquitous.

Okay, so what are some of the reasons for using Kerberos? 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 Kerberos, 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 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 Kerberos 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. And it is possible to extend it.

Okay, because the password itself is never sent over the wire, it's really a pretty good setup. 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 Kerberos implementations for lots and lots of different platforms. So Mac OS X, Windows, Solaris, pretty much everywhere. And 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 Kerberos 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. I mean, 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 Kerberos that's installed in Mac OS X to be usable out of the box. So traditionally, Kerberos 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. I THINK IT'S A GREAT There are 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 I'm 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. Thank you. The base for this is Kerberos 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 Kerberos authentication. And we've also put Kerberos 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 Kerberos authentication to login. 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 Weyer 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. Thank you.

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 Kerberos project, both John and I. And so 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 them out here, told them 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. Yeah. 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 and 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 Kerberos ticket. Nothing up my sleeves. Thank you. And we've logged in. So what does this tell us? I'm going to bring up the Kerberos 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 Kerberos app. Here we are, a second line. We've got the Kerberos ticket that actually authenticated me to the IMAP server. Okay, okay, you like that? Okay, cool. Here comes the tricky part. Thank you. 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. Thank you. I'll just go ahead. Here's Marshall. Hi, all.

I'm Marshall Vail from MIT. I'm the project manager for Macintosh and Kerberos development. Thanks to the nice demo Murph showed you, you've seen Kerberos in action. Let's take a look about what's going on under the hood. Kerberos out there deployed in sites is made up of two protocol versions, Kerberos 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.

Kerberos version 4 is the original version of the Kerberos protocol. It's still widely used in many higher ed sites. They've been using Kerberos for probably over a decade. If you're writing a new app, we don't suggest that you support Kerberos v4, but only if you find that your key markets really need it. The current version of the protocol is Kerberos 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 Kerberos in Windows 2000 and XP. It's the suggested version of Kerberos you should use in your protocols. Thank you.

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. Thank you. So the ticket training ticket, or TGT, is also called the initial ticket because it's usually this 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. for.

It's also the mechanism by which single sign-on is achieved due to the seamless acquisition of service tickets. All Kerberos 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 8 to 10 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 Kerberos 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. Thank you. 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. Thank you. First way is with one-way authentication. Here the client presents the service ticket to the server. Then 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. Now, 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 a session key from the service, from the service ticket, 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 Kerberos 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 X1. That was the very first step of our wonderful collaboration with Apple. I The version number of the package, CurveOS for Macintosh, may be a little confusion, but it does in fact include both CurveOS version 4 and version 5 libraries.

These libraries are available to a variety of application environments, including Carbon, Cocoa, and BSD command line apps. Thank you. 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 Kerberos for Macintosh 4.0 and 4.0 derivatives will be the last release for classic Mac OS, Mac OS 8 and 9. Thank you.

As John mentioned earlier, our new version included with Jaguar is Kerberos 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 Kerberos for Macintosh 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 Kerberos 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 Kerberos 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.

So the Kerberos for Macintosh 4.5 architecture is a bit different than on other Unixes or on Windows. So it's good if you write applications in layers to take a look at how it all works. The top layer we have-- we support the variety of application environments. Natively, we support the Mako 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 Kerberos 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 Unixes where the tickets are stored on disk. Even on Unixes 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 10's got the latest version. We use Mach IPC to communicate between the framework and the server. We also have the Kerberos login server, which presents the UI that allows the user to enter a username, change the realm, and enter the password.

So the Kerberos version 4 libraries include KClient 3.1. KClient is an API for Kerberos 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 then also new version 3 APIs, which I know some applications have started to support.

Underneath KClient, we have the Cygnus Kerberos version 4 implementation. It's the last release from Cygnus and includes a variety of changes to support the Kerberos login library. Okay. 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. We have put a lot of effort to try to make sure that we have a now 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 Kerberos 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're writing, you want to support Kerberos version 5, you use GSS as the API to access it.

Now, since we're talking about V5, we get asked about Microsoft interoperability all the time. Active Directory can, in fact, be used as the Kerberos V5 KDC to Mac OS X and Kerberos clients. We're actually very compatible with them on the wire. Microsoft actually spends a lot of time to make sure that they are compatible on the wire and their Kerberos V5 usage.

Microsoft promotes two application-level APIs to their Windows developers, and they vary the API depending on where the application vendor is coming from. The first is called SPNEGO, or Simple Protected GSS API Negotiation Mechanism. Gotta love the IETF. Unfortunately, this one currently has no counterpart on Mac OS X. Microsoft recommends this API to Windows application vendors who want to Kerberize their protocol, but there is no standard already out there for the Kerberized version of that protocol. On the other hand, they also have the security support provider API called SSPI. This, if you're a Windows application developer and you want to corporize your application, your protocol, and there's already a standard for this out in the Internet, in ITF, this is the API they recommend to you. Fortunately, for everyone involved, this API is very heavily based off the GSS API. And, in fact, Microsoft publishes a document comparing SSPI to GSS API, allowing you to more easily support both of the APIs in your application. In fact, it's possible to write a GSS shim on top of SSPI.

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 on 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 Kerberos app that needs direct manipulation of the credentials, you would write to the credential cache API. Bye.

The Kerberos 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 to use 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.

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. It also allows settings for defaults in the login library. You may notice on your Jaguar CDs that 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 KClient or GSS. Yes? Then you figure out how to connect the Kerberos APIs to the protocol.

This usually means that the data returned by the Kerberos APIs need to be massaged into a form for the Internet protocol. Thank you all. 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. Thanks. 1 To support v4, you follow a generic process for Kerberos. First, you want to set up a session, a new client session.

Then you want to do authenticate for the service. You do that with KClient getAuthenticatorForService. And then you want it for mutual auth. You call KClient verify protected service reply to check the reply from the server. FTP, Kerberides FTP, supports encryption of the data stream. The user can actually toggle it on and off on the fly. In this, we use KClient encrypt and KClient decrypt. 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 Kerberos to base internet protocols.

GSS API, we had to call, and you can see different folks design 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. And just like with v4, connecting the API to the protocol is through base64 encoding. Thank you.

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. The address is listed there. [email protected]. However, if you have bugs you want to report against the Kerberos in Jaguar, please report them to Apple. Many of the mailing lists involving Kerberos out there tend to be open in public. You're not supposed to be commenting about Jaguar until it's released and they open in public. Please report them to Apple. That 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. If you want to, the predominant place you might want to get on if you would like help in Kerberos 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 MacDev team directly at [email protected].

Good place for hunting down Internet RFCs to find out what already has a Kerberized Protocol Standard is 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 Kerberos is also gateway with [email protected]. And actually, it 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 on Usenet.

If you have any questions concerning Apple's use of Kerberos in Mac OS X, you can contact Tom Weyer. If you have questions pertaining to the Kerberos itself in Jaguar, you can contact myself or MacDev. And if you have any questions about security other than Kerberos, you can contact Craig Keithley.