Hej och välkomna till introduktion till Kerbero. Oh, I'm just kidding. I'm not going to encrypt this in Swedish, but I'm going to talk about encryption. And this is an introduction to Kerbero. My name is Love Hornquist Astrand, and I'm a security engineer. So I'm going to start to talk about what Kerbero is, and what it is, and why you want to use Kerbero, and where Kerbero is found today, and what systems are out there.

Also, I'm going to tell you about how Kerbero is, and how it works on the inside, and how the ticket flies around. And then some new features in Leopard that are used in Kerbero. Lastly, I'm going to talk about how you add on Kerbero support in your application.

So to understand what Kerbero is, we're going to look at the definition of Kerbero, and we're going to take it out of the O'Reilly book, The Definite Guide to Kerbero. And they have a very nice definition there. This Kerbero 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, mutual authentication, single sign-on, secure and protocol. So let's go through all these words and see what it actually means, and take some examples out from both the computer world and the real world, how this all fit together and how they relate to Kerbero.

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. Kerbero 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, trusted third party can be the certificate CAs. But unlike the CA system or certificate system, Kerbero is using shared keys instead of public and private keys. So Kerbero is using symmetric crypto.

Kerbero is also providing mutual authentication. And it's two parts. First, client is usually proving the identity to 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 you 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 Kerbero has also provided this functionality.

Single Sign On. Kerbero 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 a Single Sign On token. 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. Kerbero is also a secure system. It never transports your passwords over the network. So you don't need to worry about exposing the password. Kerbero is also using symmetric crypto.

So it's using a Kerbero 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. Kerbero's, 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 actually 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 Kerbero's provide that feature too.

Kerbero 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 the little push button lock that allows you to go in through doors. And they installed them on many university campuses and high schools in the US. 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 Kerbero has been through this already, so you don't need to worry about it. So don't do that.

Kerbero 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, knock, knock, who's there? Orange. Orange who? Orange you glad you bought your ticket before it sold out? But it can also be very complicated, like the whole IETF TCP/IP stack.

And Kerbero is maintained by IETF, and it's a Kerbero working group on IETF that maintains it, and is still continuing today and improving the document. And there's many implementations of the Kerbero protocol, and MIT Kerbero is one of them, and we use it in Mac OS X. And 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 Kerbero 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 people have thought about doing before, and reuse what other people have done.

Kerbero is also 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.

Kerbero was designed for a hostile environment. An environment where people could insert packets into a network, and they could listen on any packet, and Kerbero 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. Kerbero also scales to millions of users and services. So you won't have the problem that Kerbero won't scale. It will scale. It's been proven before.

Kerbero's never transmits username, passwords to, between, over the network. So you as a server, when you're using Kerbero's, 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 use, log in once to the system, and then they can use all these different services by just using Kerbero's. 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 like, it was, like, 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 Kerbero 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 Kurobras 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 Kurobras adapts to newer crypto systems. And you don't need to change your application to get a new functionality of Kurobras and newer crypto. It's just that you update the crypto library and the Kurobras library, and you're all set. There's no code changes and no recompilation of the server. your application it just works.

So where is Kerbero use today in Mac OS X? Well, many of the application that you get with Mac OS supports Kerbero. We have the remote login, like screen sharing, SSH, Telnet, but also the file sharing protocol, the NFS, SMB, and AFB. They all support Kerbero and use it. There's also web application. The web browser all use support Kerbero, and I'm going to show it in the demo. And also the mail, mail.app, and other mail applications support Kerbero.

But this is just for the Mac. But how about other operating systems? Well, we got all the Unix systems, like the BSC, Solaris, Linux, and AIX, and of course, Windows Active Directory. Active Directory is the big consumer of Kerbero, and it's actually the main authentication system used here. So if you want to interrupt with AD, well, Kerbero is your only choice. There's also Novell E Directory, and Java is using Kerbero as a support as part of the GAS system. And of course, Mac OS X Open Directory is using Kerbero. So this is nothing new for us.

So now we're going to have some flying tickets and describe how Kerbero work. 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 Kerbero 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 Kerbero. There's the users and there's services.

And they could have used the same name for this 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 a short-term name. you don't really have any choice, this is how it works.

There's also a trusted third party in Kerberoes, 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. Kerbero, the main data type in Kerbero is the Kerbero's 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 when this, what the ticket's, what the ticket is. It's the yellowish orange ticket in my older slides.

Users, when they log into Kerbero, 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 other tickets. It's a special format of it. It's .

So we have a client and a 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 the 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 authentication and getting your ticket, granting ticket from the KDC. The server's not part of the transaction yet.

So we asked for a ticket-and-running ticket, and guest-packed the ticket-and-running ticket and stored 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 get 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 protocol.

and it goes over and we can use our application at the server. So that's Kerbero. 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 ticket as a client, we send over our username that we want to, what service we want to get, and how long time that 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 only going to ask for five minutes because we don't want the ticket granting ticket that will give us access to all the services around for last 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 ask for. But usually this is 10 hours for a working day, unless you're working for the slide for this presentation, and then you need to log in at least twice. So the KDC 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, oh, here's some data.

I want to talk to that server, so give me a service ticket. So you add an authenticator. This was made Kerbero's 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'll get back the service ticket and we'll 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 use services 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 10. And 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, Kerbero is just providing authentication and not authorization. So just identity. So the client takes the ticket grounding ticket, sends it over to the KDC, gets back its special service tickets that allows it to talk to the other KDCs. And then the other KDC is sending the service ticket to the other KDC. 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 Kerbero can create this complex solution 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 instantly 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 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 you want 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 an 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 minutes.

That's what makes Kerbero 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 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 Kerberoos 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 Kerbero secure. So let's demo Kerbero and see how it works. The demo please.

So I'm going to show you using a web browser talking to a Kerbero web server. 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 kinet 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 Kerbero is used in Mac OS X. It's been in Mac OS X since 10.0. It's also is the primary authentication mechanism open directory. And Kerbero is supported in many applications in Mac OS X. For example, the all the file 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.

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.

But users don't want to type in this long name, so the Realm discovery to find out what Realm the 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 serving we want to do. So, Stan wants to take a random ticket, he gets a ticket, he wants a service ticket, he gets a service ticket, and he can run the file sharing on our 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 the next time. They don't need to log in again.

So on local KDC, all Macs today on Leopard is running a Kerbero 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.

So in the demo I did just recently, I was kind of cheating because this didn't look like that actually when you tried 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 you know 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 passwords 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 the 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 .Mac 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 .Mac account, and that's Stamerson, we enter it here.

And what that does in the background is, first, when Stam joined his computer to the .Mac, he actually downloaded a certificate and a private key into his machine. And then, when we created IELTS Computer on IELTS iMac, we downloaded a certificate from the .Mac and installed it on IELTS iMac. And these certificates are automatically updated whenever they change on the .Mac. 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 Stams 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, running ticket for this Stam, and that's the hash of Stam's, certificate in the Darknet 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 it's also probed the AFP server to see what resources we have on that machine. So let's see if we can do screen sharing. 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 that we use for screen sharing.

So let's get back to the presentation. So now, how can you use Kerbero in your presentation? Oh, sorry, in your application. Kerbero is supported for managed environment. It's not using the .Mac service. And using Kerbero in your 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 at 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 Kerbero, it's supporting Spnego, and that's for negotiating different mechanisms, but also NTLM for legacy applications.

As an application writer, you want to use Kerbero when you want to leverage existing Kerbero infrastructure that exists already today. And this enables you to not need to maintain password or user information for 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 or your and your Macs. Also, you want to use Kerbero as an ESS API when you have standard protocols like IMAP or SMTP submit or something like that, that requires use of Kerbero, so you don't really have a choice.

Just as 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 contexts and application contexts, 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 tokens 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-crowding 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 just as 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. And usually there's only one round trip. The packet goes from the client over through