 Hi, everybody. My name is Iker Pedrosa. I'm a senior software engineer at Red Hat. I'm very glad to be here and to see some faces that, well, I didn't know in person. It's very nice to be here in Renault. So I work for the Identity Management, where I'm part of the SSSD team, where we do the client-side authentication. And I will do this presentation about FIDO 2 authentication for centralized managed users. So the agenda for today is that I will start with an introduction of what FIDO 2 is and why this is interesting for us. Then I will explain a little bit the reality that the organizations and the customers that we have are facing. Then I will do a little high-level overview of what this implementation that we are doing is about. Next, I will do a little demo, and I will share the testing playground that you can use to test this environment on your laptops. Then I will speak about the future lines and what this new implementation holds for us. And finally, I will have time for the Q&A. So let's start with the introduction. So why FIDO 2 and Web Pousing is interesting. First of all, because it's passwordless, so you don't need any password. There's a public key cryptography involved in it, and we are using the public key to authenticate the user. Then it's also interesting because it enables strong authentication, as you will be able to use multi-factor authentication for the authentication. It also reduces the risk of a data breach because we will not be reducing the passwords between sites. And finally, it reduces the efficient rates. So what are currently the workflows that are enabled for FIDO 2 and Web Pousing? The first one is the user authentication in a website. This is the most common one. And the reason why this protocol was born. Then we also have the local user authentication in a Linux system. For that, we use PAM-U2F module from Ubico. And then we have the Azure AD user authentication in Windows. So remotely managed users for Windows can use Azure AD hosted environments to authenticate. But we are missing one of the workflows. And the objective of this workflow is to do FIDO 2 and Web Pousing authentication. We will use the passwordless part. We will also enable the remotely managed users. They will be stored in an LAP server. More specifically, if you are using the free IPA server, you will have a better integration. Then we have the local authentication, as we'll use the FIDO 2 key to authenticate locally. And finally, we'll also be enabling the Kerberos part, where you will be able to do a remote authentication to other services and places in the network. So this is the workflows that will be enabling here. So we have a user with a FIDO 2 key. You will have to connect this key to the client where SSSD is running. And then there are two different workflows. On the one hand, we have the remote authentication with the free IPA server, where we send the information from the FIDO 2 key to the server. And the Kerberos part is able to authenticate the user. But also, in case the free IPA server is down or you are using some other LAP server, like Active Directory or DS389, we also have the client-side authentication, which is local. For this case, what we do is we obtain the user credentials from the server, and we do the authentication locally. So now let's speak about the reality. So in January 2022, the US government released a memorandum, which is detail moving the US government towards zero trust cybersecurity principles. The idea behind this is that we should move towards more secure environments. The idea is to have these implementations finished by the end of 2024. So the guiding principle for this zero trust model is that no actor, system network or service working within the security perimeter or outside of it is trusted. So all the communications must be encrypted and authenticated as soon as practicable. This way, the users can use the applications from anywhere in the world or in the internet. Well, this is a high-level overview for this zero trust model, but let's focus on the part from the memorandum that speaks about user authentication. So briefly explained, the memorandum explains several things. The first of all is that we should have the users centrally managed, and then that we should use passwordless and multi-factor authentication to authenticate the users. Apart from that, the users should be able to sign in once and then use the services or applications that are available in the IT infrastructure from this company or agency or government. So the memorandum specifically mentions two different protocols. The first one is PIF, which are these smart cards that SSSD and Free API already enabled some time ago. And then it also mentions Fidochu and WebAuthn. And this is the new implementation that we are working on right now. If you'd like to know more about this memorandum, it's available on the internet. You just need to check for the title that I mentioned in the previous slide, and you will be able to read it. So now let's speak about the high-level technical details. So for the Fidochu workflow for remotely managed users, we have two different workflows. The first one is the registration, and then we have the authentication. For the registration, we need to connect the Fidochu key to the device, and then use the SSSCTL command, provided by SSSD, to register the user. This will output the key mapping data. This key mapping data needs to be stored in the LDAP server. And for that, we'll be able to use some specific commands from FreeIPA, or in the case of Active Directory, the graphical interface, or if you are using some other server, LDAP add or LDAP modify commands. In the case of the FreeIPA server, you can do both steps with a single command. I will show you later on this command. And then we have the authentication part, where we, again, need to connect the key to the system. And we'll use, well, some graphical interface or the terminal to authenticate. In the case of the FreeIPA server, the agri-velo-sticker will be issued alongside the authentication. Thank you. So what are the technologies involved in this new implementation? On the one side, we have the Fidochu and WebAuthn for password-less and multi-factor authentication. Then we have the LDAP server to store and manage the remotely managed users. Then we have the Kerberos part, well, as I already mentioned in the FreeIPA case, you will get a Kerberos ticket alongside the authentication. And finally, we have the SSSD to manage the client-side authentication. It is in charge of integrating the communication with the Fidochu device, the LDAP server. And finally, the Kerberos ticket request. If you'd like to know more about this implementation, you can check the following three design pages. The first two are from SSSD. The last one is from FreeIPA. We divided the SSSD part in two because it's kind of complex. And in the first part, we spoke about the local PASCI authentication. And in the second part, we defined the Kerberos integration. So now, let's do the demo. People in the audience, will you be able to hear me if I see? So first of all, I will authenticate as an admin here. OK, so I guess we'll have to skip this part. Don't worry. Yeah, you know what happens here in the demos. I will be able to show you later with the graphical interface how to do this. So just in case you want to play around with this environment, it uses containers. So it's kind of quite easy to use. The first link here, it's a blog post that I wrote explaining all the steps to set up this environment. And in the second link, you have the copper repository where all the packages are stored. So if you already have some environment with FreeIPA and SSSD, you can just use this copper repository to install the packages. So now let's speak about the future lines. I will also show you how it works. So this part of the presentation is about all passwordless authentication mechanisms. So currently, in the department, we are working not just on P2O authentication, but also in external identity providers. So let me show you here. I need to redirect the P2O key here. So now let's select the user, which is the one that has the pass keys or P2O keys assigned. OK, the first message here is insert your pass device, then do something. The message is cut. So this is one of the things that we are working on right now with the desktop team to improve. We'd like to show the complete message here, which would be then press Enter. Apart from that, you are also able to input some data here, but we aren't expecting anything. And we need to improve this. Next, you are requested to enter the PIN. I'm doing it right now. And finally, the FidoChuki LED is blinking. This means that you need to input your fingerprint here. As you can see, we've been able to authenticate locally. But there's a problem here. In the case of the Free API case, we are also requesting a Kerberos ticket. But what happens if we are offline or the network is down? In that case, we'll be able to do a local authentication, but we'll not get the Kerberos ticket. So we need to notify the user somehow that the user experience might be affected by this lack of the Kerberos ticket. So our idea is to show some message here while authenticating, like this welcome to Nomi44 message, or maybe show some notification in the notification toolbar. But as I was already mentioning to you, this isn't just about password layers. This isn't about FidoChuki authentication, but about other password layers' methods. And the other method that we are implementing here is external identity providers. In that case, the workflow for authenticating and authorizing the user is kind of complicated. We need to show some instructions in the login page, which currently isn't possible. Apart from that, the user needs to use a web browser to authenticate. The problem is that, well, it's kind of risky from the security perspective to have a full web browser in the login page, because then some malicious user can go to the computer and start doing some nasty things. So we need to restrict the access to the web pages that the user is able to access. So I recorded here the part for the FidoChuki, but I will not show in it. And before I forget, we also have some general requirement here is that since we are implementing the new workflows in the normal login, we would like to show the same user experience to them or a similar one when possible. So that's all from my side. And now I'd like to hear from you your questions. Sorry, can you repeat the last part loudly? So the question is that if we have enabled some way of do a mass enrollment for this FidoChuki authentication, and the answer currently is no, it's a good feedback because, well, we'll have to think about these big organizations where there are thousands of users that would like to authenticate and register. So yeah, it might be a good idea to have some way of doing this mass enrollment automatically. Thank you. It's two factors in the sense that you have the key and you can enter the pin or the fingerprint to add an additional factor of authentication. But the Kerberos ticket is more related to being able to identify yourself in other network services or applications so that you don't need to sign in more than once when you are on your computer. It means that if you collect all these text lines, I would say that this is not a good way to identify your enemy for several reasons. One of them is that this establishes strong identification of the key and user. The second one, which is one reason these devices exist, is that it wants to disassociate the physical device and the artificial device. And the second one is they have to be in the same place and it creates a lot of power. So at least in 1980s, we do have self-provision. We plan to do self-provision in Louisiana for the kind of war-gaming protocol that will allow you to step up and have the keys because most of these hardware is not, you know, a space grid. It's not sort of like an active use where you've got hundreds of times of insert of the key with the device for several, maybe months or so. So it's normal that these keys fail and you need to replace them. And that's kind of the problem there. So users become probably accustomed to where they are replacing the key. But that's not related to the work that's being done here. We enable you to use any of those keys rather than how you can do this. The keys, the position of admins and that. That part is something that the vendors who produce these keys think. So how to make them more resilient to environmental problems to the fact that these contacts on the key simply bear out that's absolutely correct. I should remind you of my question that I actually meant some kind of self-dating. So it's not that we may be able to do that today, I don't know. But that's actually why I didn't mind about that. And that we were totally correct that these keys should not handle environmental problems. So from user perspective, we didn't have self-provision in ITV. What Iker did not say is where you can get this. So this is in SSSD 290 ready in Fedora R5. You can use it if you have, for example, the nightly if your computer's not releasing yet. But it's in the Gitmaster and in the proper app. So you can install it and play with that. Then you get Fedora's data. For the rest, if you store it in some existing LDAB, store like directory or just normal or all that sort of. Then you get a authentication, but you don't get Kerberos data to a good transition to wouldn't be able to do a single sign-on into other network services. Or I think to sudo and other farm services on the same machine. That's another kind of thing that we can do. But even with that, it's kind of self-service already. What we need to solve before we can give this for users by default is a bunch oflessly mostly made up problems. This is a hard way of access for an application that runs in the background of your system. And then you have to access it to the end goal and you need to have access to the hard way and you need to take that access to this in on the right of the address. And so we want to improve on this side of it before you stumble. And now, Alexander, you've made my life very difficult because I wouldn't know how to summarize everything here that you said. Yeah. Any more questions? You can use that. But you cannot use the one form on your phone like a phone app on Google, try to push it. Now, we don't have support for that yet. We plan to, but as you can see, the UI integration would need to be present there. Because all of them require sort of showing to our phones where your phone has to go to authenticate and so on. So this is ongoing investigation, I would say, together with the best of guys how to get that work in a place of no and then to other UI environment. But it also requires certain support from the actual device. The device doesn't have to have to have to have to see or establish a shortcut and establish this dynamical operation that we're working on. Then, the only thing that's left is this there are four published in the screen. But we also, in 1980s, for example, we allow admins to say that we want physical presence on the keyboard when we are authenticated. So you have to press these buttons to keep whatever the mind looks like this. So there is a small metallic place where you're actually using the press. And you will see in that video, right? Yeah. In the demo, how I actually press it. And that's multi-factor. Something you have, something you process. So this pin code that is there is the information that basically makes this key useless to the person who has no idea what the pin code is. This is something that can be enforced by the admins. So I've entered the pin code. Now I press or touch this thing and I go to key. And I lock the end and now I show that I have it. If I'm offline, like I was when I locked in this laptop, I wouldn't get it first. So this will be offline, what I'm saying, requirements that have been set. The thing here is, is device differing a lot. Knowing which one works which way is something that administrators and users will look at in this kind of business. Unfortunately, nothing on our side will prove to us. Except in program user experience. So showing nice messages, showing as much as possible for these hints there, hints there, one hint that we debate in current please, how long to leak enough information to attackers who try to understand that this key works or not before you will be. But still providing enough information to the user that they didn't get a good example. They cannot enjoy a single sign on afterwards. So these kind of things, they actually need, at least in the backbone programs, they need some extensions and some additional work or notable person in the first place. Or shell login, yeah, we can do some crude message in there already. I also want to have working with more things. Again, POS-T, we choose to call it POS-T as well, just for the sake of, not focusing on the technical. Finally, is important here is, this is just one way of getting a possible less you'll break up smart cards. Smart cards is not a method that basically similar to this one just existed for 10 years now. We simply hunt, and if you're looking for this document that will show the executive memorandum, it actually says, personal identity verification standard. That's the smart card, that's the smart card. So US government basically says, they can use smart cards or use these in future. And the requirement for them is next year you have to switch to one place. And I think it's unfair that only US government enjoys better security. I think it's the whole open source community has to enjoy it, because the reality is they are benefited from our simple methods. I think we should benefit as well. That's the core of the key. And let's work together as a community to actually work really and let them enjoy what we are really ensuring. Thanks to you. So I consider using UVP, but I can only use it using 502 rather than HOTP or TOTP because those are one hand calls. You confirmed that correctly, and the second question is, as far as I know, a lot of these systems do use ECVSA or FVSA, so not that it's most common to do it yet, is there any indication when they will come around and say, hey, here's another memo saying, and now you need to do this with cross-containment. Okay, so the first question is related to other protocols that are available by UVKs, like TOTP or HOTP. And if the requester wants to know if this memorandum is just about FIDO2 or these other protocols, the question is, the answer is that it's only about FIDO2, nothing about other codes or anything like that. And the second question is about, if I understood it correctly, about using some crypto algorithms, specifically, or no, there isn't any reference to crypto algorithms that I'm aware of, but I guess since you are working with the US government, you will need to follow their recommendations for crypto algorithms. So even if it's not here, the government already requests you to use some specific algorithms.