Taming Kerberos - Computerphile

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
from Mike's house to you direct this is very strange all right well Steve did a great video on VPNs and how to have work remotely right and now we're all doing this so I thought I talked also a little bit about networking or you know a cryptographic protocol that we often use over networks in one of my previous videos I talked about quantum computing and what kind of effect if any that would have on encryption and the answer really is that it has quite a big effect on public key cryptography but not that big an effect on on symmetric cryptography you know that's assuming we can build bigger quantum computers sometime now what I wanted to talk about today is a really cool protocol that actually sees a lot of use particularly I mean everywhere right on lots of different operating systems but particularly on Active Directory as its main authentication mechanism and that's kerb loss right II remember kerb loss the three-headed dog but guards ain't Hades is it so it has a cool name we're off to a good start curb loss is a really interesting protocol because it's a way of managing authentication and communication over a network like a giant enterprise level network but it does it without really requiring any kind of public key at all so it does it all with symmetric encryption so it is inherently very robust to any kind of quantum computer so Kerberos was invented in the 70s at MIT and it's still maintained by MIT but obviously in recent years you know variants have it ever appeared in things like Windows Active Directory I'm just going to talk sort of in general about Kerberos I'll try and draw attention to the differences between you know the active directory version but mostly its naming differences really it's what we're concerned with one of the issues if we're going to use only symmetric encryption is we have to work out how to share keys we can't do key exchange because that's public key we can't verify people using something like certificates because that's RSA that's public key so what do we do well one of the ways we can share keys is using passwords and so we could derive a key I could take my password I could hash it in some known way and then we could you could do the same thing if you were server but knew my password or knew the hash and we could have a shared secret that way so okay let's say we want to do this right well now let's think about the number of machines on a standard corporate network like maybe there's 2,000 laptops on any given day connect to the network and 10,000 desktops and 200 servers how many of these passwords are we using are they all shared are you what different passwords different keys I mean let's use a very simple example let's imagine we have a network with ten machines so I'm just going to draw ten machines I should have drawn fewer machines let's you know what I can undo this I can say five machines now if I want to have a shared key but it's let's say different for security reasons between all of these machines it's going to look something like I think that's all of them right and then if I add another machine a SiC machine here I've got to do this and 1/7 machine this is an absolute mess right because we can't do key exchange so normally what you would do on the internet is you would just talk to a machine do a quick key exchange and then you've got yourself a session key for the rest of that conversation we can't do that because that's a public key protocol which is vulnerable to things like quantum write and also actually at a time I don't think if you help me existed when this was first developed right or at least the protocols underpinning this so we're not going to use public key as a solution we're going to come up with something different what we're going to try and do is use the fact that we have this server which I'm going to draw sort of nice and big here server a big s on it like the Superman this server we all trust and because we all trust that server we can use that to give us temporary keys so in orange I'm going to draw let's imagine that these machines now have long term keys with this server all right so there's now one two three four five seven keys there's seven permanent keys probably based off passwords right with this server we will trust a server for now so that's good now let's imagine that this machine wants to talk to this machine what we do is we ask for server to send us a key that we can use for that conversation and it just generates one at random and protects it using these encrypted channels and then we can temporarily use this green key for our session so the key exchange is now using this trusted third party so this is kind of what curb is about it has the benefit but it doesn't rely on public key but also there's an inherently there's a really elegant way but it authenticates you because basically you can't talk between these two machines unless this has given you a key to do it which is in some sense giving you permission to do it if this is a file server and you want to access a file server it's only going to work if you've got a key from here and if it doesn't give you one because you're not allowed good luck getting onto the file server alright that's the idea so it's quite a neat trick but but gets around just using symmetric and has this authentication built in now Kerr boss is also a little bit more complicated than this so that's what we're going to delve into now we're going to be on a fictitious network now and this is me over here now you know as you know from my previous videos I'm very good at drawing computers and they always look realistic so this is my little desktop so this is me I'm going to be a a for Alice or you know and here we have our authentication our ticket granting service now these are part of kerb loss we're gonna have a big machine over here and this is going to have two servers in it or two services now in the original curb loss this would be called a key distribution center or KDC often this role is performed by something called a domain controller on Active Directory now in here we have two kinds of servers we have our authentication server which I'm going to call s and our ticket granting server which I'm going to call T and everything to do with authentication and connecting to a like an Active Directory or any other kind of curb or setup is going to be using these two services so the authentication server is going to be responsible for checking your password essentially and making sure you actually do have an account on that directory or that network and the ticket granting server is going to be responsible for issuing you tickets which you can use to go and access things like file servers or printers or whatever else it is on the network the first thing to do is to approach for your fent occasion server assuming we've already had an account created and send them a message so we're gonna send them a message which says my name is a I would like to talk to the ticket granting server and here is a random number that I'm going to use to prevent replay attacks we're not going to worry too much about them which is going to pass them back and forth but the point is I'm sending a message not really necessarily encrypted to this authentication so the IMA and I'd like to talk to a ticket granting server now the important thing here is assuming that a has an account it has a established key between a and s I have a key a s which I can use to talk to that server for the long term because it's based on my past or it may be I only change my password every 12 months or whatever right my passwords very good I don't have to change it I should I should tighten notice now so I'm gonna send this message across to s now s is going to reply s is going to send a message which is encrypted assuming it allows me to talk to T it's going to send me some messages that mean I can then talk to T all right so the first one is going to be here's a key K 80 that you can use to talk between these two here's your nonce back again to prevent replay attacks this is the current time this is the lifetime of this ticket and you're okay to talk to the ticket granting server so it just has a lot of different parts to this message the things to bear in mind are so the timestamp I'm a lifetime or Soviet you can't like hold on to a ticket for sort of two years and play it again no and you know we have the names of things in there to make sure everyone knows who it is they're supposed to be talking to so the important thing in this message is this key K 80 well I'm using 80 to symbolize this as a session key between a and T right now I don't have a long term key with T my computer doesn't have that this is generated on the fly by this server now this is encrypted this message because we can't be sending keys over the internet if it are not encrypted so this is going to be encrypted with my very well drawn curly brackets and this is going to be encrypted using K a s which is of course our long term key between a and the authentication server what I can do now is I can decrypt this message using Kas because that's derived off my password I can read this session key and then I can use it to talk to T the problem is that T doesn't have this session key I this is new this is brand new this key so it's going to send s is going to send me some more information it's going to send me the same k80 it's going to say this is to talk to a and this is the lifetime of that ticket and this is going to be encrypted with K s T so this the authentication s is going to use a long term key s T to encrypt this message which I can't lead right because I don't have s T I'm ma right so this is a ticket that I can pass to T for it to use and only it can understand so this is called a wonderfully named ticket granting ticket it's a ticket that's gonna let me get more tickets in the future hey so I take this first message I decrypt it and I have the session key that I need I forward this message on to the ticket granting server it decrypts it and assuming it's okay it now has the message but it needs that's kind of cool this is all the other really nice thing about this is but it's fire-and-forget so this authentication server can very quickly look me up in database fireback these two new session key is encrypted and then it's done its work is done right it's authenticated me that's the end of the discussion it doesn't need to talk to me anymore until I love on another time so the next thing I have to do or I want to talk to some kind of server file server let's say called B now we can't do that yet because we haven't got a ticket and in that ticket is going to be a new session key that we can use to encrypt that conversation so I'm going to send a message I'm going to use my purple again a kind of I've kind of messed up the colors we'll do our best all right so I'm going to send a message now to tea and that's gonna be first of all this ticket and that ticket says OMA and this is my new session key that we can use and this has kind of been stamped as it were it's been authenticated by the fact that it's encrypted by K s T which is the authentication servers private key with this T here so I'm gonna send my name is a this is a timestamp to make sure everything is taking place at the right time I'd like to talk to be please and this is some new random number that we're going to use to prevent replay attacks and this is all going to be encrypted using the K 80 session key we've just obtained it's okay 80 so only me and T can read that and I have to take this and I also forward on the ticket it decrypts the ticket and now it has access to k80 and can read my message right and no one else can this is why Kerr bosses are clever and so this ticket granting server is going to look at me and it's good at my account and it's going to look at what B is and work out whether it is okay that I actually talk to be right now assuming that's the case it's gonna respond right it's gonna send me back let's go with green for this one I don't know it's going to do exactly the same as the authentication services so it's going to produce me a new random key to be used to talk to be I which we're going to call kab so we're not gonna get super confused it's okay a B and we're going to reply with the random number as well to prevent me player tax this is the timestamp of the server this is the lifetime of this ticket and finally I would like you to talk to B and of course this is going to be encrypted using our key between a and T okay a t only since everyone think messages are encrypted with their own session key or their own long-term key depending on which one you're talking to and of course what else does it need to send well we need B to be able to have this kab in order to have a conversation so it's going to have to send another ticket to let us access B so this is going to have K a B right so that's our shared secret this is I would like you to talk to a this is of a lifetime this is going to be encrypted with a key the only T and B have right which is K BT so that will be some password or other sort of long-term key between this file server B and our ticket granting server our key distribution center now we need to talk to be right so I'm gonna I don't know let's let's ER list will be over here so this is our file server B this is B that's a rack server and it's the worst rack server I've ever seen B is just sitting on my network waiting for thing people to talk to it right and I come along it gets very excited I'm gonna forward on the ticket right because that's the one that it can decrypt it uses its long term key B T to decrypt this and now it has access to this session key it also in some sense has a proof that I'm allowed to talk to be because otherwise I wouldn't have been able to produce his ticket because this was encrypted by a ticket granting server a bit like how a digital signature on the internet might provide some sort of proof of authenticity this kind of has that role I wouldn't even have to produce his ticket if the ticket granting server hadn't encrypted it for me to pass on so I pass on a ticket and I also pass on a message that says very simply my name is a this is a kind time and I'm going to encrypt this using K a B which is the new key I just got given by a ticket granting server so I send it that I also send it per ticket it decrypts the ticket looks at kab and it can now understand this message and finally it responds with my timestamp +1 as a challenge to prove that it can actually understand the message and it's not an impostor and that's going to be also encrypted with K a B so I've used the ticket from a ticket granting server to talk to B and now I can then continue using that ticket for a while and continue encryption with B right and then we can start to send files back and forth and things like that so let's sort of look one more time at what what's going on here right I wanted to talk to B and I also wanted to authenticate to this network because this network is let's say my University Network and I wanted to log in and all I have at the moment is a password so what I do is I send a message to the authentication server that says I'm a and I'd like to talk to the ticket granting server it sends me back an encrypted message that I would not be able to read if I didn't have my password so that's how it authenticates me and it also crucially sends me a ticket but I can use to pass on to the ticket granting server these two things both contain a new session key that I can use for encryption so then I talk to the ticket granting server and the exact same process happens again I say I'm a I'd like to talk to B B's a file server the ticket granting server will look at the s it will look at the what B is and decide ok he is allowed to access this server so it will send me back a message with a new key and it will also send me back a ticket to pass on to B so it's the exact same process so every time I want to talk to anything on this network I can just go to the ticket granting server with my ticket and say please may I have another one for this and it will give me new tickets so I can just go and get tickets it's like like an affair ground and you know you've got a lot of Ferris wheel and other stuff and you just go to one desk to buy all the tickets and then you can go to the actual rides later or something like that that kind of idea so I then can talk to B and we have this little exchange that makes sure that you know there's no me player tax and you know we're not doing anything untoward so it's a really neat way of just using symmetric encryption to gain actually some pretty good security these tickets how long does it last so it depends on a ticket but on authentication ticket like the one you get on the ticket granting ticket right from from s that could last 24 hours or something like that now tell it where it's going where it's come from and then these days the local network almost certain
Info
Channel: Computerphile
Views: 242,004
Rating: 4.9668255 out of 5
Keywords: computers, computerphile, computer, science, University of Nottingham, Dr Mike Pound, cerberus, three headed dog, authentication, domain controller, active directory, Remote Working, HD
Id: qW361k3-BtU
Channel Id: undefined
Length: 16min 6sec (966 seconds)
Published: Wed Apr 08 2020
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.