Kerberos Authentication Overview

Kerberos Authentication Overview

Table of Contents

Kerberos .......................................................................................................................................... 2

Kerberos Benefits ............................................................................................................................ 5

Key Distribution Center ................................................................................................................... 6

Kerberos Process ............................................................................................................................. 8

Kerberos Authentication ............................................................................................................... 11

Kerberos Considerations ............................................................................................................... 13

Notices .......................................................................................................................................... 15

of 15

Kerberos

58

Kerberos

Project Athena from MIT

Provides “single sign – on”

Single Sign On• Provide credentials one time and have access to multiple resources

within the enterprise

**058 Kerberos, a little bit more about Kerberos. Project Athena from MIT, it is a single sign on technology. If-- I'll use a building as an example. Let's say they are ten different suites in the building. And each of those suites has-- each of those suites represents a computer that I want to have access to. A couple different ways of controlling access. One is I go to suite number 101, and I knock on the door. And I say I want to come in. And whoever is inside the door, they have their own local list of who's allowed access. Every suite, 101, 102, through 110, every suite has their own local list.

of 15

The problem with that is consistency. They're probably not going to be the same, and it's hard to keep them up to date, maintaining all those different local lists. So, instead of each suite having their own separate list, what we do is we have a guard in a back room somewhere that has a list for access to all the suites. So, I go up to room 105. And I knock on the door. And I say I would like to have access to room 105. Whoever's inside that door picks up the phone and calls the guard and says there's someone at the door. Should we let him in? Since it's one list, one central location to store that information of access, it's a little bit easier to maintain. If I go to room 107, knock on the door, whoever's inside there picks up the phone, calls the guard. He looks at this. Oh, yeah. He's allowed in room 107. 108? Yep, he's allowed in 108. So, we always call back to the same guard. But the problem is every time I want access to a room, I have to call-- somebody has to call the guard. And it's not bad. But it's also not extremely efficient. What would be nicer-- and here's kind of what single sign on does, Kerberos. I walk into the building. I first go to the guard. The guard verifies that I am Mark Williams. And he says, "Mark, you're allowed in rooms 101, 102, 107, 8, and 9. And he gives me a badge that opens those five rooms.

of 15

So, now I've authenticated. I'm in the building. And I can have access to all those resources without having to go back and see the guard again, without having to knock on a door and say can I come in. Does that kind of make sense? So, that's what single sign on is designed to do. It's one stop shopping for administering all of our credentials and privileges. And it's also much easier from a user standpoint to gain access to a collection of resources with one authentication, rather than having to authenticate for every time you want to access a resource, so single sign on.

of 15

Kerberos Benefits

59

Kerberos Benefits

Mutual authentication

Better performance

Simplified trust management – Good for use in multiple domains

Interoperability – Kerberos is a standard.

**059 Now, so we get better performance if we're using Kerberos. There's also this idea of mutual authentication. When I think about accessing a resource, normally, if I want to access the server, the server verifies I am Mark Williams, right? It authenticated me. But how do I know, Mark, how do I know that I'm talking to the right server? By default, with most systems, I don't. Kerberos provides a way for me to get that mutual authentication, so the server knows that I am Mark. And I know that I this is the right server that I want to talk to. Kerberos can provide that capability for me.

of 15

Kerberos uses symmetric cryptography and a key distribution center to facilitate that mutual authentication capability. And Windows incorporates Kerberos inside of active directory. And they've been doing it for years.

Key Distribution Center

60

Key Distribution Center

The KDC runs on the Domain Controller

• Authentication Server (AS) issues a Ticket Granting Ticket (TGT) for connection to the TGS.

• Ticket Granting Server (TGS) issues tickets for connection to other computers in the domain.

• Credential database (AD) stores the UserID, hashed password and privileges for the user.

Key D

istribution Center

Authentication Server

Ticket Granting Server

Active Directory

**060 So, what do we have in Kerberos? We have this thing called a KDC, key distribution center. There are actually three elements of the key distribution center in Windows. We have the authentication server, the ticket granting server, and then active directory itself, which is the database the stores the credentials.

of 15

If I can give you another analogy. How can I give this analogy? I'll use a simple one of an amusement park. Where I live, we always have these fireman's carnivals. For my kids to ride a ride at the fireman's carnival, they have to go buy a ticket for the Ferris wheel and present the ticket. They have to go buy a ticket for the bumper and present the ticket for the bumper cars, and so on. Well, also, where I live is Hershey Park, thirty minutes away from me. We don't have buy a separate ticket for each of the rides at Hershey Park. We buy one expensive ticket for Hershey Park. And then, we can go get in the park and have access to all the rides without having to present our credentials again. And that's kind of what this KDC does. It gives us access to all the rides without having to present a ticket for every single ride.

of 15

Kerberos Process

61

Kerberos Process

Key D

istribution Center

Authentication Server

Ticket Granting Server

Active Directory

Server

(1) AS_Req

(2) AS_Response

(3) TGS_Req

(4) TGS_Response

(5) AP_Req

(6) AP_Response

**061 Now, how does this Kerberos process work? Now, I'm going to take out the ticket granting server just for a moment. Let's pretend this does not exist. Up on this top left picture on that laptop, that's me. I am principal one. I'm on that machine. And I want access to this server we'll call it principal two. If I wanted access to the server, I could use Kerberos. And I can send a request to the authentication server saying I'd like access to principal two. And I provide my credentials. And the authentication server can respond back and say yes, you are allowed to have access to principal two. And he

of 15

gives me a ticket-- well, in this case, a ticket to access principal two directly. And now I can talk to principal two. But what happens when I want to talk to principal three? Then I would have to send that request to authentication server saying I want to talk to principal three. And I have to provide my credentials again. And I get a response back. And now I can talk to principal three. What about principal four? So, every time I want to talk to a separate entity on the network, I have to provide a separate set of-- might have to provide my credentials every single time. So, Kerberos adds in the ticket granting server. What I basically do is one time I say I want to access the ticket granting server. So, I send an AS request into ticket granting server-- I'm sorry, into the authentication server saying I want to talk to this guy. And I get a response back. That response is basically a ticket granting ticket. And then, when I want access to principal one and principal two and principal three and principal four, I use that ticket granting ticket. And kind of behind the scenes-- behind the scenes I send a request to the TGS. I get a response. And then the TGS gives me the necessary tools to talk to each one of these individual principals.

of 15

So, do you see the difference? Without the ticket granting server, every time I want access to a principal, I have to basically provide credentials, me, the human, manually have to do it. But by the inclusion of the ticket granting server, I, the human, provide my credentials once. And then behind the scenes a lot of authentication happens that allows me to seamlessly gain access to all the resources on the network. That's a big benefit of Kerberos and the ticket granting server. I guess a question that comes into my mind though is this ticket granting server, we're going to get from the AS a ticket granting ticket that gives me access to a bunch of resources in-- they call it a realm in Kerberos terms, gives me access to all these resources. How long should that ticket be good for? We need to enforce some type of lifetime. I don't know that it matters to you, but ten hours is the default lifetime for the ticket granting ticket in Kerberos within Windows. Some organizations say ten hours is too much. Why ten hours? That's basically a workday, isn't it? Eight a.m. to six p.m., somewhere in between there, or seven to five, something like that, adding a lunch break or what have you. Well, some people say that's too much. Some organizations change it to either four or five hours. What that does is I log in. I, the human, provide my credentials in the morning when I come into work. I get that ticket

of 15

granting ticket that allows me to bounce around on the network seamlessly until lunchtime. After lunch, I have to provide my credentials again. So, that might be one of the modifications you make, how long is that ticket granting ticket going to be good for.

Kerberos Authentication

62

Kerberos Authentication

AS_REQ Client sends user ID and asks the AS for a Ticket Granting Ticket.

AS_RESPONSE AS sends a TGT (encrypted w/ TGS secret key) and a session key (encrypted w/ users secret key).

TGS_REQ Client asks the Ticket Granting Server (TGS) for a service ticket (Request to have access to the server).

TGS_RESPONSE The TGS replies with the service ticket (encrypted with the servers secret key) and a session key (encrypted with the clients session key).

AP_REQ Client finally asks the server for access. The service ticket obtained in Step 4 is passed on to the server.

AP_RESPONSE (Optional) The server proves to the client its identity. http://msdn.microsoft.com/en-us/library/ff647076.aspx

**062 All right, so they step you through each one of the six steps, and what we have with each of the requests and responses. So, starting off, AS request. That's authentication server request. Basically, I say here's my user ID. I would like to get a ticket granting ticket. And, as long as

of 15

I provide the proper user ID and password, the AS gives me an AS response. Here is your ticket granting ticket. Now, that happens when I first sit down at my computer. I haven't done anything, yet. I haven't gone to any other resources. Fifteen minutes later, it's time for me to go to a file server, maybe. I want access to a file server. That's when I click on the file server, behind the scenes a ticket grating server request goes out. That ticket granting server, the TGT, is used to request a special ticket to talk to the file server. If clicked on my print server, another ticket granting server request goes out. He wants to talk to the print server. And, if we're allowed to talk to the print server, I get a response. Or if I'm allowed to talk to the file server, I get the response that has the necessary additional credentials for me to talk to the print server and the file server, or whatever it is-- whatever resource I'm trying to access.

of 15

Kerberos Considerations

63

Kerberos Considerations

KDC MUST be present.• Build in fault tolerance by having secondary KDC.• Make the KDC a bastion host .

Timing is critical.• Everything must be time synchronized or the authentication process

will not work.

Security Implications:• Deny (or alter) the timing source• Deny the authentication server

**063 So, in order for all this to work, that KDC, that key distribution center, has to be there. A very common attack is to do a denial of service against KDC. If I can shut down your KDC or make it temporarily unavailable, for that entire time it's unavailable, nobody goes anywhere, no authentication network. So, one of the recommendations is turn on redundancy. Add in a second KDC, tertiary KDC, whatever makes sense in your organization. Make sure that KDC does not go away. Provide a proper level of both logical and physical security controls for it.

of 15

I mentioned about the tickets. And they're only good for a certain time. Well, manipulating times in Kerberos environment could allow a ticket that should be expired to still work. So, we want to have a common clock in a Kerberos environment, a common trusted clock is probably the best phrase to use. And then we also want to have some default I guess positions. If somebody tries to gain access and it's beyond their time limit, what should I do? Deny them? Shut them off? What happens if they access it before their time has expired, but they try to stay accessed after their ticket has expired? Well, what should we do there? That's something that might need to be considered. So, there's a couple of security implications with Kerberos.

of 15

Notices

2

Notices© 2014 Carnegie Mellon University

This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual study.

Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected].

This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide.

Although the rights granted by contract do not require course attendance to use this material for U.S. government purposes, the SEI recommends attendance to ensure proper understanding.

THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).

CERT ® is a registered mark owned by Carnegie Mellon University.

of 15

Kerberos Authentication Overview

Documents

Transcript of Kerberos Authentication Overview