WEBVTT 00:00.000 --> 00:24.000 Thank you. There we go. I don't want to. So, my biggest was on work at Red Hat for cockpit project. 00:24.000 --> 00:33.000 I have three main cones, which I'll show a picture of soon. I live in the North Pole, Sweden, where it's very cold, like minus 30 years of times. 00:33.000 --> 00:41.000 I should post a lot of Federer, so if you're going to look at the slides, there's a link there. I'm going to upload the slides after the talk. 00:41.000 --> 00:53.000 And last but not least, transfer it to human rights. So, just that other way. And there's the cats themselves. So, we have Luna, Lisa, and it's all there. 00:53.000 --> 01:03.000 So, what is cockpit? cockpit is, according to the website, an issues integrated, glanceable, open web-based interface for servers. 01:03.000 --> 01:12.000 So, you have a few different ways of authenticating currently. We prefer to use pan modules, because pan modules is like the default login for servers. 01:12.000 --> 01:19.000 And we just want to rely on that, which makes cockpit a bit unique, and that we are a web-based education. 01:19.000 --> 01:27.000 But you can also use different authentication protocols, like single, sign-on, covers, and public keys. 01:27.000 --> 01:36.000 Although, there's a bit of an asterisk with public keys, because you can't really use that in the browser, like with the SSH agents. 01:36.000 --> 01:44.000 But that's where we have the cockpit's client, which is just a flat packet application, so that can just access its no problem. 01:45.000 --> 01:51.000 So, just a screenshot on how cockpit looks. There's just a basic login page. 01:51.000 --> 01:57.000 And we can see an overview on your authenticated, where you can see some security updates, the usage, and stuff like that. 01:57.000 --> 02:02.000 We can see accounts, we can see groups, we can see the networking, and that's there. 02:02.000 --> 02:09.000 There's software updates, and what's been changed, and what CVs are being fixed, and storage virtual machines. 02:09.000 --> 02:13.000 We don't have, like, containers, and stuff like that. 02:13.000 --> 02:17.000 But passwordless login. 02:17.000 --> 02:22.000 You don't have to remember password with that, which makes it so much more secure. 02:22.000 --> 02:36.000 And in most cases, you can just take it with you, other with the SSH key, if you want to do that, or using a pass key, which is, I think, a lot better. 02:36.000 --> 02:43.000 The SSH keys do count as passwordless login. It's just not what we can do with the browser. 02:43.000 --> 02:52.000 So, web authentication, fiddle two, and pass keys are way to solve all the issues, but what is it? 02:52.000 --> 02:56.000 Web authentication is, like, how you can use it in the browser. 02:56.000 --> 03:17.000 The fiddle two is, kind of, like, encompassing of pass keys, and, sorry, of web authentication, and something called CTAP2, which includes, like, discoverable keys, user replication, user presence, and paid verification features, because it's direct access to the hardware. 03:17.000 --> 03:21.000 And pass keys are just the actual way of authenticating the user. 03:21.000 --> 03:26.000 So, that's sort of the differences between us, between us all. 03:26.000 --> 03:32.000 And linking it both, that's going to be this tricky part, because of the modules, I think. 03:32.000 --> 03:44.000 Since it is the preferred way for us to authenticate, I wanted to look around at what is available, and there is something for, by you, because, called, the Pan-U2F module. 03:44.000 --> 03:54.000 And that one has great documentation, it works well with fiddle two, but it currently doesn't work with web authentication, which is a bit frustrating. 03:54.000 --> 04:06.000 But it uses a very well maintained, and great underlying library called lib fiddle two, which is also something that free IPA and SSD uses. 04:06.000 --> 04:20.000 It is also made by Ubico, so there's a lot of interconnecting code and just great tools to, like, help get the tokens you need, the authentication, assertion, and so on. 04:20.000 --> 04:35.000 And you can also use specific tools to authenticate with, instead using Pan modules, like cockpit currently supports SSD, and so using that is probably preferable if we need to go in the way of some special tools. 04:35.000 --> 04:53.000 And with free IPA and SSD, both having task is important at this point, that makes it a lot easier, especially since they use the underlying lib fiddle two library, just like Pan-U2F, which can support web authentication quite well. 04:54.000 --> 05:17.000 You can register it without direct hardware access, because when we're doing something in the browser, the actual server part where we're going to call all the commands, it won't have access to the hardware, so we need to provide it through the web browser and provide all the data we get there to the backend, and that's where the issues might come. 05:17.000 --> 05:37.000 But luckily both Pan-U2F has a manual mode, free IPNSD have a way to add keys, but actual authentication haven't looked it up yet, it's a bit unclear, but it's something we should look into for free IPNSSSD, if we can actually authenticate without having direct hardware access. 05:37.000 --> 06:06.000 So things to keep in mind when we're authenticated in this, since all of these features have a very, very strong fiddle two focus, how can we actually make use of that with web authentication, because fiddle two is very focused on terminal, we have to use the manual mode, we have to configure it in a way that doesn't cause issues, which are getting a bit more soon, because those issues are very relevant to what we are doing. 06:06.000 --> 06:28.000 We may get issues with the relying poppy, especially on console SSD and 380A, because those are using the realm, whereas you might have a different host name or a different domain that you use in cockpit on, so you might have the domainexample.com with the port 1991, and then you have the realm, which is serveridmexample.com. 06:28.000 --> 06:49.000 And if those two aren't matching in a good way, you're going to have some issues with actual authentication, the response that you're sending to Pam or SSD, and there is a thing to actually help with this, which is the well-known web-authent domain. 06:49.000 --> 07:01.000 And that's sort of just, I think it's a JSON array where you can put in all the origins that is being supported through this domain. 07:01.000 --> 07:18.000 So if you're on example.com and you want to authenticate with a different line party, such as the serveridmexample.com, then you would add the example.com within the serveridmexample.com slash well-known slash web-authent. 07:18.000 --> 07:26.000 But it can be a bit tricky, especially if the realm itself wouldn't support providing this. 07:26.000 --> 07:29.000 So, bit tricky. 07:29.000 --> 07:45.000 The best way would be for us to use it like a custom relying party, where we actually provide what we want to the variation, either dynamically or statically just for cockpit itself, just we can sort this out without getting some issues. 07:45.000 --> 07:50.000 But I think the Pamutf is going to be a lot simpler than the SSD implementation. 07:50.000 --> 08:01.000 And then we actually have to think about how do we actually get it compliant with web authentication specification or like what we need to do to make it work. 08:01.000 --> 08:11.000 So, Pamutf, since this is a Pamut module, it is preferred way to do it, because we want to use Pamutjol's to authenticate. 08:11.000 --> 08:27.000 It doesn't support the limited authorization algorithm, which is the client data JSON verification from the webauthent specification, which can be a bit of an issue, because it currently uses the client data hash as a challenge. 08:27.000 --> 08:43.000 So, it kind of collapses both the challenge and the client data into one, just made it simpler, because it doesn't really have to care about anything else, since they're not doing webauthent, they're doing field to so they can skip some step. 08:43.000 --> 08:48.000 And it also relies on CO2, which is a binary encoding format. 08:48.000 --> 09:05.000 So, making that work in the browser, currently, it doesn't work but defaults, you have to either use library or add one yourself, or we can do something on the backend, which I think, live field or two, will actually support or does actually support. 09:05.000 --> 09:09.000 So, we could use that in the backend somehow. 09:10.000 --> 09:15.000 But yeah, as I mentioned, it's always watch a webauthent workflow, so this will be fairly easy. 09:15.000 --> 09:24.000 And I know that Mika, from the Susan's cockpit team, is actually working on making this possible on Pamut 12. 09:24.000 --> 09:38.000 So, it is somewhat easy, in terms of what changes are needed, since live field or two supports it, it just needs some tests and we need to go through some edge cases and stuff like that, but it is going forward. 09:39.000 --> 09:43.000 Just like I walked through on how we would use this on the web browser. 09:43.000 --> 09:49.000 When we're creating a pesky, you typically have a challenge that's gotten from the server itself. 09:49.000 --> 09:58.000 And this challenge is how it can verify that the actual request that you're sending to server and verify that the server is the one that is expected. 09:58.000 --> 10:12.000 You provide the relying party, and this is going to be the ID, which is going to be the domain in our case, and then we're going to have a name, which we can probably hot code to cockpit, although I haven't fully checked it out. 10:12.000 --> 10:24.000 We have a user, we will provide an ID that's either randomly generated or unique, at least in some way, which else is going to be some array of binary array. 10:24.000 --> 10:34.000 I'm going to have the name of the user that we want to authenticate, and then just some display name in this case, I just took admin admin, because why not. 10:34.000 --> 10:43.000 And since Pamut 12 is very strongly attestation, they're actually authorizing everything with the public key. 10:43.000 --> 10:48.000 You need some sort of attestation to actually make sure that you cannot authenticate, otherwise this wouldn't work. 10:48.000 --> 11:01.000 So you can use direct, or you can just, I think, interact, direct includes a lot of the public key stuff that is provided through the browser, although I haven't fully checked it out yet, I'm not sure. 11:02.000 --> 11:15.000 We set the time out on 60 seconds, just have something, we add some authenticated selection, where we say, we don't want to rest in the key, but also not discoverable key, because I haven't done it yet. 11:15.000 --> 11:23.000 And we don't want user verification where the user has to touch the device and stuff, just make it simpler. 11:23.000 --> 11:46.000 And then we just provide, okay, what actual algorithm we support, and we put in the three that is supported by Pamut 12, which is the ES256, EDDSA, which you have seen from SSH logins, you're shooting, and then RS256. 11:46.000 --> 11:52.000 Then you just call, call this to the browser with the public key, we just created, we get the credential back. 11:52.000 --> 12:12.000 We decode the actual attestation object that we receive, so that we can get to public key that is expected from, or on the Pamut 12 side, because they have, like, a fiddle to kind of way of doing it, so I have to use the C-board encoding on decoding. 12:12.000 --> 12:41.000 And we're basically just getting a public key object, which is just offset in the attestation object, and then that is, includes, at least for ES256, an X and Y value, and some other stuff of, like, what it is, and then we just add it to, like, a 64 bit, a 64 bit array, just because that's what's expected from Pamut 12. 12:41.000 --> 13:06.000 We then called the raw ID to basics 4 and the raw ID is just way of identifying the key from the server, so in the server we stored raw ID, and then when we're authenticating, the server is going to send, okay, here are all the keys, again, use, and your browser will basically say, okay, we're going to look and see if you find this, this key, so if you do, then you cannot authenticate with it, quite easily. 13:06.000 --> 13:14.000 And we're sending it to server, we use the concatenated public key, which is created, we send the ID, and we send the algorithm. 13:14.000 --> 13:31.000 And then on backside with Pamut 12, we stored it in this way, which is the user, column, and then all the different pastkeys that you've created, so you have the ID, the identifier, the public key, that's going to verify the attestation. 13:31.000 --> 13:43.000 You have which algorithm is being used, which is one of the three options, at this point, at least, hopefully we can get MLD safer, like the post-contom encryption, although it's not necessarily needed. 13:43.000 --> 13:53.000 And then flags, which could be plus uf, sorry, plus up, plus uv, or plus pin application, I think. 13:53.000 --> 14:08.000 The picture of the exact naming, but one is like, you have to touch the device, the other one is you have to use the biometrics, to actually check that you have the right finger print and so on, and the other one is just to enter in the pain to unlock the device and so on. 14:08.000 --> 14:37.000 That sort of, like, how we store it and use it, and then when we communicating it's your copper shell, we can actually execute commands directly to the server using web of them, sorry, using web sockets, and that can be any command we want, essentially, that makes it possible to modify files and so on, so in this case, I've just taken something from the existing code, we have records, force regenerate all, and we just send this from the front end to the back end and it executes. 14:37.000 --> 14:46.000 So that's how we will actually modify the file, instead of like that, and it is very easy, I think. 14:46.000 --> 14:50.000 The authentication that's going to be the difficult part. 14:50.000 --> 15:06.000 So we have a default authentication flow in written in C, that is being run through cockpit session, which can provide where you can also provide, you can also provide different authentication flows in a like a config file if you want. 15:06.000 --> 15:14.000 And it will look for specific authorization headers, so currently you have like basic, you have better, you have. 15:14.000 --> 15:16.000 I don't know what else. 15:16.000 --> 15:23.000 I don't think of the other ones, but you can basically have anything you want there, you can have also reshesion table if you really want to have something special. 15:23.000 --> 15:35.000 And then there we just say, okay, which command do you want to use, and as long as it is something can execute in shell, and ideally communicate with Pam or something else that you want to use, then you can use it. 15:35.000 --> 15:41.000 So Python is fine, C is fine, so on. 15:41.000 --> 15:52.000 So the actual work I managed to get so far due to some limitations with the Pam you have module and just UX workflow stuff that I'm going to come through yet. 15:52.000 --> 15:58.000 I managed to get the use name password together with Paskey 2.5 to work. 15:58.000 --> 16:06.000 So we enter in the username password, hit login, and then we get a new screen where we have a login with Paskey button. 16:06.000 --> 16:14.000 And then get that case, we're off the button to challenge, so all we need to do now is click the button and then you can login. 16:14.000 --> 16:16.000 But it's not ideal. 16:16.000 --> 16:21.000 Ideally, you just want the one button to click and login, but we'll get to that. 16:22.000 --> 16:29.000 So with the username and password, we're going to use the authorization basic, which can be a basic for data with username password. 16:29.000 --> 16:36.000 We're going to converse with the Pam stack, and we're going to get more inputs. 16:36.000 --> 16:44.000 That is being sent to the server, being sent from the server to the browser, and then we're going to display that depending on what it is. 16:44.000 --> 16:51.000 So if you have a TOTP, like to factor authentication, TOTP token that you have to enter in, we'll show that on the browser. 16:51.000 --> 16:57.000 If you have Paskey, then we'll show the button, and so on. So it's fairly easy to modify for us. 16:57.000 --> 17:07.000 So we're going to show demo where we're going to put in the username and password, and then we're going to get a new screen where we're going to use the Paskey as 2.5. 17:08.000 --> 17:15.000 I'm using the Chromium virtual environment, the authentication environment, because it makes it easier just to not have to click a physical device. 17:15.000 --> 17:17.000 It's just almost instant. 17:17.000 --> 17:25.000 And unfortunately, we have to add it manually to it to see you have mapping, because it's not something added. 17:25.000 --> 17:28.000 So it can access that in the login. 17:28.000 --> 17:32.000 So, oh, yeah, almost there, but not really. 17:32.000 --> 17:40.000 So, here we have the virtual environment, and see what I've created. 17:40.000 --> 17:48.000 If you see TOTP 2, I created Create Paskey where we get something in the console, which is the ID, the public key, the ES2, 17:48.000 --> 17:51.000 the 6, and then the flags, which in this case is none. 17:51.000 --> 17:56.000 It is for the admin user, and we added to the mapings. 17:56.000 --> 17:58.000 Then just look at the logs. 17:58.000 --> 18:00.000 Following the logs, you see what happens. 18:00.000 --> 18:04.000 I click Login with the username and password, and then Login with Paskey. 18:04.000 --> 18:11.000 And after it selects the actual Paskey and you authenticate, then you're just login. 18:11.000 --> 18:16.000 And here you can see that you have Pam, SC authenticate with success. 18:16.000 --> 18:17.000 So everything worked. 18:17.000 --> 18:24.000 You can see all the outputs that we got, and the signature that we sent to the server. 18:24.000 --> 18:26.000 So, everything just works. 18:26.000 --> 18:29.000 So, the hard work is done. 18:29.000 --> 18:41.000 Now, it's just like the user experience that we have to improve and actually also get the PR at Pam, you have to be merged and so on. 18:41.000 --> 18:47.000 But the one thing that everyone uses is Pam, is the one click login. 18:47.000 --> 18:54.000 And that is, you're going to have a credential that's discoverable and not discoverable. 18:54.000 --> 18:58.000 The discoverable one, you don't need to input a username. 18:58.000 --> 19:01.000 And it's the preferred way to do it. 19:01.000 --> 19:05.000 If you look in GitHub or other applications, you click hit the long-length Paskey. 19:05.000 --> 19:08.000 And usually that's just, you select the Paskey. 19:08.000 --> 19:11.000 You want to authenticate with and then it just works. 19:11.000 --> 19:14.000 Unfortunately with the hardware that you use, 19:14.000 --> 19:16.000 you're only going to have a few limited slots. 19:16.000 --> 19:22.000 So, with Ubiquit 5 is 25, sookies, 50, and then with nitricade, depending on the firmware and a model. 19:22.000 --> 19:27.000 And it's going to be 35 to 100 slots, which is quite a lot. 19:27.000 --> 19:30.000 If you're not discoverable, the credential is going to store an infant mount, 19:30.000 --> 19:32.000 but then we need to provide actually username. 19:32.000 --> 19:35.000 So, how we do that is a bit of a UX challenge, 19:35.000 --> 19:38.000 because we kind of want to have the username password, 19:38.000 --> 19:41.000 but also it would be kind of weird to not provide the password. 19:41.000 --> 19:44.000 But then click the, but then provide the user field. 19:44.000 --> 19:46.000 And so, use the name. 19:46.000 --> 19:50.000 When you log in with Paskey, we're going to provide, 19:50.000 --> 19:52.000 we're going to get the challenge. 19:52.000 --> 19:55.000 We're then going to parse the data given from PEMYTF. 19:55.000 --> 19:59.000 We're going to send that to the allowed credentials, 19:59.000 --> 20:01.000 because in this case, it's a normal discoverable case. 20:01.000 --> 20:04.000 So, we have to use, we have to provide the username ourselves, 20:04.000 --> 20:08.000 and we get all the keys that works. 20:08.000 --> 20:11.000 And then we'll just send that over to the browser. 20:11.000 --> 20:15.000 We get back a lot of stuff that we just send back to PEMYTF, 20:15.000 --> 20:17.000 which in this case, we're going to plant it at JSON. 20:17.000 --> 20:24.000 We're going to be RPID, which is because they don't have the line-party currently. 20:24.000 --> 20:28.000 Since there's an client data hash, instead of JSON, we have to provide it. 20:28.000 --> 20:30.000 But that's something we might change. 20:30.000 --> 20:32.000 We'll see if we're allowed. 20:32.000 --> 20:35.000 We see, we're in code, the authentic data. 20:35.000 --> 20:41.000 We send a signature, and then the user handle, and then it should just work. 20:41.000 --> 20:44.000 Also, in this case, I don't think we need the user handle since we already have. 20:44.000 --> 20:49.000 No, yeah, we need the user handle, because this is supposed to be a discoverable key. 20:49.000 --> 20:53.000 It's a bit of a mix, I think it made something wrong there. 20:53.000 --> 20:56.000 What's left, there's a lot of stuff. 20:56.000 --> 21:01.000 We have to get the WebAscent implemented in PEMYTF. 21:01.000 --> 21:05.000 We're going to add some stuff to the cockpit, to support the pass key. 21:05.000 --> 21:08.000 We're going to add a model to the cockpit shell when you're logged in. 21:08.000 --> 21:11.000 So you can add in the lead pass key, so I deal with some sort of naming. 21:11.000 --> 21:12.000 So you can name all the pass keys. 21:12.000 --> 21:15.000 And we're going to have a new line support in cockpit payload. 21:15.000 --> 21:19.000 So that we can send one request instead of many requests when authentication. 21:19.000 --> 21:25.000 Authenticating, because PEMYTF expects multiple inputs, which is a bit unfortunate. 21:25.000 --> 21:29.000 And then we're also going to follow with SSSD and free IPA. 21:29.000 --> 21:34.000 Just we can figure that out since we're going to have SSSD implemented in cockpit. 21:34.000 --> 21:40.000 We want to get that working with pass keys, just because we're all to don't have to work. 21:40.000 --> 21:42.000 So it should be fairly easy. 21:42.000 --> 21:45.000 So we're going to go through this a bit fast and running at the time. 21:45.000 --> 21:53.000 So the general timeline, based on my guess, is that we're going to have some sort of working prototype this month. 21:53.000 --> 21:57.000 We're going to get PEMYTF PR merged, hopefully this month. 21:57.000 --> 22:01.000 Since most of that is prepared, we just need to create some tests to make sure it's okay. 22:01.000 --> 22:06.000 And we're going to clean up some basics before URL, conversion, whatever. 22:06.000 --> 22:09.000 We're going to get a functional pass key login. 22:09.000 --> 22:11.000 So you have the one click login. 22:11.000 --> 22:15.000 And then early March, I hope we have gotten the registration. 22:15.000 --> 22:18.000 And in that case, we can do a full review. 22:18.000 --> 22:20.000 But we'll see. 22:20.000 --> 22:24.000 Q3, we're hopefully going to extend that to SSSD and free IPA. 22:24.000 --> 22:26.000 But time will tell. 22:26.000 --> 22:28.000 It depends on the priorities and stuff. 22:28.000 --> 22:32.000 So thank you to the new case for me. 22:32.000 --> 22:34.000 The others are what we normally made all the icons, 22:34.000 --> 22:36.000 Meika for implementing stuff. 22:36.000 --> 22:40.000 And you can find the slides on this link and cockpit on that link. 22:40.000 --> 22:45.000 I'll also provide it in the actual first them page itself. 22:45.000 --> 22:47.000 So you can find it there. 22:47.000 --> 22:50.000 But I'll do that after we talk sometime. 22:50.000 --> 22:52.000 So thank you. 22:52.000 --> 22:57.000 Thank you. 22:57.000 --> 23:00.000 We have one minute or less. 23:00.000 --> 23:02.000 But one question. 23:02.000 --> 23:03.000 Any questions? 23:03.000 --> 23:04.000 Yeah. 23:04.000 --> 23:07.000 So we have to set out some components. 23:07.000 --> 23:08.000 I can create. 23:08.000 --> 23:11.000 But then you have to envision that they're making a lot of blood, 23:11.000 --> 23:12.000 but they can close, right? 23:12.000 --> 23:13.000 What do you want to do? 23:13.000 --> 23:14.000 I'm sure. 23:14.000 --> 23:15.000 I'm just like different. 23:15.000 --> 23:16.000 Can you take some views? 23:16.000 --> 23:17.000 Can you take some views? 23:17.000 --> 23:18.000 Can you take some views? 23:18.000 --> 23:19.000 How does that look? 23:19.000 --> 23:20.000 Can you do this? 23:20.000 --> 23:21.000 It doesn't matter. 23:21.000 --> 23:24.000 If you mean, like, authenticating with, for example, 23:24.000 --> 23:27.000 TLTP and Pasquise and so on, like, in the same stack? 23:27.000 --> 23:28.000 Yeah. 23:28.000 --> 23:29.000 How does it mean that you can take some views? 23:29.000 --> 23:32.000 Like, if it works, there's a lot of money. 23:32.000 --> 23:35.000 We might not have to be enough for it. 23:35.000 --> 23:36.000 Yeah. 23:36.000 --> 23:40.000 The question is, like, how can we, this, like, figure out if Pasquise alone 23:40.000 --> 23:42.000 will be enough to authenticate? 23:42.000 --> 23:44.000 Is that right? 23:44.000 --> 23:45.000 Sort of. 23:45.000 --> 23:47.000 It is a bit unclear for me as well. 23:47.000 --> 23:48.000 I'm not sure how we can, like, 23:48.000 --> 23:51.000 the login with Pasquise button showing, 23:51.000 --> 23:54.000 in a way that makes sense. 23:54.000 --> 23:58.000 Because, like, ideally, we can detect whether or not we have 23:58.000 --> 24:01.000 the live feed or two in PAMUTIF and able somehow. 24:01.000 --> 24:03.000 And then we'll just show that in the login page. 24:03.000 --> 24:06.000 But then we'll probably need to have some code to detect that. 24:06.000 --> 24:08.000 We actually have this in the next game. 24:08.000 --> 24:09.000 You have an installer. 24:09.000 --> 24:10.000 Yeah. 24:10.000 --> 24:12.000 But it's, it's a bit tricky for us, 24:12.000 --> 24:14.000 since we kind of have a static login. 24:14.000 --> 24:15.000 So we'll see. 24:15.000 --> 24:18.000 Like, we can add some sort of C code and stuff like that 24:18.000 --> 24:19.000 to make sure it works. 24:19.000 --> 24:21.000 But, yeah. 24:21.000 --> 24:23.000 Does that answer your question? 24:23.000 --> 24:24.000 Sort of. 24:24.000 --> 24:25.000 Yeah. 24:25.000 --> 24:26.000 Yeah. 24:26.000 --> 24:28.000 Maybe you've got more of it. 24:28.000 --> 24:29.000 Yeah. 24:29.000 --> 24:30.000 Thank you. 24:30.000 --> 24:32.000 APPLAUSE