 Cool. Okay. So, Nathaniel, I'm Robbie. We're going to talk about how to conquer the world of Kerberos. So, before we do that though, this is a tag team talk. I'm going to talk a little bit. Then Nathaniel is going to talk a little bit. And then I was going to talk a little bit at the end. And then we'll leave a good chunk of time at the end for questions, hopefully. Does anybody in the room know Kerberos? Does anybody not know? Okay, cool. So, you know what Kerberos is, but you probably don't know who Kerberos is. Kerberos is this guy. He is our three-headed protector of secrets, guardian of the underworld. Very importantly, he is fuzzy and squishy. And each of the heads have individual names and need to be respected as individual persons. I have no idea where you can buy the plushie. I'm sorry. But Demetri, we need those for the team. It's essential business for the team. Go for it. Okay. So, as Robbie said, my name is Nathaniel. And Robbie and I both work on Kerberos and identity management teams at Red Hat. And this is actually an expanded version of a talk, but I give it DevConf a lightning talk. And we've combined our two relative areas of expertise. So, hopefully, we can be beneficial to you today. Let's first start off by looking at Kerberos the past. Kerberos has had a pretty long past. And it was, obviously, there was version four. Well, there was versions before that as well. But version four was the big one that was kind of first deployed. And then version five blew up from there. Lots of people deployed it. So, the true single sign-on system, unlike a lot of people that throw around the word single sign-on, what they mean is you're using the same credentials everywhere, which usually you're not. In Kerberos, you actually have a true single sign-on experience where you log in one time. And then for each additional login, you just get tickets that prove your previous login. So, you don't have to continue to type your credentials every time you log in somewhere. Kerberos has another really, really important feature, which is that the credentials don't go on the wire. So, in most of your authentication systems, you will very often see people setting up things like SSL titles because they want to send passwords in the clear, but they want to encrypt them inside this tunnel to keep them safe. Which, of course, the tunnel is compromised, but for any reason, now everyone's reading all the passwords, which is a very bad thing. Kerberos was actually designed from the get-go to be a cryptographic system in which the credentials were never sent over the wire. And what this means is that it can be deployed completely without an SSL tunnel on an untrusted network. And the end result is a very secure system. And this was widely deployed. There's lots of implementations of Kerberos. MIT-KRB-5 is the primary one that we deal with, and it's the primary one that is used in Fedora. But there's also several other implementations, Heimdall is another open source one that has largely been used in the SAMBA project, although my understanding is that they're moving from that. Are they going to Kerb-5? They're going to Kerb-5. And so Microsoft is probably the widest deploy of all of these. Kerberos is the backbone of the Active Directory infrastructure. So if you're using Active Directory anywhere, or it's seen and used, that's all you use in Kerberos over the covers. SAMBA, of course, as mentioned, uses the Heimdall implementation to provide their Kerberos Active Directory support. So it's used widely by millions of people. It's a trusted system. It's true single sign-on, and no credentials go on the wire. So why in the world isn't everyone using Kerberos? Well, there are some downsides, or at least there were in the past. The first downside is that it's blocked by firewalls. So there's a lot of system admins that open and shut off all the ports. Only opens the one that they want, and so Kerberos can't get through. And this has been a problem traditionally. A second one is that client configuration is required. So unlike Facebook, you type in Facebook and get a login prompt, and you just type in your credentials, and you're done. You didn't have to configure anything in your system. It just all worked automatically. Kerberos did not used to work like this. You actually had to set up in a configuration file where you're going to go, the KDC to get your credentials, and all of those various other things. And so client configuration was required, which was a barrier to adoption. Another downside was client's time synchronization. The initial implementations of Kerberos used a pre-authentication method, which depended on encrypting a timestamp. And so this meant that the server time and the client time had to be the same, which of course, if you've ever been in an infrastructure, you know that your systems are not necessarily the same in terms of their clock. And so this was a pain point historically that you had to have all the clocks synchronized in your infrastructure, otherwise Kerberos just wouldn't work. The last one that was being down side was you could only have one client principal, which means that you could only have one login basically in a system globally. And so if you wanted to have multiple accounts, if you were a contractor and you were working from multiple places, Kerberos would be very painful because you could only have one principal, which meant you usually have to swap out that client configuration and do things with files to make it work. It was just really ugly. And so these are all the upsides and the downsides here of Kerberos in the past. But fortunately we've done a lot of work. And so things are rather quite different today. Yes? One thing I didn't see of the downsides was Kerberos interoperability. Okay. It's generally really good. Yeah, it's pretty good. I remember the time when MS or Microsoft Kerberos was a little bit of their OCE Kerberos. Yeah, so the interoperability works pretty well these days. We actually have, there's MIT runs the Kerberos Consortium, which every year has an interoperability meeting in which the different implementations come together and tests to make sure that everything's working. That's why Microsoft is here. Yeah. So yeah. The big problem was Microsoft had an undocumented extension. Yes. And it's been documented and done for a long time. So at the present, all of the stuff that's here is stuff that has been done in the fairly recent present in the last, I've been at Red Hat for almost five years now. So all of this stuff is five years or newer. So the first thing we have is, well I guess KDC discovery is over. We have KDC discovery. One of the nice things about this is that this actually allows you to, from the principal name, determine which KDC to contact to get that information. And most of the other configuration doesn't really matter that much. Or it can be handled in different ways. And so with KDC discovery, it allows us to actually discover just from typing K in it and your principal you can figure out who to talk to, which completely minimizes the client-side configuration required. Another feature that we've implemented recently was the client time offsets. So the way that this works is that when an authentication fails because of the time synchronization issue, the server actually will reply back and say, it failed, but this is my time. And the client can now do an offset from that time and send back a request knowing that the server has a different time. And so this actually allows you to bypass the time synchronization problem, which is one of the larger deployment problems. So that's no longer an issue. We actually have an even better solution for this, which we're going to talk about in a minute. But even as of today, this is not a problem. So we've also implemented multiple credential caches, which means now you can have multiple principles of a single system. So you can log into five different sites if you want to have principles for all of them, swap back and forth between them. All of this is, and then we do it all today. We've also developed, this is fairly recent, the HTTPS proxy. You can see the URL to the upstream project there. And what this actually allows you to do, Microsoft released a standard called KKDCP, which allows you to send the Kerberos, excuse me, packets across HTTPS. And so you can proxy them over a web server. This allows you to get past all the ports, because you can just send it to 443 to a proxy and you can get past it that way. So now we don't have the port problems so much. We've also implemented one-time password support, and we were the first ones to do this for Kerberos. So you can see the upstream project here at MIT, and you can see the design page for the feature at FreeIPA here. And the way the one-time password works is it uses the standard HTTP and TOTP algorithms that are actually internet drafts, RFCs, so they're standardized, and we use this. And you can do really innovative things. If you're using it with FreeIPA directly, that's what we support. You can also proxy the OTP to a third-party radius server. This is for support for things like RSA. If you have a little RSA tokens, that all works now. And we also developed a separate app called FreeIPA, which is available on the Android and iOS stores. And this implements the standard protocol. It's basically the same as the Google Authenticator app if you've seen it, but our app right there is open source. It's actively maintained, unlike Google Authenticator, and we're actually developing innovative new features. One of the upcoming cool features is Bluetooth sharing, which will enable you to just send the token code directly to your computer rather than having to read it off the screen and type it manually. So there's cool things like that going on, but this is all happening within the Kerberos realm. So this is all stuff that's done. We're also actively working on some new features. Probably one of the more important ones is the CAMAC and authentication indicators. This actually just landed last week, and will be in Fedora 23. So what the CAMAC and authentication indicators do is that they're signed assertions about authentication. So basically it's a string in the ticket that when you receive a ticket, you can analyze these strings, these authentication indicators, and they describe what happened when the ticket, or when the authentication occurred. So what this allows you to do is, for example, if you're using the OTP support, you can stick a string now in the ticket that says OTP, and so you can validate that when you receive a ticket did this user authenticate with OTP or not. So this allows some really neat bridging. First of all, we plan to implement a policy layer for this in free IPA, and then hopefully the next release. It's scheduled for the next release, right? If we can make it. We're going to put a layer into IPA to do this, which will basically allow you to say things like, I want two-factor authentication for these services, but not for these services, and then we will prove or deny a ticket based upon your authentication. Thank you. What's that? Thank you. Oh, you're welcome. One of the... Do you want the chapter to re-challenge you, not truly? It will... Do you have just a password-based ticket that you can try to go look at that in-service? No, I'm really prompted to that, but I'll ask you to deny it. The challenge is to have an error pattern. So the error code can be issued on the server side, but the client side wouldn't know until it is enhanced to process this error code. There's a pre-existing standardized error code that we're planning on using, which is the server policy error, so it's failing the list of some server policy. It's very generic, and we hope to improve the user experience over time there. We're using an existing error code, and it's likely all the clients have free... There's a standardized behavior for... This was MIT's recommendation to us. So that's currently the plan right now, and then once we get things landed, we can work on... Talk about the second part. Yeah, so the second part is where we would actually pass through those authenticators through the tickets all the way to the end services so that end services can inspect the tickets and make the determination themselves. So there's a centralized way of doing this policy and there's a decentralized way of doing the policy, and we plan to implement both of those. We also are planning, based on some conversations we had just last night, about doing things like bridging this using epsilon into other places like SAML. So one of the things that we talked about last night was using indicators to transition into level insurance policies like SAML and through epsilon. So this is work that's all actively ongoing, and the core feature here is landed in upstream. Perberos will be in Fedora 23, and then we're doing all the squirt of ecosystem polishing stuff on God's ongoing. Do you have a question? Yeah, it's not... Are there plans to expose this through the GSI? There are plans, but we have not designed it yet. So, yes. Another problem to put back to your point. So the starting idea is call an error code for all the bad user experience for the services that fail, that just display the policy fail because you are not allowed to access the service. And we'll have to be communicated out of that, and that in this case, we'll have to go through the process. We'll have to do that. The next step is make the services smarter and selectively say, okay, for this service, we are going to now send these indicators because this service knows how to handle it. So then through the GSS API that has been discussed 30 seconds ago, the service will be able to pull this indicator and say, oh, okay, this ticket is acquired without OTP and I require OTP. So I'm going to redirect whatever my default authentication URL go and upindicate there. So that would be per service. Yeah. There's another aspect to the service side when you're doing the decentralized verification of indicators is that you can have a lot more granularity. So you can say, let's say you have some file sharing over HTTP service and you use per roast to log into it and you're browsing through your files and everything's fine, you can go into a secure directory and at that point it would say, I'm sorry you don't have permissions because you don't have two-factor authentication. So you can actually, in the centralized model everything is less granular. You only get per service policy, but when you actually then break it out with the decentralized model you can actually have four specific resources within the service. And that's where we would need more buy-in and collaboration with services. Services that are already doing something similar, like if a service is already depending on something like standardized levels of assurance, if we can transition those at a transition point like Gipselon then that allows us to have a pretty smooth experience there as well. You might also be working with the policy community. That's a good recommendation. Other policy community here? Good. We should talk about that. So that's basically the overview of authentication indicators. A long work that's just landed recently, so we hope to move forward with that. We also have HTTP proxy discovering. We have this required in the internet draft which I wrote with SEMA. And this basically allows us to also discover the proxy. Right now you can discover the KDCs that you type in there for your principal and login and go find the KDC and then attempt to do your authentication. We want to also be able to discover the KDC so that all of that is completely configless which is our plan here. How is the standardization of our authentication indicators progressing? It is... it was finalized and it was about to be done for last call and I realized that there was some wording that needed to be updated. Tom just submitted that wording probably about three weeks ago and so given another month it'll probably go for the last call. It is. I just need to update it. That's the task I'm going to put. Yeah, so comment about that. You are familiar with Alice's app, right? So that was something that has been done by Microsoft and it was in the project connected. So as a result MIT is very particular about making sure that everything that has been done in space is standardize. So there were actually two layers of standards. One is CANAC giving you a container to send all this information around and then... That's signed. Yeah, that's signed. Yeah, and then authenticated the actual flavor of the authorization information that is carried inside this container. So you can put other generic information in there as well but authentication is just one of the types. So let's move on unless anybody has more questions here. So our next big project which I actually just finished up some of the preparatory work for is password authenticated key exchange. This is a new pre-authentication mechanism for Herberos. Herberos has these ideas called pre-authentication mechanisms. That's basically the ways that you prove who you are. Well, the traditional way to do this has been encrypted time stamp and that basically means you take your password, you take the time stamp, you encrypt the time stamp of the password and you send it to the server. The server then decrypts the time stamp and matches the debilitates against the local time that it's going to do in a certain window. That have the time synchronization problems that we talked about. Other people have also implemented other pre-authentication mechanisms. Most of them are centered around the question of multi-factors and this led to the creation of something called FAST, which is essentially to boil it down very simply, probably too simply, is SSL for Herberos which allows you to send credentials to Herberos through this encrypted tunnel. Well, now of course you've actually FAST is a good thing for a variety of cases, particularly because it allows you to encrypt the entire ticket so that no information about the ticket is shown under the wire, which is a nice thing. So FAST is not bad but it does sort of fall into the trap of sending passwords into Clear through this encrypted channel which we don't want to do. We also had the concern of how to accurately handle multi-factor authentication. When we implemented the OTP support we did it using a standard that was created by RSA and although we implemented it and it works well, we realized that there were some design flaws with it fairly early on, particularly as regards to user experience. Setting up the FAST tunnel is in a system like free IPA where you have control over the clients and the servers, all of this can work very well and very integrated, but if you want to try to do it in a completely configulous environment such as with Fedora volunteers, let's say, it's not really easy to deploy in that situation. So what we've done is we've used strong monitoring photography including electric curves to implement a new free-off mechanism and it's called Password Authenticated Key Exchange and the way this works is does everybody know what a Diffie-Helman Key Exchange is? So a Diffie-Helman Key Exchange is a simple mathematical operation. Each side is to share a public key and then it derives a session key and user drivers can't determine what the session key is. Password Authenticated Key Exchange is the same thing but using a password mixed into that algorithm in some way, there's various different ways to do it but you mix in a password into that algorithm and the end result is that only if both sides know the password does the session key actually calculate out correctly. And so we use this in order to have no password on the wire again just like the encrypted timestamp but notice that there's no timestamp involved at all. So where before if you had a time synchronization issue you could get a failure and you could flip it back with an offset. Now we can just do this in one exchange no time synchronization is required at all. No offline dictionary attacks are possible at all. So one of the difficult problems with encrypted timestamp is that because you're encrypting a timestamp which is a known value in your password anyone who eavesdrops the encrypted packet that's sent can perform an offline dictionary attack against your password against that packet which is a way that looks correct than they've probably guessed your password. PIC does not allow for this which is a big win for us. It also means that we don't have to have any third party trust so the idea of having a fast tunnel goes away at least for the case that we care about which is sending multi-factor authentication and PIC permits us to actually encrypt a second factor in the same packet that's sent to validate the first factor. So we perform this key exchange and then we send a validator to prove that we know the first factor but at the same time we also send the second factor in an encrypted packet at the same time. We hand those both to the server and the server will say yes or no and so you don't know which factor succeeded or failed which is exactly the copy we want. Everything's done in encryption and there's no third party trust report so you don't have to set up a fast tunnel it's a really great user experience. We also had a proof of concept that was done here. Don't use it, it's insecure. It says that on the website. It was just a proof of concept to see if we could actually make it work and we still needed some very secure features. So don't use it, it's insecure but we did have a proof of concept. Our current state is that we have published an internet draft for this so it's going to be standardized. So we're going to implement all the preparatory work that we needed to actually implement this. So there were various... What's up? When you say in Kerberos, you mean in MIT? In MIT Kerberos, yep. So in MIT Kerberos there were, in their code base there were some things we needed to tweak so that we could implement this as a plugin and our plan now is to go implement it as the plugin and then eventually once it's all working this is very exciting along with the authenticators this is the kind of twin hands if you will of our future Kerberos approach and this will provide a really good user experience for multi-factor authentication because we've now defined a generic mechanism before doing multi-factor authentication rather than every multi-factor person doing their own pre-authenticism so that will be beneficial as well. We would really like some improved browser support. Yeah. So this is one of the things we've started to look at we have no concrete plans here but we would really like your help we don't have a browser person on our team so if you know a browser person who's looking for a fun side project we would definitely like some help here and the simple idea is that when browsers first implemented Kerberos they did so based upon the assumptions of the past. Remember that first side with a lot of the downsides so browsers basically had all those same assumptions of all the stuff that was done in the past and that was how they built their support but we've done a lot of stuff since then and so the experience in browsers could be much more polished today than it could yesterday and so we would like to bring that same level of polish to the browser experience but we don't have a browser guy so if you have a browser guy and he wants to work on this maybe it's ever possible or will ever be possible for browsers to ship with this enabled by default they do now because the last you have to configure it because the presumption is you need client configuration the last I recall was that there was a setting and you had to enable it to send existing principles for certain domains but it basically took every principle you had and threw them at the server and the one worked which was actually a disclosure vulnerability and so nobody turns it on yes there are definitely ways around this one of the nice things about PIC is that there is absolutely no benefit to a rogue server gaining an authentication packet which is something we've never had before because before you could if you received a packet you could do an offline dictionary attack for instance against the password but once we have PIC landed you can send authentication packets all day long to whatever server you want and they can't gain any information unless they already know the password which is what they're trying to get anyway so the answer is basically all of this polished stuff that we've been doing under the covers just now needs to be brought into the user experience of the browser so returning to our first slide you see we've actually gained we've gained some upsides here we have the dictionary attack problem that we've identified we've solved with PIC we have the one-time password support and with authenticators we're going to get per service policy on that and we've eliminated all the downsides so the basic plan here if you can't guess what we're doing with this slide go to poor Kerberos it's a much better environment today than it used to be and there's lots of great tools like free IPA which is by the way part of our server product so it's definitely something that we want to encourage you to use so with that I'm going to turn it over to Roddy alright so Nathaniel has talked about in a more abstract what we have for the past and future of Kerberos but what we haven't really covered is how do you get this that's what I want to talk a little bit about so to quickly recap Kerberos, right, it's a client server you need some servers we call that a KDC and as Nathaniel mentioned it's kind of a pain to deploy if you try and do it by hand and haven't done it before it's just the IPA because you turn it on you run and install and you're done you're done man assuming you don't have an existing infrastructure infrastructure and at the present day the clients need to know some stuff about the servers we have good heuristics for guessing that you mentioned pulling the server from the realm name when you do a Knet and things like that but really what you need is something that stands all that up for you and that's free IPA so free IPA is a push button solution in the sense that you run one command and it goes and it gives you all of the things you could want you have your realm, you have your nice interface you have a powerful API everything else that makes it look like AD essentially and the magic behind all of that and you don't so if you want to have a client yes thank you you can run IPA client install but you can also use only parts of the realm with SSSD so for instance the way this laptop is set up I'm not a client in the realm but I can take advantage of a lot of the realm features by using SSSD and pulling my login information from there for instance the system security services daemon that is the back room for us that's a story I'll tell later most people who are behind that I know and I'm sorry but I wish SSSD would take over war because it's the thing that seems to always work well it's in deviant now yes it's in deviant now what's up, it's in BSD now you put it in BSD so now y'all don't think it's easy can we actually make it in? I know people have it in the plugins yeah I don't know if it's in form but I know that in real world it works I think it is maintained one of the two BSD customers okay so the first way you can get in as a client application developer into using all of this great stuff your free IPA realm, your KDC, your Kerberos is the GSS API and we alluded earlier there have been some incompatibilities between Kerberos implementations and the GSS API helps to fix a lot of that it's a standardized API, it's got RFCs what do we have up there? three of them and it'll even do Microsoft if you really want it but it's not just Kerberos it has other mechanisms as well for my purposes I'm mostly concerned with Kerberos but if you want to do other things you can use Spinago and whatnot and it's a relatively simple API there's five functions you really need to care about import name, grab your username in its set context is how you begin as the first party in exchange except set context is the second party so you want to think client, server and then wrap and unwrap are for your encryption which you're going to do your encryption GSS API can also do encryption it doesn't do just authentication so you can authenticate it and also do encryption I'm emphasizing those two in particular because there are a number of applications in the wild that they get the first three right and it's amazing and it looks to all the world like Kerberos is being used fully and you get there and there's no encryption so yes you've done all this authentication but it counts for very little and it involves TLS yeah when all they had to do was call two functions yeah thank you can I have a question is there a proper documentation for GSS API? yes RFC 2743 and 2744 2744 it is right MIT did a good job on cleaning the APIs and putting documentation on the documentation portal so I have seen the efforts around that a couple of years ago they were very decent so I suspect you will find a lot of guidance there and SEMA is here as well and he's the GSS expert in the room so you can find him and ask him any questions you want I still find a lot of this to be pretty deep wizard stuff anyway but if you it's still not easy it's getting better yeah it's getting better RFCs can be a little intimidating but 2744 really does cover a lot of what you need to know in order to actually use this and yes there are other functions in there besides these five but these are the five that you really need to get started don't use Modoc the answer to that don't use Modoc use Modoc GSS API so we have been switching we started with several projects and Modoc Curve is built on the old time and it has a lot of craft in there which is not developable as we would believe it yeah so another way of calling into all of this Kerberos magic is SASL which is also standardized though I like the RFC rather less though it does have more mechanism support out of the box and it's easier to extend you drop a line in a config file and add a .so and it takes care of it it also has support for protocol support so when you have a protocol that maybe has a built in security layer say you connect SSL to a server and then you go into SASL you can inform SASL that you have done this and that the security is there from that which is something that you can't do with GSS API and yes the protocol does also allow for authentication without encryption which is kind of unfortunate but I can't win everything SASL is a bit more verbose there are a bunch more functions who we've got my two crypto functions at the bottom here that's the goal state just get to encode and decode but the way the API works is a bit more you request something from the library and the library says okay well you didn't give me enough information and then it gives you back a struct and you go fill in the fields in the struct object oriented notice that the API where it's simple in the title is actually more verbose what does SASL stand for? simple authentication and security layer? security layer it's not simple I think I think it's simple in comparison to the things that we did yeah probably okay so to recap SASL is more powerful but it is a little bit harder to use this is in part because GSS API is a mechanism you can use with SASL so it subsumes everything don't take away from this slide that you should always use SASL you should judge on it case by case basis so because this is a fedora conference we should talk about what the state of using this in fedora is so the default way of doing this because these are CAPIs you can call into your libraries lib SASL lib GSS API and the same is true for Go if you're a Go person and Haskell as well though that's not ideal okay for some others we have packaging GSS API is a bit stronger than the packaging for SASL Python and Ruby sort of hurt a little bit here and Rust and Erlang are forthcoming so you want to tell us about Perl I like it you know I'm sorry to say I assume it's there though because it's Perl Perl isn't ffi right yes there is a there is a way to write major findings somewhat like there is for Python except you don't have to deal with some of your stuff on a personal level I'm not sure I want to encourage the proliferation of additional Perl but that's not other people like Perl there are certain things that already exist that are written in it we also want to strongly suggest that you do not attempt to reimplement any of these things in negative languages you should definitely use bindings because this is a very difficult to get the security correct and these are very matured GSS API and SASL are very matured implementation of long histories although Java does a lot of stuff on its own right and it's one of the reasons why Java kind of lives in its own universe because they also implement Kerberos related stuff GSS API and others but it's not the same experience you get from other places the API is different because of course it is did you have a question yes we absolutely support Python 3 with that we encourage Python 3 both Python 2 and Python 3 we've tested out through Python 3.4 we tested Python 2.3 and 3.4 as well as 2.7 do we know when 3.5 is coming soon right it's all the soon it's in the future don't worry about that yet so in that case I should add it to my test matrix let's talk about that if not so as an application developer you probably don't want to go all bone into the night using all of these amazing new technologies that no one else is using you'd like to see some other applications using them already so here are some if you do email in a desktop client you see an IMAP SMTP those can both do Kerberos in a lot of enterprise environments they will but this is often okay so IRC XMPP they do Sassel FreeNode in particular supports Sassel for authentication and if you're someone who has ever tried to connect to FreeNode over Tor you know how exciting that is to set up so the user experience there is a little bit lacking but it's at least there CUPS if you wanted to K in it in order to print you can do that and your system log if Fedora isn't using this as the main log you can still consume RSS log for pieces and that will do Kerberized tunneling for log aggregation through the GSS API and SSH this is the one that we like to show off because it's the clearest is you know you K in it and you SSH to the host and it doesn't prompt you for the password because it uses GSS API for your authentication it has its own issues but it mostly works we've also got some databases this is stuff that I've been working on recently and is in the process of being workshop streamed but if you ever wanted to talk GSS API to your database you can do that too and in tandem with that for messaging Cupid Proton will support Sassel sorry already support Sassel as a release 0.1 I think and the goal with both of those is to have a fully Kerberized open stack if you desire that we're not quite there yet but that's a lot of the work GSS proxy also Bear is mentioning for adding additional privilege separation on top of the way credential handling works so if you as a CIS admin maybe don't want your service to have access to all of the possible credentials that could need and maybe do access control on that you can spin up the GSS proxy and GSS proxy will allow for that layer unfortunately Simo's not here that's his project yeah so the video there is if you have a network-facing service and it is generated you wouldn't find the keys in the status memory because all the keys are in another process it's a separate process which contains all of the keys that could be used if the process that's doing authentication encryption is compromised they can't access the keys I mean if you do that you're kind of sunny anyway as we mentioned Mono GSS API for Apache instead of Mono Kerb and yes we would like some help on the browser UX it's there, it's not great yeah, so one last one we didn't want to talk about is the work we've done actually another guy who's not here, Nikos wrote some integration for open connect VPN and this is actually a really fascinating integration because it uses the proxy support which actually allows you to proxy the Kerberos request through the VPN server to your KDC to get back a ticket and then you can use the ticket to log into the VPN okay, so what this means is that you actually have a single sign-on experience even outside the infrastructure you can get your Kerberos ticket signed into the VPN do all of your stuff now with one single logon and we're working on trying to figure out how to make that work in the desktop environment so that you can log in with SSSD get your ticket automatically connected to the VPN that works with the HTTPS stuff, right? yeah, so the reason that this support was able to come in so quickly was because this is an SSL VPN and it all uses HTTPS and we already have the Spenego mechanism for doing Kerberos so they just added support for that and then they added support for proxy Kerberos packets so really smooth little environments and it bears playing with that okay that's it for our content any questions we didn't get to go for it if you're interested in just Kerberos GSS API is probably the easiest to go with but there are additional considerations for InDraw in the future that may cause you to go one way or the other both will work if you need also more Kerberos specific Fibli bits to use the technical term GSS API will offer you a few more Fibli bits and there's also a bunch of GSS API extensions where there is supposed to be more stuff whereas more of a SSL is more a generic I have a list of mechanisms that I support it may be I may support GSS API I may support passwords for some reason and then the server might support a lot of those and there's a lot of negotiation there so it probably depends on the protocol that is inside so the more interoperable the protocol needs to be the higher you need to build so SSL is probably you can want to use the client with all sorts of different implementations in the server side if you are pretty sure that there's not much interoperability and it is just your client and just your server then in this case for GSS API with a key tab you can either call a specific function for acquiring credentials with a key tab or set an environment variable and then for SSL you would I believe add a line to the SSL config file and it would pick it up we're actually out of time but if you have questions we'll stand in the back and come ask them thank you everyone