So to understand what Kerberos is, we're going to look at the definition of Kerberos, and we're going to take it out of the O'Reilly book, The Definite Guide to Kerberos. And they have a very nice definition there. This Kerberos is a network authentication protocol that provides a secure, single, sign-on, trusted, third-party, mutual authentication service. It's a little bit of a mouthful, so let's break it down to buzzword instead.

So we get authentication, trusted third party, mule authentication, single sign-on, secure, and protocol. So let's go through all these words and see what it actually means and take some example out from both the computer world and the real world, how this all fit together and how they relate to Kerberos.

So first, authentication. Authentication is to prove your identity. For example, when you go to a supermarket and pay by a check, you prove your identity by showing your driver's license. However, just by showing your driver's license doesn't mean that you are allowed to use the check, and that's the second bullet. Authentication is not authorization.

Just because you claim that you are a person and you can prove it doesn't mean that you're allowed to access all the resources or what you wanted to get. For example, when you log into a file server, you will only accept your files on the file server or the groups that you belong to on the file server, but not all files on the file server.

Trusted third party. Kerberos is a trusted third party solution. Authentication is done through a central server. In the case of a driver's license, the trusted third party is DMV, the party that issued the driver's license to you. In the computer world, a trusted third party can be the certificate CAs. But unlike the CA system or certificate system, Kerberos is using shared keys instead of public and private keys. So Kerberos is using symmetric crypto.

Kerberos is also providing mutual authentication. And it's two parts. First, client is usually proving the identity of the server. This is usually what you think about when you're talking about logins. But you also want to prove that the server proves identity to you. You don't want to hand over your check to some random person you find in the aisle.

You want to have the right look to them so you know that you're actually handing over your money to the right person. And the same thing in the computer world. You don't want to act on data that you got from some random server. Or you don't want to send up some random data or your secret data to a server that you trust.

So when you SSH to a machine, it will ask you for a public key and to need to verify the fingerprint there. And the second time, it will remember it. So this is the establishment of the identity of the server. And Kerberos also provided this functionality. Thank you.

Single sign-on. Kerberos allows you to log in in the morning when you get to your work, and then for about 10 hours, usually. You can use all the services in the system. And it will single sign-on into the system, so you never need to enter your username or password again. You will access all the resources. So when you got here this Monday, you showed your driver's license or your passport, and then you got your badge. And the badge is the single sign-on tokens, And with the single sign-on tokens, it allows you to get into all the session and get your swag.

There's web systems that are also used in single sign-on. You'll log into one site, and then you can access the maps or the mail and the web search. And there are many vendors that provide this kind of federation service. Kerberos is also a secure system. It never transports your passwords over the network. So you don't need to worry about exposing the password. Kerberos is also using symmetric crypto. So it's using a crypto like triple-des and AS.

It's extensible crypto, so it will be upgraded to newer versions of crypto when they're available, and users don't need to care about this. There's something will happen in the background. around. Kerberos, in addition to just provide the initial step of providing the identification step, there's also providing crypto keys for doing the second step, the part they also care about, and that's transport security. You want your data in your protocol, the part that you are providing as a developer, you want the protocol data also to be secure, and Kerberos provide that feature too. Okay.

Kerberos has been along for about, in some way or other, for about 20 years. So it's been very time tested and been seeing through a lot of problems already. So there's not really any problems going to show up in the next three, four years just because, well, we haven't thought about it before. And this is important because some time ago they installed these simplex locks and push button locks that allow you to go in through doors. And they installed them on many university campuses and high schools in the U.S. However, there was a flaw in the system. You couldn't set the key that you could choose one, two, three, four as your key. But you couldn't repeat any numbers. So you couldn't have one, one, two, three as a code. And that changed the brute force key space from about four hours to brute force a key to about ten minutes. So they had to change all the keys. And Kerberos has been through this already, so you don't need to worry about it. So don't do that. Thank you. Kerberos is a protocol. And it's just a description of a series of exchanges. But protocols can be very simple. It can be a type of a knock, knock, knock. Who's there? Orange. Orange who? Aren't you glad you bought your ticket before it chilled out?

But it can also be very complicated, like the whole IETF TCP IP stack, and, like, all of that. And Kerberos is maintained by IETF, and it's the Kerberos working group on IETF that maintains it, and it's still continuing today and improving this document. And there's many implementations of the Kerberos protocol, and MIT Kerberos is one of them, and we use it in Mac OS X. The other implementations, like the Java one, Haymdahl, There's GNU One. It's used in Windows Active Directory and many others. So it's important to have a standard protocol because that will allow you to become vendor independent and have interoperability between different implementations.

So why would you like to use Kerberos in your application or in your system? Authentication is very easy to get wrong. It seems very simple. You tell who you are to the other side, but as has been shown before, this is something that is not very easy to do. So you should really use something that has, people have thought about doing this before, and you reuse what other people have done.

Kerberos is a standardized protocol with many implementations and people working with it, so it's a secure solution. And this is important for you as a developer because it allows you to get an interoperable solution when you want to talk to other systems. And you can plug in your applications into an already existing system. system. Kerberos was designed for a hostile environment, an environment where people could insert packets into a network, and they could listen on any packet.

And Kerberos is secure in this solution. And this is something that was designed at MIT. So you have all these smart students that are trying to get better grades. So really, it needs to be secure. Kerberos also scales to millions of users and services. So you won't have the problem that Kerberos won't scale. It will scale. It's been proven before.

Kerberos never transmits passwords over the network. So you as a server, when you're using Kerberos, don't need to care about password. This is important for you and the system administrators. It is also a good thing for the user, because they only need to log in once to the system. And then they can use all these different services by just using Kerberos. And I said it was important for you as a developer, because now you don't need to maintain a username and password database. And your user will be more happy, because they don't need to have yet another system where they're maintaining password information and get all their users confused because, well, what password should I use for this system? And you need to change it every three months. And well, you have one password, one username, and that's it.

I've been talking about all passwords, but Kerberos support more than just passwords. There's also smart card support or one-time token support. So password is not the only thing that you can use. The good thing about Kerberos is that once upon a time, DES was really good. And when 20 years later, DES is kind of a yoke. It's not really secure anyway. And Kerberos adapts to newer crypto systems, and you don't need to change your application to get a new functionality of Kerberos and newer crypto. It's just that you update the crypto library and the Kerberos library, and you're all set. There's no code changes and no recompilation of the server. on your application, it just works.

So where's Kerberos used today in Mac OS X? Well, many of the application that you get with Mac OS supports Kerberos. We have the remote login, like screen sharing, SSH, Telnet, but also the file sharing protocol, the NFS, SMB, and AFP, they all support Kerberos and use it. There's also web application. The web browser all use support Kerberos, and I'm going to show it in the demo. And also the mail, mail.app, and other mail applications support Kerberos. But this is just for the Mac. But how about other operating systems? Well, we got all the Unix systems like the BSD, Solaris, Linux, and AIX, and of course, Windows Active Directory. Active Directory is a big consumer of Kerberos, and it's actually the main authentication system used here. So if you want to interrupt with AD, well, Kerberos is your only choice. There's also Novell E Directory, And Java is using Kerberos to support as part of the GAS system. And of course, Mac OS X Open Directory is using Kerberos. So this is nothing new for us.

So now we're going to have some flying tickets and describe how Kerberos works. And I'm going to go through the protocol exchanges a couple of times, and for each iteration, I'm going to get more and more into detail how it works. So let's start out with some concepts. We have a realm, and realm usually looks like a DNS name, but the spell is used uppercase letters. And this is by convention, and you should really try to use uppercase letters if you want to use Kerberos, because many applications assumes that the realm is going to be uppercase, and uppercase is for you, and you're going to be very sad if you use lowercase letters. There's two different kind of principles in Kerberos. There's the users and there's services. And they could have used the same name for these users and services, but the users usually look like, by convention, an email address with, of course, the domain part in uppercase. And the servers look like service/hostname@realm. So this is also by convention, But you don't really have any choice. This is how it works.

There is also the trusted third party in Kerberos. And that's the KDC, the key distribution center. And this is the machine that the users and the server are trusting. So this is the machine that keeps track of all the keys in the system and makes sure that the trust is correct.

I've been talking about flying tickets. Kerberos, the main data type in Kerberos is the Kerberos ticket. There's a special ticket that's called a ticket grounding ticket. This is a ticket that provides a single sign-on solution. It's going to be very obvious later what the ticket is. It's the yellowish-orange ticket in my older slides.

Users, when they log into Kerberos, is using password or other system, other initial authentication system, but usually passwords. Servers don't have passwords. They have key tabs. Basically key tabs are random generated keys stored on the server in a special key tab file. So servers do not have passwords. Right. So the ticket granting ticket is just a principle, like all the other ticket. This is special format of it. It's curvity ticketee slash realm name app realm name. So it's no special with it.

So we'll have the client and the server. So let's add the rel and the KDC. And now when the client wants to talk to the server, it starts with getting an initial ticket from the KDC. And that's the authentication service request. And then it's going to talk again to the server, the KDC. And that's to get a service ticket for the host. And that's the second step of the protocol. That's called the ticket granting service. And last, it's going to finally talk to this server. And this is called the application protocol.

And that's sending over the ticket to the application and logging into the service. So we have the client and the KDC, and we start out doing the authentication service. And this is the initial authentication and getting your ticket, granting ticket from the KDC. The server's not part of the transaction yet.

So we ask for a ticket and running ticket, and get back the ticket and running ticket and store it in the cache. And then we're going to do the second step, the ticket granting service. This is to get a service ticket to talk to this specific server. So for each server, you get a specific service ticket. So we take our ticket granting ticket, send it over to the KDC, and gets back a service ticket. Now we don't need to talk to the KDC again when we want to talk to this service until our tickets expire and we need to log in again. So we have a service ticket, and we're going to send it over to the KDC in the application call.

and it goes over and we can use our application at the server. So that's Kerberos. It's everything that it does. So let's go over this one more time. So we started with the AES Exchange, that's authentication service. And when you do network traces and stuff like that, these names will, the AES and TGS and AP, they will show up over and over again. So it's easy to figure out what part of the protocol that doesn't work or what is working and what you should concentrate your searching on what the failure is. Second step was the TGS Exchange. Third, the application exchange. So let's go through this in more detail and see what actually is sent in the tickets when you want to talk to different services.

When we ask for a ticket, granting a ticket, as a client, we send over our username that we want to, what service we want to get, and how long time we want the ticket to be valid for. Maybe we know that we're only going to use the ticket for five minutes, and then we're going to ask for five minutes because we don't want to take a granted ticket that will give us access to all the services around for 10 hours. So we only ask for five minutes.

This is a hint to the KDC. The KDC might return a ticket that is shorter-lived than we asked for. So, but we usually this is 10 hours and we'll full working day unless you're working for the slide for this Representation and then you need to log in at least twice So the Kitties C sends back this ticket-granting ticket. And it's a ticket-granting ticket, and we store it in the cache in the client.

So now the second step of the protocol, the ticket granting service. The ticket granting service, we send over what server we want to talk to, and in addition, we send over the ticket granting ticket. But you know, you can't just send over the ticket granting ticket, because then someone else might replay this to the KDC and say, "Ah, here's some data. "I want to talk to that server, "so give me a service ticket." So you add an authenticator. This was to make Kerberos tickets one-time use only. I'm going to talk about how the ticket and the authenticator works fits together later. So don't worry about that right now. We send it over to the KDC.

and we get back the service ticket. And we store it in the local cache. So now we don't need to talk for a server KDC again. So we take our ticket, and just like the KDC, we add an authenticator. And then we send over the authenticator to our server. Now the server creates a beautiful authentication token. This is to prove the server is the server we're talking to.

and it sends back to the client, and the client can verify the mutual authentication service. So we know that we're talking to the right server. And every time we want to redo this transaction to log into the server again because we tore down the network connection of that, we just take the service ticket, add the authenticator, send it over to the server, and get back to the mutual authentication. There's no need to talk to the KDC here.

So we've been talking about this simple concept. We have a client and a server, but we in engineering, we don't really trust that marketing guys. But we want to see the keynote slides they're doing. So we want to access the resources, but we don't want to have them in our system. So how do we solve that? Well, we can add another realm and then add trust between them. And this concept is called cross-realm. So you can traverse between two different realms, and you service in other systems. So I have a ticket here in engineering. It has already got a ticket, a grounding ticket. And now when it wants to talk to the server at the other end, we start with adding a trust between the two KDCs. And the trust is only for identifying users and services. So you can see that the first server is telling the other KDC, the first KDC is telling the other KDC, you know, this user I'm talking about right now is this identity. It doesn't tell you what rights you get. As I said before, Kerberos is just providing authentication and not authorization. So just identity. So the client takes the ticket granting ticket, sends it over to the KDC, gets back its special service tickets that allows it to talk to the other KDC in the other realm to send over the service ticket to that machine. and get back a service ticket. And the service ticket is for the server. So now we can just send over the service ticket to the server and get access to all the resources. And we can read the key now.

And of course, this scales to multiple hierarchies or non-hierarchical solutions. So you can add trust between two KDCs and end out there, and you can actually jump between the KDCs and the realms. So you can go from the first KDC to the second KDC, and then go through the third KDC. So Kerberos can create this complex solution on that will fit your organization.

And I've been talking about this flying tickets and flying all over the place and I've been talking about authenticators. So let's look on how they actually look like. The ticket that I'm going to look at first is a ticket granting ticket. But it could be any service ticket that I'm going to show you. So the name of the service that I'm using this ticket is for is instant in the plain text of the ticket. And in the bottom of the ticket is some data that's encrypted with the server's long-term key. That's the key inside the key tab.

And with the long-term key, you can decrypt the data inside it. And inside the data, there's a client name, so the server who know who the client is. There's also expiration time, and that's a fixed time in the future, or hopefully for the user, so they can access the resources. There's also a session key, and the session key is shared between the user and the service. So you have to remember this part of the ticket is only readable to the server. So the user can't read this. So how do the user get hold of the session key?

In the authentication service reply, that's the first transaction you did when you talked to the server when you logged in. Then they added some more data to that ticket. So you got back in the user's ticket for use, and this is ticket, and so some more data. And this other encrypted data is encrypted with the user's password, and we can decrypt this and see what's inside it. And it's pretty much the same thing as it was inside a ticket. It was a server that they wanted to talk to. and the expiration time, and the same session key that's inside the ticket. So now the server and the client is sharing the same key.

So let's look on the service ticket again. We have this part of the tickets that's encrypted with the service long-term key, and we added the authenticator to make it one-time use only so anybody can't steal the ticket off the network. So we add on the authenticator, and inside the authenticator, the client is putting its name, and that will match with the thing that's inside the service ticket, or the ticket granting ticket in this case, and a timestamp that's now. And it's only valid for about five minutes, plus two and a half minute. So... That's what makes Kerberos time sensitive. The last step is adding a subkey. The subkey is important because it allows the protocol for each authentication you're doing to use a new key to authenticate through a service. And for each connection you do to the service, you get new fresh keys that are not using the session key. So you won't reuse the session key, and the session key is only used to protect the Kerberos Exchange.

And we take the session key and encrypt the authenticator, and the main data of the ticket is encrypted with this long-term key. So now we have a fully protected ticket-granting ticket with an authenticator, and this is what makes Kerberos secure. So let's demo Kerberos and see how it works. The demo, please.

So I'm going to show you using a web browser talking to a Kerberized web server. And when I start my Safari, I get a question that I want to authorize against the web server. So I pull up a terminal. and kin it as a stem. And log in as stem. And then I can check my credential cache on local machine to see what tickets I have. And the first ticket I get is a ticket granting ticket. So now I can go back to my web browser and reload. And I'm logged in.

and the web server knew who I am. And when we go back to look at the credential cache again with K-List, we can see that I got HTTP service ticket. And of course, if I destroy the oldest tickets with K-Destroy, So no ticket. And going back to the Safari again and reloading, I'm not logging in anymore. So let's go back to the presentation.

So I've been talking about this, about how Recurbers is used in Mac OS X. It's been in Mac OS X since 10.0. It's also, it's the primary authentication mechanism, open directory. And Kerberos is supported in many applications in Mac OS X. For example, the OLIFI sharing, printer sharing, screen sharing, and many of the applications that you get with Mac OS X. So let's talk about the new features that I would introduce with Leopard. The first is a local KDC.

In a typical managed environment, then you have the KDC, the server, and the client. And in Leopard, we combine them into one service, the local KDC. And all these services are running on one machine, because that's usually how it looks like in your environment. You have one machine.

In the local KDC, the realm name is actually lkdc.trial1, and there's a big number of hex digits, and that's the signature or the checksum of a certificate that's generated the first time your machine starts the KDC and needs to use this service. Uh, But users don't want to type in this long name. So the Realm discovery to find out what Realm machine is talking or using is done through Bonjour.

So we have this local KDC. And to make this simpler, I'm going to name this KDC to Stamps, Stamps iMac, because, well, so we have a name. And Stamps has a friend, Owl. And on our computer, there's some screen sharing or file sharing we want to do. So Stan wants to take a random ticket. He gets a ticket, random ticket. He wants a service ticket. He gets a service ticket. And he can run the file sharing on all his computer. So how do we get this to work? Well, if he wants to use other services, he can just get service ticket for those services and access them. They don't need to log in again.

So on local KDC, all Macs today on Leopard is running Kerberos KDC if they're using printer sharing or screen sharing or file sharing. And it's used to log in when you're using local accounts on the machine, but not when you're using the equivalent of an open directory or AD. me.

So in the demo I did just recently, I was kind of cheating, because this didn't look like that, actually, when you try to use it yourself. So you had Stam's iMac, and he tried to use the service on the other machine, so I got a ticket running ticket there. And when he got back the ticket running ticket, he got a login window. And he had to remember the username. He's on the other machine. And the password there, I don't know, was something simple. I think it was like my username.

So it's not really secure, and it's kind of easy to brute force these solutions, and you have to remember password for all different services. So can we do this better? Yeah, we could use certificates. There's no need to remember them. They're like data blobs that you store on your computer, and there's no simple passwords, so you don't need to bother about that. And there's also fewer dialogues because, well, we have this certificate that you can pull up from the keychain and you just use it. So the user don't need to worry about all the Android passwords and stuff like that. But there are some problems with it.

They are difficult to manage. You need to be a computer expert to create certificates. Well, at least create them correctly. And also you need to distribute your certificates between all the computers and stuff like that. So we want to make this a little bit simpler. So we can do that by adding the.mac into the whole equation. So with.mac, we can make this solution really simple.

So in this example, we have joined both Stam and IELTS computer to the DocMath service. So that's basically all the things that we need to do from the beginning. And now we just created a sharing-only account for Stam on IELTS computer. And we do that by going into the Preference panel and adding Stam's name, adding a sharing-only account for Stam first. And then we add Stam's.mag account. And that's-- we stammers and we enter it here.

And what that does in the background is, first, when Stam joined his computer to.Mac, he actually downloaded a certificate and a private key into his machine. And then when we created our computer on our iMac, we downloaded a certificate from the.Mac and installed it on our iMac. And these certificates are automatically updated whenever they change this on the.Mac service. So we don't need to worry about that.

So we got the creation and the distribution problem solved. And now-- We don't need to use.mac anymore, so you can use it on your private network over a FireWire cable and access resources. So when asking for a ticket granting ticket, we encrypt the reply using the certificate, and then we can get the service ticket as usual and just get service ticket and get to our file sharing. So let's demo this. 10 more please On both of the demo, one of the demo machines I'm working is now a Stamps computer and I want to access resources on iOS computer. So I open the finder and I can find iOS iMac here. And as you can see, I'm logged in as Stamerson at.mac. And if I go to my terminal, in the background, it actually got and fetched me a ticket, a running ticket for this Stam. And that's the hash of them certificate in the darkness service on this other weird realm name. And that's actually realm name of iOS iMac. And we've got a ticket running ticket. And there's also probe AFP server to see what resources we have on that machine. So let's see if we can do screen sharing. oh, we got the machine already there. And we have nice family photos on our computer. And we can access the resources that we want. And when we go back to the credential list, we see that we have a VNC ticket as we use for screen sharing.

So let's get back to the presentation. So now, how can you use Kerberos in your presentation? Oh, sorry, in your application. Kerberos is supported for managed environment. It's not using the.max service. And using Kerberos in the application is usually using GSS API. And GSS API is both an abstraction of protocol, a protocol itself, and a program interface. So it's many things that are the same name. And the GSS API is maintained by the IETF in the Kitten working groups.

YesSCPI, as the name says, is a generic interface, so it supports more than just Kerberos. It's supporting Spnego, and that's for negotiating different mechanisms, but also NTLM for legacy applications. questions. As an application writer, you want to use Kerberos when you want to leverage existing Kerberos infrastructure that exists already today. And this enables you to not need to maintain password or user information specific for these users in your application.

And it's also when you want to use cross-trail support between different environments, like your AD systems and your Macs. Also, you want to use Kerberos and ESS CPI when you have standard protocols like IMAP or SMTP submit or something like that, that requires use of Kerberos, so you don't really have a choice.

GSS API is a somewhat complicated protocol, but it can be easily broken down into some key concepts. So first we have the initiator, and that's the client. That's the machine that sends the first packet. And it sends it over to the acceptor. That's the server, usually. It could actually be the opposite, but it doesn't matter. The server can be the initiator, but in the common case, the client is the initiator. And together, the client and the server build a security context.

And the security context, the building of it, is actually the login into this service. And when you've logged into the service, then you can use the per message services. The per message services are encryption and integrity controls of messages. And to build these security context and application context, you pass around tokens between the two different parties, the initiator and the acceptor. And the tokens are, of course, called the context tokens for the context building and the per message token for the message building.

So we have the initiator and the acceptor. And the first thing that the initiator does is call it in its context. And it passes in the service name you want to talk to. And in the background, the library goes and talks to the KDC and gets the ticket-cramming ticket.

So this is nothing your application need to care about. However, the user needs to be logged into the system already, so they already have a ticket, re-inning ticket. And this is nothing that CSS API solves for you, but rather some other support libraries. And then it creates a token and sends it over to the server. And that's an AP exchange, application protocol exchange. And the server reads in the token using accept-tag context. Thanks.

And usually there's only one round trip. The packet goes from the client over through you The security context, the server needs to check who the user is, what the user name is, what the server's name is, if it's a multi-home server. It also needs to check how long time this context is valid for, and then it needs to check if it's actually using Kerberos or some other mechanism, because it doesn't maybe know how to translate the username into a local account so they can actually authenticate the machine. And this is the part where you do the authorization.

And then when you want to transfer data, your application protocol, and that's when you come in with your protocol, is you can wrap packets and unwrap them and send them back and forth between the server how many times you want. And the function are called wrap and unwrap. And they both support integrity and confidelity, so both signing and encryption.

and can go both ways. And when we're done, we can free our local resources using delete_text_context, and that frees all the local resources on both ends, so it should be called on both ends. Let's look at some code. And the code is on the web page associated with this session. So you can find it there.

And this is the client part. We have a little nice while loop there. It goes around. And we start with calling just as in its context. And it takes an input token, and it sends back an output token. And when we get the output token from this function, we always send it over to the server, even in case of an error, because that can be processed in the server and figure out what the client actually did when it failed. So figure it all out. In case we get an error, we bail out and free up all the resources we want to have.

And then if we need to continue another loop, which is always the case in the client, at least the first time, then we read the token from the server, And when we've got the token, we loop around again and do the same thing again. And when we built the security context, this flag won't be set, just as continue needed won't be set in the return value. So now we need to verify that the mechanism we tried to use is actually returning the correct flags on the context because we are only asking for what services we want. So we need to check that the services that we got back is actually what we asked for. The server end of this code kind of look the same way.

But we don't call the init-tag context. We start to read the context token that we got from the client and pass it into gs-accept-tag context. And here, of course, the output token of the client is the input token in the server. And we'll get back an output token, and we always send back the output token to the client, even in case of error, because it might be some... The time difference there, the plus minus two and a half minute I talked about before, it might be a token there telling the client that, you know, the local time you have on your computer, I don't think that is right. And then we free the resources, the output token, And if case of error, we clean up and exit.

And then we loop around again if we need to continue, as the protocol tells us, or we don't need to do that. And we'll continue to validate the flags, just as we did in the INSTEC context on the client. The Harris, actually, ending up, we need to verify what services the GSS layer is giving to us and see if they are acceptable to our protocol. For example, it might be so that the context we're building is not providing encryption, and our protocol is sending over private data, and we want to have encryption, so we should really check that it's actually encryption what we got.

And now we'll get to the second part of the server. We have a context, and we now need to check who the user is. So we inquire the context. to get the username out of the context. And then we display the name, and then we parse the name and check against ACLs to see if the user is going to access resources on that machine.

So there's a complication here that display name is actually not really the correct way to do this. You should really use GSS export name. That will give you a binary blob and you have to parse it. But mostly everybody is using GSS display name that will give you user string that you can display for users. But this is cheating because it's not meant for machine consumption.

But it's what everybody is using today. And we recommend you to do this way because it's simpler and you don't need to unparse ASN1 data. This should really be some other way to do this, to get a local machine name, a local account name. And we will think about that, how to make it easier for you.

So as an application writer, when you want to add your protocol, you need first a service name. And that's the first part of you, if you remember, the ticket for a service is the host/hostname. That's the host part of the ticket. And for IETF protocols, this is usually specified. And usually, it's the same as the port number you're using. And this is something that you need to make up if it's not part of the-- or get registered.

And then the second thing that you need is a key tab. And this is for storing the regenerated keys on the machine. And you need to point out this file and have this sysadmin get you the file somehow and have instructions for that. And then lastly you need to implement the ACLs and you can use display name or you can use export name. Display name is much easier. Thank you. There's some related technologies here that you will run into when you start to research about GCSIS BI. There's SASL, which is a simple authentication and security layer.

And that's also an IETF standard, and it's usually used in text protocols, because GSSPI is a binary protocol with data length encoded data blobs. SASL is pretty much just a thin wrapper around the SSAPI when you're using SSAPI, but SASL also support other mechanisms like password-based logins and digest 75 logins.

SSPI is the equivalent of JSCC API in Microsoft AD. And it was created about the same time as JSCC API. And it's compatible with JSCC API if you use it correctly. Or the way that makes generated packets the same way as Microsoft can understand it. There is good documentation how you use SSPI for doing this. And if you're using cross-platform applications, SSPI is something you're going to run into. Just exactly like SSPI, SSPI support multiple mechanisms. For example, Digest and JSSPI, Kerberos, SPNEGO. SPNEGO is called Negotiate in that protocol. And also TLS is also used in SSPI. So let's demo this.

And we thought that the application that we're giving you is kind of boring, so we made a little chat application here instead. So let's start the server. and it's just a text-based protocol here. And let's start a client. And I will refill in all the information to log in to the server. And the first time I connect to the client through server, it will ask me for the password. You might guess the password.

And I'm connected through a server. And if we turn on debugging here, we can go back and see the context tokens. And you can see part of the messages are in clear text. You can see the service name there, ticket, and the rest of it's encrypted. And that's the second ticket going back from the client to the server. And we are logged in. And of course, we can talk to ourself.

And actually, the packets go back to the server and back again, so we send it over to the server and get back the reply. And if we turn off the encryption, That's hello in Swedish. Then we can actually see that the pack is in clear text in the client, but the servers in this implementation always send us back encrypted. And just to show you that I'm not cheating, and actually this is a-- it's actually a client. I will open up another window. Log in as another user.

and they talk to each other. And you can see that they print out the username. So let's go back to the presentation. So in this session, I've been talking about an overview of Kerberos, what Kerberos is, and how it works on the inside, and why you want to use Kerberos, and how we use Kerberos in Mac OS X, and especially the two new features in Leopard, the local KDC and the PIC unit, the certificates for.Mac. And also I've been talking how to use Kerberos in your application.

And there's some related sessions that you might want to go to, and that's Extending and Troubleshooting Directory Services tomorrow at 9:00 in Russian Hill. And that's going to talk about OD and AD. So if you have a problem with that, that's the session to go to. There is also a lab related to this session, and that's right after this in Mac Lab A.

And there's also a session for director services, and that's tomorrow at 10:30. So for more information, you can see our technology and volunteerist, and that's Craig Keithley. And there's also documentation on our website. And the MIT covers has documentation, and there's the internet RFC say you can read.