 Good morning folks. Today we are joined by Alexander Bokovi. He's a senior principal software engineer at Red Hat working on things security related and identity management. Today he'll be talking about how the next release of Fedora 39 is planning on providing basic functionality of passwordless authentication. Over to you Alexander. Yes, thank you. So we don't have actually anyone in the room yet because the keynote is still happening so it it will be a bit awkward so I'm as if well actually there are people coming. Great. I was about to start saying that I'm doing a remote presentation. Yeah, but the first two came in just at the beginning of the talk. So this talk is a variation on few talks that I gave earlier this year and I gave a talk at FOSTA in February and then in May at the Samba XP conference and this is the third one and it's like it's a progress talk because the work has been done in the upstreams and in distributions to implement all of what I believe we'll be talking about and that one is kind of the things are changing the target is also changing over time. So let me start with a bit of description who am I. So I'm working at Red Hat on all things related to identity management. Basically anything around free APS, SSD, Samba and Kerberos that's me or my team. I met Red Hat for 12 years now so there's a lot of history in the work that I will be describing today and in fact we kind of going back we follow this actually 30 almost 35 years into 80s and I will be talking about that one at the progress we have today in free APS and related components and the future so what will happen in Fedora 39 and later because it's still not everything is ready there. So past if we look into the past and past is literally like last 30 years for sure. The assumptions that we had on the operating system level were that you really have more or less compatible authentication mechanisms everywhere. So when you try to log into the system you expect that the system actually configured the same way you expect in it to be used so if it's not a system that uses the centralized identity management then you have to make sure that it has all the same user databases all the same passwords and or other other parts and you really want to be able to transfer this state of authentication from one system to another. So people went long way trying to solve this problem and for absolute majority of them only two of those survived it's typically use of the some sort of authentication agents that store you previously authenticated kind of credentials and consult over the network this is typical case for SSH for example when you do login over SSH you kind of have a chance to use authentication agent on your original system and get access to it piped through. There was recently a CVE actually in SSH on an open SSH that exploited this nature of the authentication agent by triggering a lot of literally anything into the authentication engine on your system like on your laptop while you're trying to log in into the remote server. So these things security-wise they have ups and downs even though certain implementations exist like for decades and a typical approach is literally you log in on your let's say desktop or laptop you unlock your secrets manager be it's authentication agent for SSH or it's your desktop like non desktop and then you use these secrets to use the authentication agent and then consume resources based on the secrets right. There's bunch of application specific issues literally you can choose any area you will find problems related to that but the most important problem is when you get you get to go and access resources that out of the scope of the protocol so you want SSH agent to be used or SSH keys to be used but you need to access file system go find a file system implementation like NFS or SMB or any other that actually uses SSH as your authentication method now. So you have to use something else there and typically it's a the password or use of things like Kerberos because Kerberos is another way of transferring your authentication state using the mechanism of issue insert service tickets and then presenting this service tickets between the applications that operate on the client side on the server side and so on. So it's important that in the Kerberos case a long time ago I think more than 30 years ago the decision was made to actually split a state we have the initial authentication from the actual use of the authenticated kind of concept so initial authentication can happen using whatever method you and your key distribution center agree with and over years these methods were developed in like maybe 20 years ago so the use of smart cards became more or less standard way of password list so to say authentication in Kerberos and that's the one used for example by the majority of governmental customers that simply means that you use as a smart card device and you use PKACS 11 smart cards to prove your identity. KDC to issue a ticket granting ticket that contains some information about you that you can use later to ask for service tickets to a particular services and that one is actually a fairly good mechanism because once you get the ticket you present it every time you need to talk to a new service and until this ticket is well it you don't need to reacquire your initial kind of credential use your initial credentials that builds up the idea of single sign-on because you really signed once whether this signed once happens at the login screen on the desktop or it happens well through some other mechanism it's secondary it's the part of the user experience that you build up there but this whole thing works like fairly fairly well and the interesting part is that in free APA and in Fedora specifically we do have this for like almost 10 years if we look at the complex things that you can do with this is what free APA is doing when you enable trust to active directory this is the typical authentication flow that you would see there this is from actually a rel documentation and it just shows that when you're trying to log in over SSH you get asked at the password that password well if there is a password need to use there it goes into the palm and through the palm stack SSSD kind of captures this and acquires a Kerberos ticket for you and on the login to the shell you will get that Kerberos ticket which you can use later but what's happening behind is is a whole machinery of different components being involved and one of them is actually let me try to show here is P11 child that's the one that actually goes with the smart card reader if the one exists and configure it and so on so these are typical things you can see that the smart card reader is more or less on the client side you don't need to get it connected to the server side and so on but if we look into the past actually in 2016 I gave sort of similar presentations for the enterprise desktop with GNOME and free APA also at the flock I think it was Krakow in Krakow and we use their free APA to log in into GNOME environment and we work it with the GNOME guys to extend GNOME to support all of this and this look at like the whole thing look at like this this is I think a VM at that point so I'm logging in with the password just a password to obtain a ticket you can see I have a ticket this is like 2016 and then I use that ticket to come up with the VPN connection and that VPN connection was obtained using Kerberos credentials so you got the service ticket to my open connect VPN endpoint that that side and the next step was actually using the application which is IPA management tool to add since this user can support can use OTP to add the Ubiqui based second factor and instead of being asked it for the password be asked it for actual first factor and second factor from this Ubiqui as soon as I added that Ubiqui I can now lock the screen and next attempt to log in will ask me for factors so now this is not just a password it's sort of password less in a sense that the whatever was your password becomes you're one of the factors to enter but the same way you can do smart cards and so on it's it's kind of the thing that exists in free APA and in Fedora since 2015 also and this is a new ticket now not the old one you can see the I need to stop this because this is the next one and you can use that for a lot of stuff so we did bunch of integrations we did the integration with the GNOME account so that if you have this Kerberos ticket obtained through the login whatever method was there then GNOME accounts tracks it and renews if needed then GNOME browser at that point and later Firefox and later Chrome all obtained the functionality to support single sign-on using Kerberos that that came in the 2015-2016 together with the Fedora and others and yeah that was kind of the base for all of this work you could use this everywhere whether it's in the at work like enterprise or at home this is like enabled many people to go there what happened though from from that time was that we effectively stopped we as as a society effectively stopped using the infrastructure as a as a driving factor for how we work we switched from infrastructure for applications we switched from infrastructure for people to infrastructure for applications you don't care whether your laptop is actually enrolled into the work space you're most likely using some browser as I said to access the resources that provided by applications on your workplace and six seven years ago that wasn't true you have to have your system enrolled you use resources on your domain and so on the change came actually with the profound use of the mobile devices and actually phones killed everything else in in terms of also application development and frameworks and so on so things became increasingly a new main frame ish in the sense that the browser became a new sort of main frame you be quit us in in terms of use and access and so on and for the authentication and most importantly authorization of the applications people switched to off to set of standards and framework of all these flows and to any organizations what happened is basically if you integrate new applications you integrate with the of you bring your authentication into the authorization framework provided by the of and this is important part so okay if my laptop is not anymore really on the network I probably not on the network that is trusted by the domains and so on then how I do trust all of this this all change actually went event eventually went into the situation that is outline and so sort of so called zero trust architecture where effectively organizations said and being forced by the governments around the world to say that we don't trust our infrastructure anymore we have to validate every single thing that happens there but we also don't trust neither end user devices nor we trust our applications so it it kind of changed the game and the idea with this is not new one it's basically a statement of facts everybody is doing that in the world and they have to reapply at the boundary where the application is running reapply this change of kind of see if the things are right authorize every single access and so on so what we get is yeah really things which to be a browser and this story is actually similar to what we had in 2016 except that in 2016 we we dealt with environments where we had captive portals and even today here you have a captive portal to get on the hotel network you have to solve this captive portal thing and in 2016 one of the problems that we outlined was about the same so okay if I want to log in and into my laptop with my enterprise credentials I need to be on the network but in order to be on the network before I log in I have to solve the capture portal and I cannot solve it because well it's it's meaning running untrusted code on a system with pretty much root privileges because of how a system works and this is not Linux only problem this problem is everywhere so some time ago I was talking with Microsoft engineers who were implementing live.com and whatever is called now Azure or Entra ID whatever methods that they use to login to Azure and other resources and they say they had the same issue running an unconfined page to login into the environment before the login into the machine is a constant pain and to solve it there is no real solution other than really running isolated scratched environment they tried to provide like filtering on the level of what URIs are supported but federation as a part of the OAuth space kills it all so if I want to log in let's say to Red Hat's single sign-on system I go to SSO.redhat.com and there I say that I want to log in with my Google stuff so it actually forwards me to the Google page so from the perspective of of the login system like GDM or Windows login system now I am dealing with the content that might from the Google forward to another resource that actually handles my authentication if I never gave the credentials to Google when I created Google account it's like there's simply not possible to solve this in a safe and sane way so we didn't solve that problem for captive portals because that's exactly the same thing we did not solve this yet for today's kind of login in this online services thingy again I'm talking about the login to the session first and then using the browser we don't have yet browser running and the problem is really the same how to bridge these things together how we get there we started with the other side so looking in into the environments we realize that okay you have a browser somewhere you really have a browser when your device and if it's an online service that you have to authenticate with then probably you can run it on the other device to login here so in free IPA we implemented last year and it's available in Fedora 37 and rel 8 7 I think and later you can instruct users to visit the off to base it identity provider and authorize the access so we did some sort of a magic which is based on the device authorization grant flow describe it in the RFC 86 28 which is similar to how you authorize your TV to use your YouTube account sign into YouTube here you sign in into your SSH server but really not into the server you're signing in in your Kerberos environment instead of doing this every time you get the Kerberos ticket and then continue using Kerberos ticket so this looks like this there's a lot of flow things happening but I will let me let me show you I really hope it will work yes so this this looks like this so I use key club here as of to identity provider and this user is authenticated with the password first so now I don't have a security key which is the fighter to key associated with it but I want to associate so I've resister it you can see I'm using the browser here on the other system other system in this case of course these are running on the same system but it doesn't matter I created this key so basically web often and of authentication here and I configured key clock to use web both an authentication if the user is there and then when I try to SSH to the end system I get asked it of these prompt that says hey go to this URI and confirm that you want to access this environment and as a user I get to log in there and use a security key to log in of course the Firefox asks me to confirm what I want to use this key and then asks me to confirm that I want to log in into the system so I logged into the system I got the Kerberos key so what happened here is I traded web often authentication somewhere at some other place into authorization to access the token user info token on this user on that identity provider and I use it that fact as action to issue your ticket granting ticket in Kerberos so it's starting from here I can use Kerberos ticket for everything else I need because this is the ticket granting ticket I can trade it for other services of course doing this every time as is kind of weird and the most weird part is of course I cannot do this in the login because you see the size of the URI I cannot really even display it in GDM it will be cut off at the beginning so authenticate at HTT and then the rest will be cut off you wouldn't see nothing basic there so we need to do something to kind of fix this okay but can we actually go and get away from the network and because this really wants to have this networking thing to happen let's see if I can do that so this is relatively recent demo that I made at Samba XP where I basically took the fighter to token and used it to login into the GNOME environment it still cuts off some information luckily in this case the important one is to enter a PIN and effectively ask user to validate their presence by touching the device is what you really need and it's shown so it works this is actually Rohit at that point but you need a special version of free IPA which is not in Rohit yet it's at this point everything is in the free IPA upstream already but not released we are gonna release this maybe in a couple weeks and so so this is how I log in on this machine as well already and it works also with the environments where you don't have networking access the only thing that is needed is to provision a local account information that SSSD keeps in the cache about this user but the information comes from the network and so you you need to be at least once in the network to get there and so this is good I get the Kerberos ticket and that's that's great it will be a kind of configurable the same way we do this configuration in the rest of IPA authentication type so you can see that you can do the OTP in the same way I did in 2016 you can do a smart cards that's PK in it public key infrastructure use you can do external IDP provider like I show it in the demo before this one or you can use the 5.2 basis tokens which we call pass keys intentionally because we support anything that lipo 5.2 supports and lipo 5.2 plans to also support the Bluetooth base at once and these whatever Android and iOS support but they are not supportable yet but we will get there at some point and it's also a bit complex scheme but it's built on the same architecture we use for other stuff so it's a radius backend to Kerberos that simulates certain things it it just uses radius protocol between Kerberos KDC and itself but it doesn't use other radio stuff so it's kind of a way to extend things we build up this I think in 2012 or 13 to support the two-factor authentication in IPA for Kerberos and for the rest but it's also used for all the other stuff and the same technology can be used also for enabling Samba ID well there is dependency on MIT Kerberos so it will not work with Heimdall that's fine because they don't have a pluggable mechanisms for all these methods we only have them for MIT Kerberos and of course right now it doesn't but I mean extending use of IPA infra to plug behind the Samba ID is possible because it's it's just the LDAP storage of certain bits and then the same utilities can be used to manipulate it so that's in my plans again not Red Hat but my upstream plans to have this support but then other problem is what to target so if we talk about this this is not going to be supported by Microsoft so Windows systems are out of this story they are not going to work on anything like this you can extend authentication packages in Windows and provide your own but reading that for certain things is a bit cumbersome and it's really where you want to have customers because it's it's a lot of work to do so targeting Linux systems we can and we will probably target them given that now with the Fedora OpenQA supporting the testing of Samba AD we can actually test the whole cycle in OpenQA from the client system login and go in there the same way for both IPA and Samba AD once it went in there that's the beauty of the architecture we have in OpenQA so for the desktop integration the bigger kind of thing is of course inadequacy of the UI in well in this case in GDM but it's really extended to other desktop environments as well they are inadequate to anything but like passwords the GDM is more advanced here because we work it together with the GNOME folks and they cover a few other methods as well so for the smart cards for example in 2019 we extended GDM to allow kind of choose which smart card to use for which account to map into and so on and we kind of work now well with them to design how all this extends for all of these methods not just the one because we need to cover the login with external identity provider we need to cover pass keys we need to for the pass keys some of them like the physically ones they work already so we just need to have a bit of nicer UI but the the phone-based pass keys they will require scanning QR codes from the screen and that means also enabling this triangle kind of connection between the different services to discover what to negotiate with and so on so this is like you need to have an infra and if you want to expand this beyond just one desktop environment it needs to be more or less independent of just one so there's a lot of discussion ongoing it's not most of it not public because in the initial steps we have to calibrate tightly over the things but some of it already can be seen in the GNOME's GitLab environment there are some branches there are tickets open and so on so let me show how this looks like this is the proof of concept it's not a full working thing raised road who maintains GDM he wrote a proof of concept for both GDM side and he wrote a special pump module that kind of interoperates with it's not part of SSSD but it's just a separate module to test the proof of concept thing so this is a login with the like imaginary user that has actual authentication associated with some external identity provider and when this user tries to log in it gets to get to see this different dialogue that says okay continue to initiate web login and authenticate with an external device and when the user touches these left right angles arrows and you proceed in the flow so this kind of says okay you can get back and choose another authentication mechanism or you can go forward it's already different from what was before it it's not necessarily the final one but we kind of been discussing this with the UX people so in this case once you proceed a request is being made and the new authentication you are is generated so then convert it into the QR code and then once you did all your job you press the next button and you get logging if you're right at this point when you log in you get the Kerberos ticket issued okay not in this proof of concept of course but the in the real environment if you run with this you get the Kerberos ticket issued and then again you can use this for for the rest in the browser in the other applications mounting your home directory actually and so on but there are other things there is a lot of other things so for example in the real life you often have to log in for example with this token you want to log in but you don't have a network okay you can do that but how you differentiate this case for the user to say that your single sign-on experience will not be there yes you you're logged in because you're allowed to login offline but we need to tell them we need to pop up some information we need to differentiate whether this was a graphical login so that this information this warning will be a pop up somewhere and we need to show the message in a console if it was a SSH for example login and you were unable to get the things in and so on so this is a lot of UX work and improvement on that one to get these things done and then this is where the hard thing comes in it all has to work together it's not just the one project doing their job or two projects or three projects you have to coordinate how things are delivered to and appear together in the distribution that's how we work and we have the Fedora typical we don't advertise most of this work because well coordinating is hard enough promising something when every party can sleep and delay their delivery is also possible so in the true open source fashion it's ready when it's done that's that's how we work but there's we are not the only ones who doing this so there's a lot of parallel efforts from overall community so there are people who are looking at how to get the these past keys information shared across different execution environments so how to get them in flat packs without exposing everything how to get these details back and forth in in different places most of them is not using Kerberos or not really relying on Kerberos so we are not overlapping with anyone we kind of getting this puzzle solved a piece here a piece there and then combining these efforts together so for example I know that system D has some support for fighter 2 integration through leap fighter 2 so we have some hopeful things that the definitions of these past keys in free APA could eventually be used to sign in the encryption of the disk drive and secure boot and all of these things together at the same time we hope and that would be interesting to see how you can actually get this to pre boot environment and get this booting happen there you have to cash some data that ssd provides you have to use it beyond this kind of network able environments and so on so this is a lot of work and it's not like the thing that is the whole experience is delivered in the single release it may well take several releases to complete all this delivery so I know that the GNOME parts wouldn't be ready until maybe March next year if we are happy with what we get which I heard we are not yet so there is still discussion across us and GNOME developers from other distributions how to get all these things working together but the basics are there and I'm really excited that actually it works so I I do log in in my system here with it and I can actually show you it here as a sort of an environment I locked the system so this is using PAM for Vlock authentication so now I can unlock the system it starts blinking on my device because I enabled the user verification and I did verify it I'm sorry and you probably see that my ticket is old oh this is actually a different one this is the Red Hat one let me switch to mine it's this 1215 1215 here that's the new one this is also I'm not on the VPN to my home system but this Kerberos environment uses so-called KDC proxy mechanism so it's proxy in over HTTPS to to my environment similar how we use in Fedora for Kerberos login that's why the login works but I'm officially I'm offline in terms of IPA and SSSD environment so that thing is is here let me grab okay this will not work wouldn't work because I don't have the VPN right let me let me log in there why I don't is this up so I do have now a VPN connection I can actually run it yeah so there is a passkey mapping in my IPA account for well this is my home setup so it's it's like and this one of these keys that you can see there are multiple of them registered I'm just guinea pig in myself with all this thing yeah so this is here as far as we are but really it's enabling you to do all this stuff one thing I did not say is that I can now use this Kerberos ticket or any Kerberos ticket to actually authenticate not just to any other system and that's really SSH to other system right but I can use this to authenticate as a part of the palm authentication on the same machine which makes possible things like if you have a Kerberos ticket you can do sudo base it not on the password or enter in the game into the authorization cycle but with your Kerberos ticket and this is supported in Fedora and rail for about two years now it's a document in the documentation you can actually tune SSSD to specify which Kerberos ticket can be used for that so you can say that the Kerberos ticket obtained it with the PASCII is the one that I'm allowed to use for raising sudo just password will not work just like anything else will not work only if I use FIDO 2 or I use smart card and that kind of thing is already in Fedora I'm I'm asking myself for couple months now that I should write down an article this about all of this because many of the things they exist but they are not discoverable right of course we have this in the humongous rail ID documentation but go find things there that's another part of the story but yeah this is all I have and if you have any questions I think we have maybe five minutes or so thank you okay so I have a few questions so I'll try to take one question then if somebody want to ask they can ask and then I will go back and forth so for your first demo when you were using the UP key and you did configure the UP key through the I think it was free IPA well this is an oath or the token what kind of token did it use there because it wasn't an FIDO 2 you're talking about the first demo yes the first demo from 2016 yes was using UP key with TOTP yeah the TOTP here was just the six digits right I don't I don't recall the exact technical term for okay so this is good how it could configure because the UP key need to have the secret for this yeah this is integrated in free AP it will configure the UP key and yeah okay you can you can set up it with like software one or you can set up with UP key and so on the secret is actually if you don't use this special comment that I had this whatever OTP at UP key if you don't use that one it will print your QR code and it will print you a secret there that you will use to program your UP key manually but if you have if you use that command it will use Python bindings to the UP key thing to program the USB device directly so that's kind of transparent but you need to run that command on the device where you configure it that that's kind of that is the thing that exists for like forever now and maybe you mentioned it I was a little bit distracted so I apologize in advance if it was mentioned but is it possible to set this up standalone without a full-blown free IPA infrastructure so we are focusing on making this work with free APA on the first stage the client side meaning SSSD side only needs to have this information in the local database the local cache that they have the information can be injected into the local database they don't have utilities for that yet there is SSS control but it doesn't have a mode to inject this this is on the plants we will we will do that the idea is to have a replacement for the palm UTF thingy completely because from our experience palm UTF is actually a bit insecure in terms of the configuration management and you really have to split these things this is another part we need to provide the user utilities to make it nicer manageable for common folk right now it's more usable for the admins who know what they do excellent and I'm looking forward to some nice blog post or documentation that would be really helpful thank you yeah okay other questions okay so for the second demo when we're using key clock with I was with with free IPA you were using the key clock interface to configure or fetch a ticket that will be added for the user as far as understood when you clicked on configure secret does this mean that the free IPA is your main ITP and then it just extended the authentication to a Kerberos server where you configure your Kerberos environment which is a free IPA in this case this one is is all done through the Kerberos and only in free IPA so you cannot do this first you cannot do this offline because you have to communicate with both Kerberos KDC and the Kerberos KDC have to communicate with the online identity provider so this requires Kerberos you cannot configure this like standalone okay thank you thank you any more questions thank you