So what is network authentication? Well, authentication is proof of identity. So you can think of, for example, if you have a badge where you work, when you present that badge to a reader, that's a form of authentication because you're proving that you are who the badge indicates that you are because you have possession of that badge.

So we need to keep in mind that this is not the same thing as authorization. It sounds very similar, but authorization is actually whether you can access a particular service or not. So in the case of the badge, it could be that I have an Apple badge, but I still don't have access to the super secret hardware lab where all the new prototypes are because I'm just a lowly software engineer.

So I can successfully authenticate, but I'm not authorized for particular services. Another thing, once we think about this on the network, the first thing you may think of doing is just sending the username and password that the user types in into your dialog directly across the network. But that's kind of a bad idea because you can't trust the network in general. There could be, you know, the server that you're connecting to may not be what you think it is.

There could be someone interposing between you and the actual service that you're using. Or, you know, just using TCP dump to sniff your network traffic. TCP dump is part of every Mac OS X machine. And they could have a hardware sniffer on the network. So you have to assume that the network is insecure.

And there's three main problems that we want to solve with network authentication. First of all, we need to prove the user's identity to the service securely. And then we also need to prove the server's identity to the user. That goes back to what I was talking about where you're not sure if the server that you're connecting to is what you think it is.

So if you have some way independent of the network stack to prove to the client what it is, that gives you a lot more confidence in using that service. And finally, when you're dealing with network authentication, you want to avoid asking the user to enter their password over and over and over again. But also, you don't want to necessarily always store it somewhere because that could be insecure. So we need a better solution to that.

So the next step beyond just sending the password in the clear would be to do a challenge response authentication. So the sequence goes something like this. Here we have a client and a server. And first, the client could send the username to the server. The server would respond with a random challenge.

And finally, the client sends back a response. The response is a function of the challenge and the password, and it could also incorporate the username, maybe other information. The other thing to keep in mind here is actually in some authentication methods, the challenge is actually sent before the username. So depending upon what auth method we're talking about, it might be a little different, but that's the basic idea.

And Apple has something called Password Server, which we've had in Mac OS X Server since 10.2, and that is our solution for challenge response authentication. It supports a wide variety of authentication methods. It's based on the Simple Authentication and Security Layer, or SASL, developed by Carnegie Mellon, which is a library that allows you to abstract these various challenge response authentication methods and provides a lot of code to do that and make it easier. It's based on the Simple Authentication and Security Layer, or SASSL, developed by Carnegie Mellon, which is a library that allows you to abstract these various challenge response authentication methods and provides a lot of code to do that and make it easier.

And the final point here, we call the password server the Roach Motel of passwords. So passwords check in, but they don't check out. There's no way to, using that password server protocol, to harvest the passwords back. All you can do is do an authentication through some secure challenge response authentication method or change the password or set various options.

So the authentication methods I was talking about here, here's some examples. We have MD5 Digest, CRAM MD5, NT Land Manager, and so on. You may have seen these before, but depending upon which service you're talking about, there may be one or two auth methods that are typically used by that service. And these sort of came up over the years. So we just put all of them into Password Server. So all these things are supported in Password Server, and we can work with a single password across all these services on Mac OS X Server.

So let's look at an example password server authentication, the sequence that we would go through. You have four machines here. There's the client, the Panther server, directory server, and a password server. And in some cases, maybe the directory server and the password server might be the same machine. That's the typical configuration, but it could be different. So for purposes of this illustration, we're going to keep them separate.

So first, the client's going to contact the service and send the various information about what user they're doing and potentially the response to the challenge and so on. Then once the server has the user name, it's going to-- oh, wait. OK. The arrow's going the wrong way. So the server looks up the user record in the directory server and then gets a response back. So it finds the user record. And the user record will have an authentication authority attribute that indicates it's a password server user.

So at that point, the server conducts authentication, sort of a pass-through authentication against the password server. From the perspective of the client, none of this is really important. But that's the sequence of steps. So once that password server authentication from the service happens, then you have access to the service.

Okay, so what is Kerbero? How many people here know about Kerbero? Okay, everybody almost. But I'll go through this anyway for those of you who are new to Kerbero because it's important. So Kerbero is a secure network authentication protocol. It doesn't deal with authorization, which we talked about before, but it's for authentication.

It was developed at MIT in the 1980s, and there's actually a couple of versions in use. There's Kerbero V4, which was the initial version, and that has some issues, some security issues and problems with it. So Kerbero V5 was the solution to the various issues with Kerbero V4, and that's really what Apple is encouraging everyone to go with.

V4 is primarily around for legacy deployments, and in most cases, anything that's using V4 is also using V5. So they just have a few applications that are still on V4, and the rest of the stuff runs on V5. So when you set up an open directory master, for example, we're just setting up Kerbero V5, and we're doing everything with Kerbero V5. Thank you.

There's implementations available on various platforms throughout the industry. So it's not just one vendor, it's a standard, which is important. And it provides solutions to those three problems that I talked about earlier. It proves the user's identity to the server securely. It also proves the server's identity to the client.

And it provides what we call single sign-on. So a single password dialogue when you log in at the beginning of the day can unlock everything for that entire day's session. Anything that's using Kerbero can take advantage of that and still be secure, not just replaying the password constantly to get that feature. So given all of these strengths, Apple is adopting Kerbero throughout Mac OS X.

So I know a lot of this is review for most of you who know about Kerbero, but I'll just go through it quickly. Some definitions. So a Realm is a Kerbero namespace. It's sort of the Kerbero version of a domain or... and I will be talking about the different versions of Kerbero.

Then we have a principle. There's actually two kinds of principles. So there could be a user principle or a service principle. These are entities in the Kerberoos database. So a user principle corresponds to a user, a service principle corresponds to a service. You can also have a host principle for a particular machine on the network.

and you have either user at the realm or service type slash host name at the realm as the style of name there. And we have the Key Distribution Center. This is the server that provides the, this is the Kerbero server. So it handles all of the transactions for sending the various authentication tokens around.

We actually call those tickets. So we have a ticket as the name for an authentication token or credential. And this is used instead of a password. So when you first connect to a service, all you're handed is the ticket and then it verifies the ticket. And it has an expiration date, so any ticket that you get can only potentially be compromised for a finite amount of time and then it's expired and no one's going to honor it anymore.

The ticket granting ticket is a special kind of ticket, which is what provides single sign-on. So when you first log in at the Kerbero dialogue, you get a TGT and then that TGT is used to later get other tickets for various services. And that can be done transparently as long as the TGT is still valid.

And the service ticket, which I mentioned already, authenticates the user to a service, and that's granted as long as you have a valid TGT and the service principal name provided from the client. So, here's another example diagram. We've got the client and the KDC in the middle and then the server.

So first, the client requests a TGT. This is assuming that you're coming to the machine and you don't yet have a TGT. And then the TGT is returned with a client key and the client has a TGT. And then some point later, the client wants to access a service.

sends the TGT and a request for a service ticket to the KDC. It gets back the service ticket. So now it has the TGT and the service ticket. At this point, it can contact the server. So it sends the service ticket to the server, and then the server verifies that and responds and allows access to the service.

One thing to note here is that the server actually doesn't have to contact the KDC to verify the ticket because it has a service principle, which is a shared secret between the KDC and the server. So that means there's part of the ticket which is encrypted by that service key or the service principle, and then it can verify that it decrypts properly.

So with all of these great things about Kerbero, you have to wonder why hasn't it caught on in more than the areas that it has? Why is it not used everywhere? There's a few barriers to Kerbero adoption, and we tried to address all of these in Panther. The first one, it requires you to deploy KDC. So that usually meant a lot of work, and it wasn't really easy to do.

In Panther, we ship with a full KDC. It's set up by default whenever you set up an Open Directory master, and it's just a matter of picking one menu item in server admin to do it and entering a username and password to set it up. So it's really simple.

Another issue with Kerbero is how do you integrate it with the directory server? And there's a lot of times that would be a site-specific decision. But in Panther, we've integrated all the open directory tools with it and we've used the authentication authority attribute and come up with a standard way of integrating Kerbero into the directory and doing that mapping between the two.

Another problem is a lack of integrated user account management. What this means is, let's say that you're deploying Kerbero and LDAP together. What would you do when you set that up? Well, every time you create a record in LDAP, you also need a user principle to go with it. But the tools that you use to do that might be completely different.

And so it would be kind of a difficult thing to do and you'd have to go back and forth between different tools. Well, in Panther, Workgroup Manager automatically creates the user principles as you create user records. So as long as you have Open Directory set up, whenever you create a user, it's going to get a Kerbero's principle created for it.

Another problem is the service and host principles are kind of difficult to manage. You have to have all of the servers that are in your network be registered in the KDC so that they have that shared secret for the system to work. And that could be potentially a difficult thing to manage.

So we compose those in Panther Server Configuration Tools. And another thing that we've done is we actually allow you to put that information encrypted into the directory and use the directory as a mechanism to distribute those service principles. So you can have potentially the directory administrator create that record and then a completely different person who's the administrator of your file server can later grab that record, enter a password, their password in order to decrypt that record. And that's all they need to do to set up Kerbero on that server.

Another problem is you'd have to do command line level configuration of the Kerbero clients or potentially make an installer package that has your config file in it to distribute out to all of your users. And then you have to go through the trouble of installing that everywhere, copying the file, which is kind of a problem. In Panther, we auto-configure Kerbero.

All we do is we just put a record in the directory, and the Panther and later clients are going to look for that. So if they see that Kerbero's client record, they'll just generate the Edge UMIT Kerbero's file from it. And so you can centrally configure how you want the clients to be using Kerbero's rather than having to do it over and over again.

Another problem which you have, which is very important, is in a traditional Kerbero set up, you would have no support for legacy network authentication. What I mean by legacy network authentication is at the beginning I was talking about all these challenge response protocols, authentication methods that are used by various protocols.

And normally you'd have to have all of your network services be on Kerbero in order to integrate. Well, what we've done So, the idea in Panther is to actually integrate Kerbero with password server. So, there's one password between Kerbero and password server. Whenever you change one, it syncs to the other.

So, you have access to all the great features of Kerbero as well as continue to support the legacy network authentication, which is important if you have, say, a remote worker that's not going to be set up for Kerbero, but they do have -- they need to have access to a file server. So, you might want to just allow them to do a traditional authentication for that. Or if they have an older platform that they can't upgrade to be able to support Kerbero, they can still do the older authentication methods.

So going back through the benefits again, we have single sign-on, which is very convenient, but it's still secure. We're not just replaying passwords. We have mutual authentication, so you can trust when you're using a Kerberized service that you are getting the same server that you thought it was before.

And another very important thing is client and server programs are out of the business of dealing with passwords. So they're just passing tickets around. And all of the prompting for passwords is handled by the Kerberoes framework. So your application doesn't have to care about that. And at some point in the future, it may not be prompting for a password or it might be a password plus something else. There might be a smart card or some biometric data that's being used.

As long as that process gets a TGT, everything after that that's Kerberized will pick up that new non-password based authentication for free. So we really wanna get everything onto Kerberoes so we have this kind of flexibility to expand in that area. As I said before, Kerberoes is secure and it's cross-platform.

So some more features that we have in Panther. Once we had Kerbero and password server to really make this something useful to deploy, we added secure multi-master replication support. So what that means is you can have a bunch of machines all with the same password data and you can authenticate against any one of them. You can change your password against any one of them and that change will propagate throughout the system.

So there's no single point of failure there and the clients were also updated so that they would automatically fail over to whatever's available. So the client, you know, the user won't even necessarily know that the password server they were talking to before happens to be down at the moment and used a different one this time.

There's support for password policies, so you can force people to change their password or specify what the minimum length is and so on. And that can be done globally and on a per-user basis. We added the PW Policy command line tool. And this is just providing the same functionality that we had in Workgroup Manager and the Server Admin Open Directory plugin, but at the command line level. So you can take advantage of that from a script or if you're administering through SSH, you can do everything you need to do.

And don't forget, Crypt is dead. Okay, no applause, but anyway, Crypt is still dead. And that was accomplished in Panther. We actually already had password server in Jaguar, but in Panther, we replaced the local users with their Crypt passwords with ShadowHash. And then we used Kerbero and password server for network users. So here's a screenshot of what the global password policy looks like in server admin. So there's all kinds of things you can set there. And then we have the per user password policy, which is in Workgroup Manager.

So the message we want you to get here is that Apple's providing a complete solution. We have Kerbero for security, mutual authentication, and single sign-on support. Password server supports your legacy needs. All of this is done with replication and client-side failover. We've got the administration tools both at the GUI level and command line.

And we're doing a lot of auto-configuration for you so that it's really easy to add a system to use Kerbero. You get the Kerbero for free as long as you can connect to the LDAP server. So whatever you need to do to get LDAP is all you need to use Kerbero. Which if you're using DHCP, it might be nothing at all. So at this point, I'd like to bring up Leland Wallace to talk about our changes in Tiger.

Thanks, Jason. I'd like to talk about what we've done with authentication in Tiger here. First thing we've done is, as many people have said before, added password server support, or actually added Intel MV2 support to password server. We've added some password policy enforcement between the password server and the KDC. Added Spanago for Active Directory support with SMB and also with... It was a pain. And we've added some new Kerberized services, so we're continuing upon our drive to Kerberize the entire OS.

So every open directory server has, or every password server has a Kerbero's principle and it's used to sync up password changes between both the KDC and the password server. And we've added for Tiger, we've added password policies in the password server are now honored by the KDC as our password and account expirations.

Some of the new services that we've got, and I'll start with the old services, the existing services, AFP, FTP, the mail troika there, and SSH and login window are the old ones that we've got in Panther. We've added LDAP, Espanago for the web, both client and server side, and the SMB stuff for Tiger.

I'd like to talk, just give a quick overview of what kind of command line tools we have for Kerbero now. Starting out, these are the things that our single sign-on solutions are built on. MIT's got, you know, KADMIN, KDB5 UTIL, and KT UTIL. Well, the Apple, we've got SLAP Config, SSO UTIL, and a bunch of others there. They've all got man pages. They're all at least reasonably intelligible, I think. They are.

The MIT tools, KAdmin is used to deal with server principles and user principles and policies. KDB5 Util looks at the Kerbero database just as a database, dumping it, restoring it, things like that. KT Util manages the key tabs that you need on the servers. There are other tools like KNet, K-List, K-Destroy. Those are user level things to be able to manage your ticket cash and stuff from the command line.

The Apple tools, slap config is sort of the high level front end of it all. It works with setting up the open directory, setting up the KDC and doing a bunch of other things. A lot of good stuff is in the slap config log. If you are having trouble with things, slap config log is one of the first places to look.

Let's see. Kerbero auto-config, this is the command line tool which is run whenever the search policy changes on the clients and that provides our client auto-config stuff. That's where it writes the edu.mit.kerbero file out. KDC setup creates the Kerbero's client records in the directory and sets up the KDC.

Kerberos Service Setup sets up the Kerbero services and SSO Util It's another high-level tool, and it allows you to do a lot of things in configuring servers this way and also generating the stored config that Jason was alluding to earlier to allow the network administrator to delegate to delegate the responsibility of Kerberizing a specific server to a server admin rather than having to do it all on themselves.

Setting it up, we prefer you to use the GUI to set up Kerbero. It's just selecting the Open Directory master from the pop-up menu. You can also use command line tools. The folks at AFP 548, you know you're out there someplace, have done an excellent job. There's nothing I can add to what you've said.

You can do it by hand, looking at the instructions in the Kerbero admin guide. It's a little bit painful. That's why we're doing all of this. And when you want to integrate it into an existing Kerbero setup, There are some things that you can do to an existing LDAP server, adding a Kerbero client record, to be able to get some of the benefits of our single sign-on stuff. You can add the Kerbero client record that all your Panther clients will automatically configure for Kerbero, create Kerbero auth authorities for your users, and they'll all get TGTs on login.

Setting up a Kerberoz server. You know, you've got just one network admin, one person who knows the master password for the KDC database and such, and lots of servers. It's a real pain if you have to go out to each server and set it up manually. So what we've done is we've allowed the network administrator to delegate part of that setup to you.

Network Administrator has got to create a computer record and then attaches a Kerbero record to that, or a secure config record we call it. And that contains the key tab file, a list of authorized users, and some other stuff. And it's encrypted all to a set of admins that you've delegated to.

The delegated admin then grabs that record and decrypts it and then that installs the key tab file and Kerberizes the services. This will also work now with Active Directory. The delegated admin then grabs that record and decrypts it and then that installs the key tab file and Kerberizes the services.

This will also work now with Active Directory. KDC setup is the thing that creates the Kerbero client and Kerbero KDC records. Kerbero client record is again used for client setup, whereas the Kerbero KDC record is used when you are replicating, setting up replicated KDCs. Kerbero auto-config pulls that data out of the Kerbero client record and puts it onto your desk there.

Then the SSO util is used to create the secure config records that, or the SSO util generate config command creates the secure config records for the, which allow the network administrator to delegate to the server administrator and then SSO util use config takes that same configuration and then installs it in a server and Kerberos the server.

The Kerbero's client record, I don't know if everyone can see that, is a pretty straightforward XML translation of the edu.mid.kerberos file. If you need to edit this by hand, it's not all that difficult. You add domain realm mappings, the various defaults, realms, and all of the other major tags in the edu.mid.kerberos file are supported and will be read out just fine. The Kerbero KDC record is, since we don't edit this at all, is just a more literal translation of the KDC.conf record that you find down next to the Kerbero database stuff.

And another useful, useful record type or actually it's a property I think, isn't it? It's an attribute type. It's the Kerbero's auth authority. It's used by login window to determine whether or not this user is Kerberized and that helps it get the TGT and also when you're changing a password through system prefs. It looks like this. It starts with the Kerbero 5 and there's some optional fields, the GUID, the principal name. The Realm name is not optional and the Realm key is optional.

At minimum, we want to see Kerbero's 5 and then the Realm. And from that, our code can figure out that the user's principal name is going to be used, the first short name at the Realm name. Ideally, we would like to see the actual user principle in that auth authority. It would be a good idea if you're creating these on your own to add the principle name as an additional short name. It will make some things easier in the future.

I'd like to talk now about using Kerbero in your apps. Things you need for Kerbero development are, of course, a KDC. In this case, we would like you to use a Mac OS X Server, a Mac OS X client, your server processes and your client processes. I'd like to talk about what you need to do when you have an existing protocol.

If you're writing a new FTP client, say, or a new mail client, you'd need to think about this. If you're writing a completely new protocol, there are some other things you need to think about. They're just stuff you need to decide. I'd like to give you a demo of how, or not a demo, but an explanation of how you use GSS, which is Generic Security Services API, to do a Kerbero authentication, and then talk about things that you no longer need to worry about once you've Kerberized your authentication.

So if you've got an existing protocol, if it's HTTP based, use what we've got in Foundation and CF Network. Some of that's automatically done for you. You'll automatically get Espanago support without having to do anything at all, as I recall. If not, then look into SASL. There's a good RFC on it, and it's fairly widely supported. For other protocols, FTP, POP, IMAP, SSH, there's all RFCs and standards on how you are supposed to do those things. Don't invent anything you don't have to. It's not worth the trouble.

For new protocol, again, if you're HTTP based, use CF Network. You'll get what you need for free. Use SASL with a GSS mechanism if HTTP doesn't work for you. If you need to roll your own, use the GSS APIs. They make things very easy. And if that winds up being too limiting, go with the Curb 5 APIs there.

One of the things you need to decide if you're creating a new protocol, you need to decide on the service type. Here, in this case, it's webcam. And the rest of that is just the service principal name. Then you need to find a way for the client to construct the principal name.

It needs, you know, it can either get it implicitly from the DNS address of the server, like in the way FTP or SSH does. Yeah, that leaves you dependent upon DNS, which can either be a good thing or a bad thing. Or you can do it explicitly, getting it from a secure source such as the directory.

And that's typically a little bit more friendly, but there's more infrastructure required. You've got to actually work at things. So here's a simple Kerbero authentication using GSS, and this is after the user's gotten their TGT. So the first thing's first, the client needs to figure out what the service principle is, and then it calls GSS import name on that.

After that, it calls GSS and its security context. That goes and talks to the KDC, asks for a service ticket. Service ticket comes back. The client then sends that service ticket off to the server. Server calls GSS Accept Security Context. And that pulls the server's key out of the key tab file.

Server returns the GSS token. At this point, the client and the server have both been authenticated to one another. Note that the server has only had to make one call and the client has only had to make three calls now because the token is passed back into GSS in its security context.

The server then needs to do an additional step of checking the authorization. That would be checking the client principal against an ACL or something like that and checking to see that the service principal that you sent was indeed the service principal of the server you actually are talking to.

And then to get an encrypted data stream between the two, between the client and the server, you can use the gsswrap and gssunwrap commands, gsswrap encrypts, gssunwrap decrypts. It's pretty much just that simple. So in review here, on the client side, you call GSS import name and GSS in its security context. On the server side, you accept that context. And then on the client side, you pass the token that comes back into GSS in its security context. You can actually go around this loop several times if there's an authentication mechanism that actually needs it.

Kerbero does not at this point. Then the server side needs to check the authorization against an ACL or what have you. And then GSS wrap and unwrap to provide your encrypted data transfer. So that's pretty much all there is for GSS API. API. And we've got sample code. It will be available for download. And it shows exactly how to do this stuff. And it's rather simple.

A fair number of things that you no longer need to worry about, Jason alluded to some of them earlier. You're out of the business of caring about the password. If the user doesn't have the TGT, the library will prompt for it. If new auth methods are available, those will be taken care of before you even get called. Don't have to worry about tickets expiring.

The expiring tickets are handled by the library. If you're worried about single points of failure and you've set up your, you know, as an app developer, you don't need to worry that there may be only one KDC. That's all taken care of in the... In the infrastructure there, Kerbero does failover very well and Open Directory does replication very well.

In summary, Apple's investing heavily in Kerbero. This is the way we're going. We ship the MIT KDC and Kerbero client. We are committed to keeping that open, not taking anything proprietary here. If you're writing a new authentication method, talk to the Kerbero folks, work with it through that community, get it put into Kerbero, and then Everybody will be able to take advantage of it.

As a client developer, any new auth methods that are available, you get for free because you've Kerberized. And Kerbero is an Apple's future in yours. That's it. That's what we're doing. So we've got some very good things there on more information on Kerberoes, more information on Kerberoes protocols, and there's the URL for the AFP548's bit of information there.