Okay. So, hello everyone. We'll start in a minute. If the talk will have 20 minutes,
and after that, there will be space for questions. If you have questions, please write them into
the metrics room, or we will try to run around with the mic. So, thank you all for coming,
let's, I will give a word to Alexander Bokovoy, who will have the first presentation about
enabling FIDO in support for remote-lemonaged users. Yes. Thank you, Jakob. Thank you everyone
who came today in this drizzle day into a room that is not so easy to find. Let's fight
security with obscurity. Okay. The talk I'm giving here is actually, it was supposed to
be done by Ika, who drives this effort at Red Hat. And I have another talk in the afternoon
in the main tracks about passwordless Linux, where we are. This is part of it, but not
the full stuff. So, it's kind of a preview of where we are, hopefully with demos and
without demo effect. Let's go. I hope I will be able to get something working. Nice. My
laptop actually locked up. Really? Yeah, I'm trying. It doesn't want to. Okay.
We'll get there. No, no. So, the fun part is, this is old laptop. This is really old laptop.
My actual laptop got the battery puffed up. So, it literally looks like this now. It's
sort of a hat, right? Here we're working there. But it means that I cannot fly with that kind
of laptop. And this one is maybe six or seven years old. So, it's a bit surprisingly slow
for contemporary software. We are booting Fedora. Okay. So, this talk is about a very
simple thing. Basically, this is the hardware incorporation of what people call nowadays
as a pass key or web orphan, which is known as 5.2 set of specifications. And actually,
we start with a small demo, right? If I get the screen working. Okay. I'm not getting.
I don't know what you see there. Maybe you are not seeing anything. But I actually was
able to log in with this token. And what I will be talking about is how I actually get
it. Now, let's see. Yeah. Yeah. This is because I logged in without password. The password
storage manager asks me to enter the password to unlock the storage manager. Not to log
in with the password. That's another part of the stuff that we have to fix before we
will be able to get into the Linux without all the passwords. Okay. Let me get to the
top. It's really slow. I really hope to get this working.
Yay. Finally. So, some time ago, we at Red Hat were working on the identity management
on security, on the stuff like free AP and SSSD. We started looking into a couple things.
One of them is how we can get password less into our systems. Mostly, we talk about remote
servers because that's what most of our customers are using. And many of those customers started
asking about the thing that sort of required them to be enforced for them from the governments
and so on. So, one of those things that is forced it is FIDO2 or web often because, well,
everybody else supports it. Where everybody else means all these web applications, all
the other operating systems like Microsoft Windows and the others. And, of course, there
are properties that are related to this. They are all nice. But the reality is that you
get all of this nicely working mostly in browsers, at least on Linux. And not in all browsers.
Some browsers do not support web often. Workflow some do. But we need to get these logins
into the actual systems. Because if you are not able to log into these systems, you cannot
use this password less. And, of course, there are, from the technical point of view, it's
a combination of some PAM modules and some changes to applications and so on. It shouldn't
be that hard, right? There are already PAM modules that implement this. The problem is
that if you look at this from systematic point of view, if you manage thousands of hosts
where you need to get access with the credentials stored somewhere, you need better than just
everything defined on the single machine. So, we started looking into what we have. We have
centralized identity management. We have free IPA. We have SSSD on the client side that
allows to query these different identity management, including free IPA and so on. So, we started
looking what we can create all of this. And we wanted to enable use of FIDL 2 in the console
for these remote-managed users. We start with local authentication. This is what is working
now. It didn't work like a couple of weeks ago. We are already having some progress. And
the second part will be remote authentication, but with at least, because all the things
like remote authentication using native SSH, for example, protocol, it's really not about
this. It's not compatible with the local use of the FIDL 2. It encapsulates some of the
principles, but it converts kind of use or assertion of the FIDL 2 into a different form
specific to SSH and cannot be reused for anything else. So, the reality is that's coming from
where all these governmental admins or big organizations admins are getting the pressure
from. This pressure came actually a year ago in the form of what they call zero-trust memorandum.
The zero-trust memorandum is effectively an answer by the executive office of the president
of the United States to the set of threats that they got over the last decade, or visualizer,
at least in public. So, this memorandum basically states by the end of fiscal year 2024 a number
of things should happen in the governmental organizations. There are, I think, five big
targets that they have to go, and one of these targets is to switch to password less everywhere.
And to say the truth, governmental organizations in the U.S. already use a password less form
with smart cards. But web often is called out as one of the recommended ways of doing
it in the memorandum. So, zero-trust memorandum says that basically you have to use a personal
identity verification or smart cards. We already support that. And web often is another approach.
And go there. There you go. You see the customers or prospective customers getting pressure from
there, those who drive them, who give the budgets and so on. And then these customers
come to Red Hat and all other companies and ask to get this working, because they have
to comply. Not us comply with this, but the customers comply with this. The lucky part
we have is that all of this, actually in the interest also of the community, because, well,
it simply improves our state, not only at work, but also at home. If we switch to password
less everywhere, we get a bit secure environment, I hope, given the practices that we preach
to at home. But this is the part. So, if you have remotely-managed users, basically define
somewhere, centralize it, your accounts, your post-exidentity, your home directory, your
shell, and so on, somewhere should be defined which password less credentials you can use.
These credentials should be delivered locally. And if you have a device like this one, or
maybe the one on the phone, which we do not support yet, it needs to be verified. It needs
to be an engaged way of applying and so on. And in these centralized environments, we
often have to deal with the fact that you are not only logging into the single machine,
you are jumping somewhere. You are interoperating with other applications. Typically, this transfer
of authentication state happens through transition from your local authentication to something
like Kerberos, which issues a ticket recording your authenticated state, and then uses this
ticket to issue other tickets to other services in the environment that's being built.
So on the high level, in principle, all the stuff that we deal with in free APNSS is already.
For FIDAR 2, this is the new thing for us, but we use LibFIDAR 2 library that's already
existing and shipped in many distributions for the implementation of the FIDAR 2 stuff.
We store the data at the LDAP server and fetch there that's SSSDXL set. And the other part
is we integrate with free APNSS Kerberos implementation to provide the transition from FIDAR 2 to Kerberos.
So for the local authentication, what happens is that you have the SSSD running on the machine.
It picks up the user information from LDAP record for that user. Part of that record
is the specification of the PASCII recorded details, pretty much like in the traditional
way you store them somewhere on the disk, but here you store them remotely. Then when
the token is added and there's a need to log in over a PAM, any PAM service, you get LibFIDAR
2 communicating with the device and performing its magic comparing with the record that you
have. So in LDAP, this looks like this. I intentionally included a bunch of stuff here,
but literally all we care about is that we have this PASCII attribute. And obviously
in LDAP, it's a structured store, so you have to have an object class that defines the use
of this attribute. And on IPA level, this looks like this. There is a user information which
also has this PASCII mapping. This is not in the released version of IPA yet. Hopefully by,
I hope, by spring we will get this, but later I will show you where you can get the test version.
So in IPA case only, you get after this login, which is currently not working, so you get a
Kerberos ticket. This is high-level overview of how it goes in. The presentation is available on
the site, so I'm not focusing on describing these details, but effectively we extended MIT
Kerberos implementation to allow us to communicate with the KDC. All these details related to
web often implementation. So behind KDC on IPA, on free IPA server, we have relay and party
implementation that performs part of this authentication and then uses Kerberos protocol
to transfer the bits between the two sites. So tested. So this is actually a demo of what I kind
of ran before I got my presentation working. So this is the locked-in screen this morning. And to
unlock, I have to insert this PASCII and press enter. You don't see the part of the full message
because it's so large compared to the actual input stream that GDM shows. Then I just activate the
device and magic happens. I logged in. How you can play with this yourself if you want to set up?
Iker wrote some instructions in this black post and he maintains copper wrapper for Fedora. Fedora
36 and 37 at this point. So you can get SSSD packages. There is one package that is not
installed by default. This is exactly your support for FIDO2, SSSD dash PASCII. Then you need to
enable it in the SSSD configuration. But if you follow Iker's instructions, you should get it
working. Right now it only works with free IPA because we have free IPA from that copper wrapper
because it has the support for storing the PASCII in the old app server. I will stop here
because I have like three minutes and I would like to hear any questions and feedback. This is
sort of early stage. I will show a bit more in the afternoon with the bigger presentation that they
have at the main track. There will be a bit more demos there. But we really would love to hear
your feedback and what you want to see working there. I have a question. So what happens if the
key is lost or stopped working or something like that? So what happens if the key is lost or stops
working because it's a hardware that might blow up, right? That totally depends on how the system
is defined. If the system is defined to allow fallback to other PASCIIs or it's allowed to use
a different authentication method, the fall-through to those methods will happen. If you want to,
if the key is lost, for example, user or admin can remove from, let me get here, from the user
entry, you can remove the PASCII mapping and then this user wouldn't be able to use this PASCII
anymore. So in practice, this is a process thing. You have to define your policies for organizational
policies, how you handle any lost credentials. There's no difference with this. Some systems
like, for example, Apple in MacOS actually forces you to define two separate PASCIIs,
two separate tokens, if you enable one because they think that you most likely will lose one.
They probably figured out something about the users. Okay. Any other question?
There's nothing to pass here. So the whole, I'm not going into details of web often implementation
itself. It's fairly secure in this context. Yeah. You have to have actual hardware or
software implementation of the token. You have to have exactly the same key. The private part
of the key is typically not leaving the device. So it's fairly secure in that case.
Hi. Stefan here. Is it possible to add yet another factor? Can you please speak up louder?
Sorry. Can you add another factor to this key that you will bring? I'm sorry. I'm not here.
Guys, could you please silence a bit? Sorry. I will speak out loud. Can you add another
authentication factor to the process, like the OTP token next to this physical key?
So you're asking if there's a possibility to amend use of pass keys with something else?
Exactly. I believe it's possible to, because all of this available over PAM interface,
you can stack up several PAM modules in it. In SSSD, that wouldn't be possible at this
moment to get it. But maybe this would be a good idea for going forward to allow extending
and forcing to use several methods. Yeah. I will write this down. Okay. I guess I'm out of time.
I think we can still have one last question if there is some. Okay.
Nice, nice. Technology. I have a question about user nameless login. Is it also supported?
Because this is the problem of FIDA 2 that you can have discoverable credentials stored on the
token. So the only thing you do is plug in the token and use a fingerprint. Does it also support
user nameless and passwordless login? So the question is whether login where a system,
when you insert the token, identifies to which user this token belongs to. Does it work or not?
Implementation as right now does not support it. There is a plan to support discoverable
credentials. There are a few things that I would like to address in a presentation in the afternoon
related to UX. Basically, right now, we are very limited in how graphical environments allow
to do this discoverability. So for example, for the smart cards, a couple years ago,
we changed the GNOME GDM to extend to allow picking up different identities from the smart
card. And if user has, for example, several identities associated with the same smart card,
then GDM allows to pick up the right one. The same problem comes with the past keys. Maybe I meant
it with the idea of discoverable ones, but it's the same story. So it's more like not the back end,
but rather the front end, the one that presents you. And user experience is pretty bad right now
on this. But the plan is to fix it eventually. Okay. Thank you, Alexander, for the talk. Thank you
for all the questions. Thank you.