[00:00.000 --> 00:12.660] Okay. So, hello everyone. We'll start in a minute. If the talk will have 20 minutes, [00:12.660 --> 00:17.760] and after that, there will be space for questions. If you have questions, please write them into [00:17.760 --> 00:26.560] the metrics room, or we will try to run around with the mic. So, thank you all for coming, [00:26.560 --> 00:32.280] let's, I will give a word to Alexander Bokovoy, who will have the first presentation about [00:32.280 --> 00:47.000] enabling FIDO in support for remote-lemonaged users. Yes. Thank you, Jakob. Thank you everyone [00:47.000 --> 00:54.280] who came today in this drizzle day into a room that is not so easy to find. Let's fight [00:54.280 --> 01:06.160] security with obscurity. Okay. The talk I'm giving here is actually, it was supposed to [01:06.160 --> 01:16.840] be done by Ika, who drives this effort at Red Hat. And I have another talk in the afternoon [01:16.840 --> 01:23.800] in the main tracks about passwordless Linux, where we are. This is part of it, but not [01:23.800 --> 01:29.200] the full stuff. So, it's kind of a preview of where we are, hopefully with demos and [01:29.200 --> 01:44.840] without demo effect. Let's go. I hope I will be able to get something working. Nice. My [01:44.840 --> 02:08.040] laptop actually locked up. Really? Yeah, I'm trying. It doesn't want to. Okay. [02:08.040 --> 02:35.760] We'll get there. No, no. So, the fun part is, this is old laptop. This is really old laptop. [02:35.760 --> 02:45.400] My actual laptop got the battery puffed up. So, it literally looks like this now. It's [02:45.400 --> 02:54.240] sort of a hat, right? Here we're working there. But it means that I cannot fly with that kind [02:54.240 --> 03:01.800] of laptop. And this one is maybe six or seven years old. So, it's a bit surprisingly slow [03:01.800 --> 03:14.160] for contemporary software. We are booting Fedora. Okay. So, this talk is about a very [03:14.160 --> 03:24.360] simple thing. Basically, this is the hardware incorporation of what people call nowadays [03:24.360 --> 03:35.720] as a pass key or web orphan, which is known as 5.2 set of specifications. And actually, [03:35.720 --> 03:44.720] we start with a small demo, right? If I get the screen working. Okay. I'm not getting. [03:44.720 --> 03:50.000] I don't know what you see there. Maybe you are not seeing anything. But I actually was [03:50.000 --> 03:57.800] able to log in with this token. And what I will be talking about is how I actually get [03:57.800 --> 04:18.120] it. Now, let's see. Yeah. Yeah. This is because I logged in without password. The password [04:18.120 --> 04:28.880] storage manager asks me to enter the password to unlock the storage manager. Not to log [04:28.880 --> 04:35.040] in with the password. That's another part of the stuff that we have to fix before we [04:35.040 --> 04:42.600] will be able to get into the Linux without all the passwords. Okay. Let me get to the [04:42.600 --> 05:10.320] top. It's really slow. I really hope to get this working. [05:10.320 --> 05:27.200] Yay. Finally. So, some time ago, we at Red Hat were working on the identity management [05:27.200 --> 05:36.640] on security, on the stuff like free AP and SSSD. We started looking into a couple things. [05:36.640 --> 05:49.360] One of them is how we can get password less into our systems. Mostly, we talk about remote [05:49.360 --> 05:58.800] servers because that's what most of our customers are using. And many of those customers started [05:58.800 --> 06:11.600] asking about the thing that sort of required them to be enforced for them from the governments [06:11.600 --> 06:18.920] and so on. So, one of those things that is forced it is FIDO2 or web often because, well, [06:18.920 --> 06:25.000] everybody else supports it. Where everybody else means all these web applications, all [06:25.000 --> 06:34.440] the other operating systems like Microsoft Windows and the others. And, of course, there [06:34.440 --> 06:42.360] are properties that are related to this. They are all nice. But the reality is that you [06:42.360 --> 06:50.960] get all of this nicely working mostly in browsers, at least on Linux. And not in all browsers. [06:50.960 --> 06:59.320] Some browsers do not support web often. Workflow some do. But we need to get these logins [06:59.320 --> 07:04.840] into the actual systems. Because if you are not able to log into these systems, you cannot [07:04.840 --> 07:11.560] use this password less. And, of course, there are, from the technical point of view, it's [07:11.560 --> 07:19.680] a combination of some PAM modules and some changes to applications and so on. It shouldn't [07:19.680 --> 07:24.920] be that hard, right? There are already PAM modules that implement this. The problem is [07:24.920 --> 07:31.000] that if you look at this from systematic point of view, if you manage thousands of hosts [07:31.000 --> 07:40.480] where you need to get access with the credentials stored somewhere, you need better than just [07:40.480 --> 07:45.960] everything defined on the single machine. So, we started looking into what we have. We have [07:45.960 --> 07:53.240] centralized identity management. We have free IPA. We have SSSD on the client side that [07:53.240 --> 07:59.880] allows to query these different identity management, including free IPA and so on. So, we started [07:59.880 --> 08:10.120] looking what we can create all of this. And we wanted to enable use of FIDL 2 in the console [08:10.120 --> 08:16.360] for these remote-managed users. We start with local authentication. This is what is working [08:16.360 --> 08:23.160] now. It didn't work like a couple of weeks ago. We are already having some progress. And [08:23.160 --> 08:29.280] the second part will be remote authentication, but with at least, because all the things [08:29.280 --> 08:36.920] like remote authentication using native SSH, for example, protocol, it's really not about [08:36.920 --> 08:44.480] this. It's not compatible with the local use of the FIDL 2. It encapsulates some of the [08:44.480 --> 08:53.800] principles, but it converts kind of use or assertion of the FIDL 2 into a different form [08:53.800 --> 09:02.920] specific to SSH and cannot be reused for anything else. So, the reality is that's coming from [09:02.920 --> 09:09.240] where all these governmental admins or big organizations admins are getting the pressure [09:09.240 --> 09:18.200] from. This pressure came actually a year ago in the form of what they call zero-trust memorandum. [09:18.200 --> 09:27.920] The zero-trust memorandum is effectively an answer by the executive office of the president [09:27.920 --> 09:37.600] of the United States to the set of threats that they got over the last decade, or visualizer, [09:37.600 --> 09:47.600] at least in public. So, this memorandum basically states by the end of fiscal year 2024 a number [09:47.600 --> 09:54.920] of things should happen in the governmental organizations. There are, I think, five big [09:54.920 --> 10:05.480] targets that they have to go, and one of these targets is to switch to password less everywhere. [10:05.480 --> 10:12.400] And to say the truth, governmental organizations in the U.S. already use a password less form [10:12.400 --> 10:22.320] with smart cards. But web often is called out as one of the recommended ways of doing [10:22.320 --> 10:31.320] it in the memorandum. So, zero-trust memorandum says that basically you have to use a personal [10:31.320 --> 10:40.000] identity verification or smart cards. We already support that. And web often is another approach. [10:40.000 --> 10:47.560] And go there. There you go. You see the customers or prospective customers getting pressure from [10:47.560 --> 10:56.560] there, those who drive them, who give the budgets and so on. And then these customers [10:56.560 --> 11:02.920] come to Red Hat and all other companies and ask to get this working, because they have [11:02.920 --> 11:10.160] to comply. Not us comply with this, but the customers comply with this. The lucky part [11:10.160 --> 11:18.480] we have is that all of this, actually in the interest also of the community, because, well, [11:18.480 --> 11:25.040] it simply improves our state, not only at work, but also at home. If we switch to password [11:25.040 --> 11:32.320] less everywhere, we get a bit secure environment, I hope, given the practices that we preach [11:32.320 --> 11:43.640] to at home. But this is the part. So, if you have remotely-managed users, basically define [11:43.640 --> 11:52.040] somewhere, centralize it, your accounts, your post-exidentity, your home directory, your [11:52.040 --> 12:01.400] shell, and so on, somewhere should be defined which password less credentials you can use. [12:01.400 --> 12:07.920] These credentials should be delivered locally. And if you have a device like this one, or [12:07.920 --> 12:16.000] maybe the one on the phone, which we do not support yet, it needs to be verified. It needs [12:16.000 --> 12:24.800] to be an engaged way of applying and so on. And in these centralized environments, we [12:24.800 --> 12:30.960] often have to deal with the fact that you are not only logging into the single machine, [12:30.960 --> 12:38.840] you are jumping somewhere. You are interoperating with other applications. Typically, this transfer [12:38.840 --> 12:45.440] of authentication state happens through transition from your local authentication to something [12:45.440 --> 12:54.120] like Kerberos, which issues a ticket recording your authenticated state, and then uses this [12:54.120 --> 13:01.920] ticket to issue other tickets to other services in the environment that's being built. [13:01.920 --> 13:12.840] So on the high level, in principle, all the stuff that we deal with in free APNSS is already. [13:12.840 --> 13:22.240] For FIDAR 2, this is the new thing for us, but we use LibFIDAR 2 library that's already [13:22.240 --> 13:30.680] existing and shipped in many distributions for the implementation of the FIDAR 2 stuff. [13:30.680 --> 13:39.360] We store the data at the LDAP server and fetch there that's SSSDXL set. And the other part [13:39.360 --> 13:48.720] is we integrate with free APNSS Kerberos implementation to provide the transition from FIDAR 2 to Kerberos. [13:48.720 --> 13:54.720] So for the local authentication, what happens is that you have the SSSD running on the machine. [13:54.720 --> 14:02.120] It picks up the user information from LDAP record for that user. Part of that record [14:02.120 --> 14:09.200] is the specification of the PASCII recorded details, pretty much like in the traditional [14:09.200 --> 14:16.760] way you store them somewhere on the disk, but here you store them remotely. Then when [14:16.760 --> 14:27.040] the token is added and there's a need to log in over a PAM, any PAM service, you get LibFIDAR [14:27.040 --> 14:34.760] 2 communicating with the device and performing its magic comparing with the record that you [14:34.760 --> 14:43.120] have. So in LDAP, this looks like this. I intentionally included a bunch of stuff here, [14:43.120 --> 14:50.680] but literally all we care about is that we have this PASCII attribute. And obviously [14:50.680 --> 14:57.200] in LDAP, it's a structured store, so you have to have an object class that defines the use [14:57.200 --> 15:06.600] of this attribute. And on IPA level, this looks like this. There is a user information which [15:06.600 --> 15:14.640] also has this PASCII mapping. This is not in the released version of IPA yet. Hopefully by, [15:14.640 --> 15:23.280] I hope, by spring we will get this, but later I will show you where you can get the test version. [15:23.280 --> 15:33.120] So in IPA case only, you get after this login, which is currently not working, so you get a [15:33.120 --> 15:41.920] Kerberos ticket. This is high-level overview of how it goes in. The presentation is available on [15:41.920 --> 15:50.080] the site, so I'm not focusing on describing these details, but effectively we extended MIT [15:50.080 --> 16:00.880] Kerberos implementation to allow us to communicate with the KDC. All these details related to [16:00.880 --> 16:10.600] web often implementation. So behind KDC on IPA, on free IPA server, we have relay and party [16:10.600 --> 16:17.760] implementation that performs part of this authentication and then uses Kerberos protocol [16:17.760 --> 16:27.280] to transfer the bits between the two sites. So tested. So this is actually a demo of what I kind [16:27.280 --> 16:39.040] of ran before I got my presentation working. So this is the locked-in screen this morning. And to [16:39.040 --> 16:46.840] unlock, I have to insert this PASCII and press enter. You don't see the part of the full message [16:46.840 --> 16:58.320] because it's so large compared to the actual input stream that GDM shows. Then I just activate the [16:58.320 --> 17:08.600] device and magic happens. I logged in. How you can play with this yourself if you want to set up? [17:08.600 --> 17:17.880] Iker wrote some instructions in this black post and he maintains copper wrapper for Fedora. Fedora [17:17.880 --> 17:24.360] 36 and 37 at this point. So you can get SSSD packages. There is one package that is not [17:24.360 --> 17:32.360] installed by default. This is exactly your support for FIDO2, SSSD dash PASCII. Then you need to [17:32.360 --> 17:38.360] enable it in the SSSD configuration. But if you follow Iker's instructions, you should get it [17:38.360 --> 17:48.560] working. Right now it only works with free IPA because we have free IPA from that copper wrapper [17:48.560 --> 17:58.320] because it has the support for storing the PASCII in the old app server. I will stop here [17:58.320 --> 18:03.320] because I have like three minutes and I would like to hear any questions and feedback. This is [18:03.320 --> 18:10.120] sort of early stage. I will show a bit more in the afternoon with the bigger presentation that they [18:10.120 --> 18:21.160] have at the main track. There will be a bit more demos there. But we really would love to hear [18:21.160 --> 18:44.120] your feedback and what you want to see working there. I have a question. So what happens if the [18:44.120 --> 18:55.000] key is lost or stopped working or something like that? So what happens if the key is lost or stops [18:55.000 --> 19:04.760] working because it's a hardware that might blow up, right? That totally depends on how the system [19:04.760 --> 19:13.800] is defined. If the system is defined to allow fallback to other PASCIIs or it's allowed to use [19:13.800 --> 19:21.880] a different authentication method, the fall-through to those methods will happen. If you want to, [19:21.880 --> 19:33.480] if the key is lost, for example, user or admin can remove from, let me get here, from the user [19:33.480 --> 19:40.880] entry, you can remove the PASCII mapping and then this user wouldn't be able to use this PASCII [19:40.880 --> 19:52.960] anymore. So in practice, this is a process thing. You have to define your policies for organizational [19:52.960 --> 20:01.360] policies, how you handle any lost credentials. There's no difference with this. Some systems [20:01.360 --> 20:07.920] like, for example, Apple in MacOS actually forces you to define two separate PASCIIs, [20:07.920 --> 20:14.640] two separate tokens, if you enable one because they think that you most likely will lose one. [20:14.640 --> 20:24.120] They probably figured out something about the users. Okay. Any other question? [20:24.120 --> 20:40.960] There's nothing to pass here. So the whole, I'm not going into details of web often implementation [20:40.960 --> 20:49.280] itself. It's fairly secure in this context. Yeah. You have to have actual hardware or [20:49.280 --> 20:58.040] software implementation of the token. You have to have exactly the same key. The private part [20:58.040 --> 21:02.600] of the key is typically not leaving the device. So it's fairly secure in that case. [21:02.600 --> 21:12.720] Hi. Stefan here. Is it possible to add yet another factor? Can you please speak up louder? [21:12.720 --> 21:23.000] Sorry. Can you add another factor to this key that you will bring? I'm sorry. I'm not here. [21:23.000 --> 21:30.800] Guys, could you please silence a bit? Sorry. I will speak out loud. Can you add another [21:30.800 --> 21:37.080] authentication factor to the process, like the OTP token next to this physical key? [21:37.080 --> 21:43.520] So you're asking if there's a possibility to amend use of pass keys with something else? [21:43.520 --> 21:51.960] Exactly. I believe it's possible to, because all of this available over PAM interface, [21:51.960 --> 21:59.520] you can stack up several PAM modules in it. In SSSD, that wouldn't be possible at this [21:59.520 --> 22:07.200] moment to get it. But maybe this would be a good idea for going forward to allow extending [22:07.200 --> 22:15.280] and forcing to use several methods. Yeah. I will write this down. Okay. I guess I'm out of time. [22:15.280 --> 22:20.160] I think we can still have one last question if there is some. Okay. [22:20.160 --> 22:31.680] Nice, nice. Technology. I have a question about user nameless login. Is it also supported? [22:31.680 --> 22:36.160] Because this is the problem of FIDA 2 that you can have discoverable credentials stored on the [22:36.160 --> 22:42.480] token. So the only thing you do is plug in the token and use a fingerprint. Does it also support [22:42.480 --> 22:51.960] user nameless and passwordless login? So the question is whether login where a system, [22:51.960 --> 23:00.120] when you insert the token, identifies to which user this token belongs to. Does it work or not? [23:00.120 --> 23:07.840] Implementation as right now does not support it. There is a plan to support discoverable [23:07.840 --> 23:17.080] credentials. There are a few things that I would like to address in a presentation in the afternoon [23:17.080 --> 23:28.720] related to UX. Basically, right now, we are very limited in how graphical environments allow [23:28.720 --> 23:34.360] to do this discoverability. So for example, for the smart cards, a couple years ago, [23:34.360 --> 23:44.080] we changed the GNOME GDM to extend to allow picking up different identities from the smart [23:44.080 --> 23:53.200] card. And if user has, for example, several identities associated with the same smart card, [23:53.200 --> 24:04.160] then GDM allows to pick up the right one. The same problem comes with the past keys. Maybe I meant [24:04.160 --> 24:10.560] it with the idea of discoverable ones, but it's the same story. So it's more like not the back end, [24:10.560 --> 24:17.760] but rather the front end, the one that presents you. And user experience is pretty bad right now [24:17.760 --> 24:24.640] on this. But the plan is to fix it eventually. Okay. Thank you, Alexander, for the talk. Thank you [24:24.640 --> 24:36.320] for all the questions. Thank you.