[00:00.000 --> 00:13.360]  Welcome, everyone. It's probably the first time in the last three years I actually see
[00:13.360 --> 00:22.800]  this big auditorium full of people willing to hear something I'm going to rumble about.
[00:22.800 --> 00:32.360]  I actually wrote a bit of a script for this, but I'm bad at memorizing those scripts, so
[00:32.360 --> 00:44.760]  it will be remembering as I go, rather than seating something that I wrote about. So for
[00:44.760 --> 00:53.280]  the past maybe 10 years, a team I'm a member of, we are working on a bunch of stuff related to
[00:53.280 --> 01:03.640]  something that many people think is uninspiring, because it's all about the enterprise use of
[01:03.640 --> 01:11.600]  Linux, which is just a done deal, right? Every enterprise uses Linux nowadays. And we kind of
[01:11.600 --> 01:22.080]  look into some of the areas and choose what to work on, because there's always stuff unfinished
[01:22.080 --> 01:33.680]  and needed to be working on. And suddenly there's, obviously, 10, 15 years ago, some companies from
[01:33.680 --> 01:41.000]  the West Coast, they started to look into, hey, this shiny thing called the Internet and this shiny
[01:41.000 --> 01:51.960]  way of having your account somewhere in the social network drive your login into your machine and so
[01:51.960 --> 01:59.240]  on. And here we are, 10, 15 years after talking about doing similar thing for Linux in enterprise
[01:59.240 --> 02:08.040]  environment than at home. So I will start with a bit of introduction. I'm working at Red Hat for
[02:08.040 --> 02:19.520]  almost 12 years now. I'm focusing on the identity management. So basically, really running accounts
[02:19.520 --> 02:31.040]  in the Linux systems. Centralized identity management is what we do. Mostly working on these
[02:31.040 --> 02:42.760]  days pre-IPA. And I started with Samba 20 years ago, SSSD on the client side, MIT Kerberos for
[02:42.760 --> 02:49.480]  the authentication and so on. So there's a lot of things blended together and it's really not a
[02:49.480 --> 02:57.560]  single person or a single project. It's amalgamation of a lot of activities of a lot of people around
[02:57.560 --> 03:09.800]  the world. This talk is a kind of a split between past contemporary things and what we see in
[03:09.800 --> 03:21.680]  future or what we see now will be in future. Hopefully in February 39, if we get this through in
[03:21.680 --> 03:29.800]  upstreams first and then manage to collect this all together in the distributions, which will be a
[03:29.800 --> 03:41.160]  point to talk about a bit later. But in the past, we've been always getting all this stuff kind of
[03:41.160 --> 03:50.320]  with a bunch of assumptions. So one of the really unspoken assumptions is that when you login into
[03:50.320 --> 04:00.440]  your system, the Linux system or Windows system or so on, you don't only want to use that particular
[04:00.440 --> 04:07.160]  system. Typically, you want to go beyond that system. You want to go, well, in these days, you go
[04:07.160 --> 04:15.040]  onto web typically and use all these web applications, right? But before that, in office
[04:15.040 --> 04:23.640]  environment, you were reaching for your nice non-working printer or you were reaching for
[04:23.640 --> 04:37.600]  something to fetch files from or get your home drive and all the other stuff or play games
[04:37.600 --> 04:43.440]  together with your colleagues on the local network and so on. And in many of those cases,
[04:43.440 --> 04:54.040]  you needed to get through the authentication information that you provided or got at the
[04:54.040 --> 05:01.760]  login time. So you needed to get this state of authentication translated or correlated into the
[05:01.760 --> 05:11.400]  network onto the network services. And a typical approach that we see these days is that you
[05:11.400 --> 05:21.800]  unlock your, let's say, non-session. Then there is a secrets manager, which gets your secrets
[05:21.800 --> 05:30.120]  stored, unlocked using the password that you provided as a part of login. Then the passwords
[05:30.120 --> 05:38.720]  from this secret store used transparently by the other applications through some common APIs,
[05:38.720 --> 05:45.720]  like browsers have their own stuff. Of course, they have their own password managers and
[05:45.720 --> 05:52.320]  those might be even shareable across multiple devices and so on. But it still doesn't solve
[05:52.320 --> 06:00.720]  the real problem, which is when you log in into the system and you go to a specific network
[06:00.720 --> 06:08.800]  face and applications, you need to do this transition or transfer the authentication state
[06:08.800 --> 06:18.720]  between maybe incompatible or not well connected protocols. It is bridging that we don't really
[06:18.720 --> 06:26.960]  have in place and in many applications we kind of derive it based on certain things.
[06:26.960 --> 06:34.920]  Okay. In reality, it's much easier in the enterprise world because for almost 40 years
[06:34.920 --> 06:43.440]  we've been dealing with something that is called Kerber's in different ways of it, which
[06:43.440 --> 06:53.400]  is effectively a decoupling of the initial authentication and then requesting some authentication
[06:53.400 --> 07:01.240]  tokens on behalf of you after you get this initial authentication done. That's a nice
[07:01.240 --> 07:10.640]  thing. Over years Kerber's as a mechanism grown these authentication or how it's called
[07:10.640 --> 07:18.280]  awkwardly in the Kerber's world pre-authentication mechanisms that allow you to use something
[07:18.280 --> 07:28.840]  more than just passwords. So you can use, for example, smart cards or you can use one-time
[07:28.840 --> 07:40.160]  codes, two-factor authentication mechanisms and so on to log in or provide initial credentials
[07:40.160 --> 07:47.920]  to obtain the so-called ticket granting ticket in the Kerber's thing. The good part of it
[07:47.920 --> 07:55.480]  is that this is exactly a way to get the transferable authentication state. Over years we added
[07:55.480 --> 08:03.960]  to Kerber's ability to record how this initial state was acquired. So an application can
[08:03.960 --> 08:15.480]  use an API to inquire whether this initial token was obtained with a password or with
[08:15.480 --> 08:25.520]  a smart card or with some other more strong type of authentication. So it can differentiate
[08:25.520 --> 08:32.560]  how to behave if, for example, application-specific policies says that you cannot use this application
[08:32.560 --> 08:41.840]  if you were not using smart cards or you were not using FIDO2 tokens and so on. Then application
[08:41.840 --> 08:47.320]  can inquire this information and say, yeah, you're not allowed to use this. You cannot
[08:47.320 --> 08:55.880]  use sudo on these machines because you're merely used your password, that kind of thing.
[08:55.880 --> 09:06.600]  And this is the thing that I was doing a lot and the one thing connected with this is that
[09:06.600 --> 09:16.680]  the complexity of a typical Kerber's environment is huge. But separating the authentication
[09:16.680 --> 09:23.280]  method is a nice part because it allows to decouple the other part of complexity. All
[09:23.280 --> 09:31.000]  these tokens or separate devices that you can use to prove who you are and that you've
[09:31.000 --> 09:37.520]  processed these credentials from the actual applications. It's really splitting up in
[09:37.520 --> 09:42.600]  these two parts is what is important here because we can write applications once and
[09:42.600 --> 09:50.400]  forever, at least the verification of the authentication authorization there, and deal
[09:50.400 --> 10:00.520]  with the rest separately. Now this is, for example, how it looks like in a typical Kerber's
[10:00.520 --> 10:09.160]  environment with free AP or with Samba AD or Microsoft's Active Directory. This is detailed
[10:09.160 --> 10:18.160]  in the description from the Red Hat's Enterprise Linux Identity Management Guide. Links are
[10:18.160 --> 10:29.160]  in the PDF, not just as an example of what we're dealing with. And the fun part is that
[10:29.160 --> 10:37.600]  many seven years ago I've been talking in the other room in Janssen about similar things,
[10:37.600 --> 10:45.280]  so how we started with this, how we started with the Enterprise Graphical Workstations
[10:45.280 --> 10:57.960]  on Linux. That was, how many, 15 Fedora releases in past, 15. When I wrote that, I did not
[10:57.960 --> 11:07.120]  realize that we are 37 now and it's like seven and a half years back. And almost all this
[11:07.120 --> 11:13.600]  stuff already worked by that time. The smart cards were possible to use in this environment.
[11:13.600 --> 11:19.880]  Of course there were some issues with the visual representation, how you choose these
[11:19.880 --> 11:26.840]  smart cards and so on, but it's kind of funny that what I will be showing to you today is
[11:26.840 --> 11:31.360]  kind of similar to what we did seven years ago. We fixed this problem for smart cards
[11:31.360 --> 11:41.440]  eventually, together with the GNOME people. By introducing some interfaces between SSSD
[11:41.440 --> 11:53.640]  and GNOME components, GDM and the other parts of the Window Manager, so that they can pick
[11:53.640 --> 12:00.720]  up this information and show a nicer UI to choose who you are based on your smart card
[12:00.720 --> 12:09.720]  and so on. But smart cards were the first thing we did with this passwordless authentication
[12:09.720 --> 12:17.600]  because you don't need passwords anymore on this system. So what happened in these seven
[12:17.600 --> 12:22.240]  years, and that's a nice period because every seven years something happens with people,
[12:22.240 --> 12:29.080]  they change themselves and environment around them changes a lot. So what happened? Actually
[12:29.080 --> 12:39.400]  there was change of winds and that's a fundamental one. If you remember 2015 to 2016, a typical
[12:39.400 --> 12:45.120]  office environment, first there were offices where people were working every day going
[12:45.120 --> 12:51.360]  into those offices and they had a network actually where those computers were connected
[12:51.360 --> 13:00.880]  and enrolled into the whatever domain controllers were in those offices. It really was an environment
[13:00.880 --> 13:12.320]  that was for the infrastructure for people, right? That you come, you switch in, your laptop
[13:12.320 --> 13:20.280]  connected and it knows what to do. It was so to say infrastructure for people. Nowadays
[13:20.280 --> 13:27.480]  there's all infrastructure in cloud and it's not for people, it's for applications. You
[13:27.480 --> 13:33.080]  deploy applications somewhere in the cloud and all that infrastructure that is there
[13:33.080 --> 13:43.680]  is not for you as an employee, you as someone who consumes it. You don't consume that infrastructure
[13:43.680 --> 13:53.280]  anymore. In most cases, of course there are exceptions. In most cases you are consuming
[13:53.280 --> 13:59.320]  the applications and applications consume that infrastructure. So if your laptop is
[13:59.320 --> 14:05.600]  enrolled in something, that's most likely not the same environment as your applications
[14:05.600 --> 14:14.600]  enrolled. The applications are actually consuming what? They consuming stuff like OAuth. They
[14:14.600 --> 14:22.760]  get tokens, they get authorised to get tokens on your behalf from the identity provider
[14:22.760 --> 14:30.240]  service that is some WAG stuff that you don't really know how is built inside in most cases
[14:30.240 --> 14:35.440]  and you don't care. All you care about is that you can prove to this identity provider
[14:35.440 --> 14:44.880]  your identity and for that you can use a bunch of stuff. For most of the cases on the social
[14:44.880 --> 14:53.960]  networks or on a myriad of websites and so on, you don't even prove for them that you
[14:53.960 --> 14:59.960]  possess certain credentials. You prove this for some identity provider that they connected
[14:59.960 --> 15:09.360]  to and that something that I call bring your own authentication. So you connect your account
[15:09.360 --> 15:16.680]  in something to your social network account and you prove to the social network that you
[15:16.680 --> 15:23.600]  are who you are and then that social network IDP issues talking to that site where you
[15:23.600 --> 15:29.640]  want to be. That's essential, bring your own authentication to that site. The site doesn't
[15:29.640 --> 15:37.240]  really care how you authenticate it to the social network, how you prove yourself. And
[15:37.240 --> 15:47.560]  in fact what becomes out of it is all infrastructure around OAuth and all IDC is a part of it is
[15:47.560 --> 15:54.400]  built around I have a browser and this browser is everything I need. There are radio acts
[15:54.400 --> 16:00.040]  between different components and websites. They talk to each other on your behalf. So
[16:00.040 --> 16:08.920]  this is kind of a new mainframe where everything runs. So you still need a network access for
[16:08.920 --> 16:16.960]  this to work. And here we get back to the 2016. In 2016 one of the biggest issues we
[16:16.960 --> 16:27.240]  were identified at that point for enterprise workers was everyone goes into business trip,
[16:27.240 --> 16:33.360]  goes into the hotel and every single hotel has captive portal on their Wi-Fi. So in order
[16:33.360 --> 16:40.240]  to log in into your machine using your credentials you have to solve a problem of solving captive
[16:40.240 --> 16:45.400]  portal before you log in into the machine. The fun part is that we never solved this
[16:45.400 --> 16:53.400]  problem at all. Instead of solving this problem we basically say to ourselves let's remove
[16:53.400 --> 17:00.440]  our machines from the corporate environment, right? Decouple machine from the environment
[17:00.440 --> 17:06.520]  rather than solving the problem. Maybe this is a good solution. Maybe not. Because right
[17:06.520 --> 17:13.760]  now to solve, to get this authentication again working for us we need to run browser before
[17:13.760 --> 17:24.080]  we log in again. And running browser before you log in in titles running insecure unknown
[17:24.080 --> 17:32.840]  executable which is JavaScript code with the access to your hardware which is your at least
[17:32.840 --> 17:39.600]  screen and GPU and so on because that's what the browsers are requiring to do this stuff.
[17:39.600 --> 17:49.520]  So that's still the problem to solve and of course some of these problems might be solved
[17:49.520 --> 17:57.760]  but some of these problems might be, hey, move the way. So almost everyone has a phone.
[17:57.760 --> 18:05.840]  So this is somewhere I can run a browser instead of my laptop. So maybe I can run the authentication
[18:05.840 --> 18:14.160]  and authorization process on this separate device instead of running it on my laptop
[18:14.160 --> 18:20.880]  when I try to log in. It's kind of getting around the problem but maybe all the problems
[18:20.880 --> 18:25.680]  are like that. Get around them, roughen them, solve them directly. And in some cases this
[18:25.680 --> 18:32.000]  is not even a problem. For example, if you want to log in over SSH and you're already
[18:32.000 --> 18:38.960]  logged into your workstation then launching a browser on your already logged in workstation
[18:38.960 --> 18:51.080]  is easy, right? You just need to have a URL to get into. So let's try, I hope I will show
[18:51.080 --> 19:06.640]  this. Let's try a demo. So here I'm trying to SSH into some machine and on the left side
[19:06.640 --> 19:15.320]  from you, I have an IDP based on the key clock, open source project. And this user, it doesn't
[19:15.320 --> 19:21.560]  have the security key associated with it. Now I'm associating. So basically I'm taking
[19:21.560 --> 19:31.200]  this kind of token and connecting it with this user. Okay? I have this token associated
[19:31.200 --> 19:38.480]  somewhere there. And now I can log out of my IDP just to make sure that I don't reuse
[19:38.480 --> 19:44.320]  the same session that I obtained with the password, right? So now I'm trying to SSH
[19:44.320 --> 19:52.920]  and I'm presented with a message that says, okay, authenticate against this browser somewhere.
[19:52.920 --> 19:59.000]  So I have a browser. It's handy. I'm getting, I'm using the security key to actually authenticate
[19:59.000 --> 20:08.240]  instead of the password. I authenticate it into the system. Now the system says, do you
[20:08.240 --> 20:14.240]  authorize this access? Yes, I authorize this access and load it into the system. But a part
[20:14.240 --> 20:21.800]  of this authorization is that I'm getting Kerberos ticket. Kerberos ticket issued to
[20:21.800 --> 20:29.400]  me by my infrastructure. And now this Kerberos ticket can be used for, well, anything. Anything
[20:29.400 --> 20:34.960]  that's allowed there within this Kerberos environment. So I can SSH with this Kerberos
[20:34.960 --> 20:46.480]  ticket further. I can mount NFS or Sambo, something shares, get access to files. I can use this
[20:46.480 --> 21:00.000]  Kerberos ticket to sudo into the system itself. There is, since last year, or actually 2001,
[21:00.000 --> 21:07.840]  there is a POM module as a part of SSSD, POM, SSS, GSS. This module actually checks that
[21:07.840 --> 21:15.800]  you have active Kerberos ticket and its properties are good enough to access POM services. So
[21:15.800 --> 21:23.640]  you can configure, for example, sudo to say that if you have Kerberos, active Kerberos
[21:23.640 --> 21:32.160]  ticket, obtained with this IDP authentication or smart card, then you can use sudo rules
[21:32.160 --> 21:38.160]  on this machine. Which rules is separate from this, but you can get access to sudo with
[21:38.160 --> 21:46.160]  it. You don't have password. You never had password in your system. And the password
[21:46.160 --> 21:54.200]  may be existed somewhere in the IDP, in this key clog thing, or in GitHub, or GitLab, or
[21:54.200 --> 22:04.520]  Google for your company, or Azure for your company, or your own key clog stuff. But the
[22:04.520 --> 22:14.640]  rest will work the same, regardless of how you get there. So it's a bit complex in terms
[22:14.640 --> 22:24.280]  of how this is implemented and how it goes. But at the core of it is we split the process
[22:24.280 --> 22:31.240]  in two parts. There's initiating part, which in this case is the running on the server
[22:31.240 --> 22:41.040]  I tried to log in. There is a part that actually verifies that your IDP authorized access,
[22:41.040 --> 22:48.920]  which is running on the Kerberos key distribution center part, so Kerberos server side. And
[22:48.920 --> 22:56.400]  then there is a client, which is in our case SSH, trying to connect to the SSH server,
[22:56.400 --> 23:04.080]  which initiates process. And of course, there is a browser that you run somewhere. You sold
[23:04.080 --> 23:11.760]  that URI there, probably to use a phone to access that URI. You probably want to have
[23:11.760 --> 23:20.360]  a QR code instead of the URI, or in addition to the URI. This is one easy thing that we
[23:20.360 --> 23:28.080]  need to implement to make it easier. But also, it will become probably a mandatory part if
[23:28.080 --> 23:34.800]  you want to integrate this with the graphical login into the system, because you cannot
[23:34.800 --> 23:41.520]  run browser yet. But sure, you can show the nice picture that you can access from your
[23:41.520 --> 23:51.440]  phone or other device. And you will need something like that for the past keys existing only
[23:51.440 --> 24:00.080]  on your phone, the soft FIDA 2 tokens that both Apple and Google are eager to push to
[24:00.080 --> 24:10.280]  us these days. So effectively, the same thing works with the FIDA 2. In fact, the demo that
[24:10.280 --> 24:17.640]  I showed was FIDA 2 token, because the IDP side was configured to use FIDA 2 or Web
[24:17.640 --> 24:28.640]  Wolf token instead of password or smart card or OTP, whatever is there. So we already can
[24:28.640 --> 24:36.360]  do this. It's already, in fact, all the tests that I ran, it's Fedora 37, the one that's
[24:36.360 --> 24:43.680]  already released last November last year. So this passwordless login to the Linux console
[24:43.680 --> 24:56.160]  works on Fedora, works on RHEL 8.7.9.1, and a client side of it works on Ubuntu 22.10,
[24:56.160 --> 25:05.520]  because they have this new SSSD version that supports this stuff. Okay. So if I want to
[25:05.520 --> 25:22.800]  do this with the other services, let's hope I can get another demo. How I can switch to
[25:22.800 --> 25:40.280]  the next one, huh? Use it just a second.
[25:40.280 --> 26:06.640]  Okay. So this is basically exactly the same demo, just using, instead of SSH, I'm using
[26:06.640 --> 26:13.840]  VLOG. VLOG is just a normal application that uses PAM, Plugable Authentication Mechanism
[26:13.840 --> 26:22.400]  Module, to lock your system. So typically what happens is that you lock your console,
[26:22.400 --> 26:27.880]  and then you have to provide a password. VLOG doesn't know anything about all this stuff,
[26:27.880 --> 26:35.320]  but it works because we use the standard APIs there. And in this case, I don't need to provision
[26:35.320 --> 26:45.640]  the token, obviously, because it's already provisioned, but I can use it to log in into
[26:45.640 --> 26:57.720]  the VLOG application. This goes just transparently, maybe awkwardly because of the URLs and not
[26:57.720 --> 27:05.160]  nice UIs and so on, but still it's there. The most important part here is that in order
[27:05.160 --> 27:11.400]  to all this get work, and we have to have a network and service, this IDP thingy, how
[27:11.400 --> 27:19.400]  we can get without it. Well, FIDAR2 has this ability to work locally and not really through
[27:19.400 --> 27:30.480]  the web stuff. So we can run this authentication locally. And all these tokens that Ubico and
[27:30.480 --> 27:38.600]  all of this is token EU or some others, they usable in the isolated environment as well.
[27:38.600 --> 27:53.400]  So we can actually run it. So I got one small demo with this to, let's hope I get this started.
[27:53.400 --> 27:59.840]  This is recorded with my phone camera because I needed to actually show you that I pressed
[27:59.840 --> 28:06.440]  something on the screen. So this screen is locked, right? And now I'm trying to log in
[28:06.440 --> 28:13.680]  into that screen. And it asks me to insert this passkey device. So I'm inserting it in
[28:13.680 --> 28:22.440]  and you can see that it doesn't actually show you the full message that is shown there.
[28:22.440 --> 28:29.760]  The part of the message says and press enter before it goes further. So when I press enter,
[28:29.760 --> 28:36.480]  it tries to communicate with the device. It blinks to me and then I have to press a test
[28:36.480 --> 28:42.440]  that I physically present at the device to log in it. And after that, I'm unlocking
[28:42.440 --> 28:50.760]  the same way as with VLog or SSH through the palm. I'm unlocking this. This was my presentation
[28:50.760 --> 29:03.880]  this morning at the security dev room about the same thing. Now, if we go logically further,
[29:03.880 --> 29:08.200]  this is working actually by the way. I cannot show it on this laptop because as soon as
[29:08.200 --> 29:18.040]  I lock my screen to unlock, the video stream through HDMI will get disconnected and we
[29:18.040 --> 29:23.720]  will have to wait another five minutes to get my screen working back. So you wouldn't
[29:23.720 --> 29:33.440]  see this on the screen. So believe my camera. Now, how we can combine this? Logging in locally
[29:33.440 --> 29:40.240]  with the FIDO2 token is effectively, it gives me a login into the system. But the very first
[29:40.240 --> 29:48.200]  thing, the same problem that I discussed in the beginning applies here. How I transfer
[29:48.200 --> 29:56.760]  this authentication state that I used this passwordless device to log in to other applications?
[29:56.760 --> 30:03.680]  Well, in enterprise environment, whatever we call enterprise environment, for me for
[30:03.680 --> 30:09.720]  the last 10 years or so, enterprise environment is my home environment because I run what
[30:09.720 --> 30:22.080]  I develop, free IPA in my, as my home authentication service. I simply need to transition from
[30:22.080 --> 30:30.800]  this FIDO2 token authentication to Kerber's ticket using it, right? Sounds simple. Yes,
[30:30.800 --> 30:39.640]  it's also a bit of arrows and lines and so on, but it's pretty much in line with this
[30:39.640 --> 30:46.560]  one. It's just the question of who is communicating with whom to prove that the possession of
[30:46.560 --> 30:56.640]  credentials is the real one. Okay. Unlike the previous one, I cannot show a demo of
[30:56.640 --> 31:04.800]  this one because we are at the point where maybe in two weeks we will complete this implementation.
[31:04.800 --> 31:13.800]  And of course, the amount of bugs to find and fix will get this probably delayed until
[31:13.800 --> 31:21.680]  Fedora 39 or so. But I really hope to get this working by that time, which is by the
[31:21.680 --> 31:35.400]  way just how many? Seven, nine, nine months away. Sounds a nice number. So that's not
[31:35.400 --> 31:44.920]  everything, of course, because, well, it's only an infrastructural part of it. To get
[31:44.920 --> 31:51.040]  it usable and not to the point that users will trash their laptops because they cannot
[31:51.040 --> 32:01.720]  read the message. Imagine this is just a simple insert your passkey device. What if this was
[32:01.720 --> 32:11.960]  authenticate against these URL, HTTPS, something that can't even fit into this box? That's
[32:11.960 --> 32:19.440]  the situation right now. So we need to fix this with, in this case, it's a GDM, of course,
[32:19.440 --> 32:27.240]  this is the GNOME display manager. For the login, we need to fix this. And we started
[32:27.240 --> 32:33.480]  talking with the GDM developers, and there is some common understanding of what to do
[32:33.480 --> 32:40.680]  similar to what we did with the smart cards. The nice part of it is that it's mostly about
[32:40.680 --> 32:46.680]  a protocol of communicating between the PAM service, in this case, SSD, and the display
[32:46.680 --> 32:55.560]  manager through the environmental variables within the process. So SSD can tell that I'm
[32:55.560 --> 33:05.000]  now using this type of passwordless authentication. Please switch to this visualization of it.
[33:05.000 --> 33:11.000]  So we kind of can make it this way that it works for GNOME, but it's also usable for
[33:11.000 --> 33:20.560]  others. And here I come to the point of effort across multiple projects. So you can do this
[33:20.560 --> 33:30.840]  with GNOME, but then what to do with GDE, what to do with XA, XFAC, and others. There's
[33:30.840 --> 33:38.880]  a need to agree on something. We can agree on APIs, we can agree on protocol driving semantics
[33:38.880 --> 33:46.120]  behind this, but somebody needs to implement all these pieces in the end. This is a common
[33:46.120 --> 33:56.040]  effort as a community. It's not just one company or one developer crazy enough can drive and
[33:56.040 --> 34:04.880]  write all this code and get it. We as a community need to work together to get this done. And
[34:04.880 --> 34:14.400]  of course, this is just a top of the iceberg. This bunch of work needs to be done on the
[34:14.400 --> 34:23.280]  distribution level to make it usable for cleaning installations, for example. If I want to
[34:23.280 --> 34:31.680]  use this type of the key, if I go to keys, for example, for the login into machine, I'm
[34:31.680 --> 34:38.760]  sure probably want to use it also to provision encryption of my disk. And this is already
[34:38.760 --> 34:51.200]  possible with system D supporting configuration of lock devices with the FIDO2. In all contemporary
[34:51.200 --> 34:59.400]  distributions, system D already compiled with support for FIDO2. It's a matter of configuring
[34:59.400 --> 35:06.880]  them, right? It's the matter of configuring other services to reuse all of this. But I
[35:06.880 --> 35:16.360]  don't think as much as I like wiki pages that describe how to do this in multiple articles,
[35:16.360 --> 35:24.600]  I don't think this is what we should be doing. It's the distribution level job to polish
[35:24.600 --> 35:32.320]  or add this kind of polish. Again, as a community of distribution developers, in Fedora, in
[35:32.320 --> 35:41.920]  Debian, in others, in Arc, we need to focus on this kind of polishing. When all these
[35:41.920 --> 35:49.000]  pieces ready, sure, someone will be faster with the releases and polishing of it. But
[35:49.000 --> 35:56.440]  in the end, we as a community, we as community of developers, users, we are users themselves,
[35:56.440 --> 36:06.080]  even if we are, we know how this stuff works. It doesn't mean that we tolerate how badly
[36:06.080 --> 36:14.040]  it's integrated. So that's my message here. We need to work as a community to bring it
[36:14.040 --> 36:25.240]  all to us, to be pleasant to work with. And with this one, I guess I'm even on time. Thank
[36:25.240 --> 36:26.240]  you.
[36:26.240 --> 36:43.520]  My question is about the two factor authentication when there is a password and a security key.
[36:43.520 --> 36:49.440]  Do you know why in all the work flow the password is first and then the security key? Whereas
[36:49.440 --> 36:55.920]  it likes to me that the security key is the strongest part, and it should be better to
[36:55.920 --> 37:01.200]  first press the button of the key and then enter the password. Is there some movement
[37:01.200 --> 37:06.040]  to change the current way of doing things?
[37:06.040 --> 37:17.520]  The question is whether using password and second factor and so on can be one of the
[37:17.520 --> 37:27.200]  ways of doing it. And is there an activity to make it better, let's say this way? Yes
[37:27.200 --> 37:33.960]  and no. It depends on what we define as the first factor and second factor. One of the
[37:33.960 --> 37:41.520]  driving factors behind password less work in the last 10 years or so across the industry
[37:41.520 --> 37:48.560]  is the tightening of requirements from the government, specifically from the U.S. government.
[37:48.560 --> 37:58.040]  The U.S. government issued a so-called zero trust memorandum last year for urging governmental
[37:58.040 --> 38:09.800]  organization to move by end of fiscal year 2024 to move to password less authentication.
[38:09.800 --> 38:16.780]  This means that they have smart cards already, so that's solved. But they specifically name
[38:16.780 --> 38:24.120]  web often 5-2-2 as one of the alternatives to smart cards. And in fact, all of these
[38:24.120 --> 38:31.080]  things they have PIN associated with this, which can be looked as a kind of first factor.
[38:31.080 --> 38:38.480]  But it's not the first factor as we understand it. It's a first factor to unlock hardware
[38:38.480 --> 38:48.840]  rather than unlocking some factor in software. So this is the thing which drives some of
[38:48.840 --> 38:55.760]  this work, not necessarily for us but for many others already. And I think there is
[38:55.760 --> 39:03.280]  a value in staking factors. The question is in which environments you want to use them
[39:03.280 --> 39:14.280]  and so on and configure it this way. Certainly there is already a mechanism to enable it.
[39:14.280 --> 39:20.760]  For example, PAM already is staking. So technically you can stack multiple PAM authentication
[39:20.760 --> 39:27.760]  modules in the same configuration for VLOC or GDM or something and say always enter three
[39:27.760 --> 39:36.360]  passwords from different sources. That already would be multi-factor, multi-password authentication.
[39:36.360 --> 39:41.360]  Or one of them this and the other one is the password and the third one is phase of the
[39:41.360 --> 39:49.000]  moon and so on. So you can get that stuff already. It's the question of adopting to a specific
[39:49.000 --> 39:58.240]  environment where this makes sense. I have not seen multi-password in the traditional
[39:58.240 --> 40:05.960]  kind of environments yet. But if we do something like integration with the identity providers
[40:05.960 --> 40:13.800]  like I show it in the demo, that gives you possibility to move this check away into let's
[40:13.800 --> 40:21.320]  say keyclog. Keyclog actually has ability to ask a password, OTP and the web often at
[40:21.320 --> 40:28.080]  the same time. So you can configure that already. Again, the question is in which direction
[40:28.080 --> 40:35.800]  you want to focus this. Maybe not adding into SSSD or some specific PAM module but instead
[40:35.800 --> 40:45.320]  adding into more flexible and more controllable source. Any other questions?
[40:45.320 --> 40:53.720]  Yes, here. So you were talking about how can distributions and desktop managers contribute
[40:53.720 --> 41:00.840]  to get like a unified interface and I recently come to a project called XTG credentials portal
[41:00.840 --> 41:07.480]  which tries to specify a standardized debas interface for interacting with web often credentials
[41:07.480 --> 41:12.600]  such that different KDE and GNOME and stuff can hook into this. I was wondering whether
[41:12.600 --> 41:18.000]  you were aware of this project and if that would be a good place to maybe start trying
[41:18.000 --> 41:26.160]  to collaborate on a unified interface. So the question is am I aware of the projects
[41:26.160 --> 41:34.520]  like XTG credentials that tries to specify or unify access to the credentials for things
[41:34.520 --> 41:42.000]  like I think it's for the containerized environments, desktop applications running in flat pack
[41:42.000 --> 41:48.960]  and so on. Yes, I am aware and that's one partial thing that I mentioned about the parallel
[41:48.960 --> 41:56.560]  effort there but it's not for the logging, it's for the reuse of the credentials in the
[41:56.560 --> 42:02.040]  browser or relaying party outside of the container so that you can isolate direct access. That's
[42:02.040 --> 42:09.520]  very important but it's a bit different layer and it's the layer that we will eventually
[42:09.520 --> 42:17.040]  need to reuse if we want to do this transferable state of authentication between different
[42:17.040 --> 42:26.680]  places without caregivers. Yes, we will have to work with them or Dave with us or everyone.
[42:26.680 --> 42:27.680]  Yes.
[42:27.680 --> 42:47.200]  Hello. So I use ED25519 security keys which SSH supports and it's really simple so I just
[42:47.200 --> 42:53.000]  generate a key and I can use it and my SSH demon supports it and I don't really need to
[42:53.000 --> 42:57.160]  run any services and I need to use Kerberos. How do we get to a world where everything
[42:57.160 --> 43:01.440]  is that simple?
[43:01.440 --> 43:10.320]  So the question is why do I need all these things if my SSH keys work fine with the hardware
[43:10.320 --> 43:19.760]  based tokens, X549 and basic certificates and so on. The answer is simple. It's not
[43:19.760 --> 43:28.760]  an answer for all use cases. You cannot authenticate with these tokens and these keys to, for example,
[43:28.760 --> 43:35.280]  file services. You cannot use them to authenticate to NFS. You cannot use them to authenticate
[43:35.280 --> 43:41.840]  to SMB or other resources. Needs are different, use cases are different. All of these things
[43:41.840 --> 43:49.320]  does not replace SSH keys and SSH keys do not replace this one. They exist in parallel to
[43:49.320 --> 43:56.560]  each other because if you start using FIDO2 tokens, you wouldn't be using them exactly
[43:56.560 --> 44:05.240]  the same way on SSH level as well because SSH will need to generate their own keys based
[44:05.240 --> 44:12.840]  on the same, use of the same hardware but different protocol specific and application
[44:12.840 --> 44:20.800]  specific thing. And this is where the program really comes in. You can find use cases where
[44:20.800 --> 44:30.160]  existing functionality is perfectly usable and secure and attainable but it's not transferable
[44:30.160 --> 44:37.040]  to the other systems and other protocols. That's the problem we try to solve. So it's
[44:37.040 --> 45:03.320]  more amending rather than displacement. Hello. Hello. And thanks for the talk. My question
[45:03.320 --> 45:09.800]  is if I'm a very, very bad person, I want to break this system and steal the Kerberos
[45:09.800 --> 45:17.120]  ticket authentication, for example, what's the easiest way I can do it? So the question
[45:17.120 --> 45:23.240]  is how to steal Kerberos ticket in the Linux environment in the easiest way despite all
[45:23.240 --> 45:32.600]  the protection mechanisms we want to add. I preferably answer what mechanisms we have
[45:32.600 --> 45:42.440]  so that you may reconsider your activities. So in comparison, Microsoft some time ago
[45:42.440 --> 45:51.720]  added a virtualized slice where they store all the credentials so you do not have access
[45:51.720 --> 45:58.920]  to that slice. It's running literally not as a container, it's like a VM separated from
[45:58.920 --> 46:08.720]  the actual system where they handle all the security credentials and so on. And you cannot
[46:08.720 --> 46:17.200]  easily store that from the memory of the applications that try to load this stuff. On Linux side
[46:17.200 --> 46:29.160]  at that point we had a project called GSS proxy. The GSS proxy is a daemon that runs in separate,
[46:29.160 --> 46:40.440]  typically on the root, and it interjects into GSS API, hence the GSS proxy. GSS API operations
[46:40.440 --> 46:51.760]  and interposes access to all Kerberos crypto material. So when you are a service like
[46:51.760 --> 47:02.960]  HDTPD or NFS, you want to have access to the Kerberos key tab so that you can authenticate
[47:02.960 --> 47:14.920]  clients coming to you and get access to it, or your IMAP or send mail or something. And
[47:14.920 --> 47:21.960]  GSS proxy basically removes access to the key tabs, removes access to credential cache
[47:21.960 --> 47:29.960]  that you use. They are in separate process. So now if you're broken into NFS server like
[47:29.960 --> 47:36.960]  Ganesha or even the kernel, well, kernel one is probably easier target, right, if you happen
[47:36.960 --> 47:45.240]  to find a bug that allows to exploit it. But you're probably not a Linux Torvalds anymore
[47:45.240 --> 47:56.000]  and it's not 1994 where he found NFS problems to hack into and get the data out. Out of
[47:56.000 --> 48:06.160]  NFS. So typically this privilege separation between the processes works fairly well.
[48:06.160 --> 48:18.040]  If you're root, of course, you get what you get. In that case, there's some number of
[48:18.040 --> 48:24.480]  ways of preventing root running processes from accessing the capabilities on the kernel
[48:24.480 --> 48:34.320]  level. And on typically still this is an operation that should probably be multi-layered. Like
[48:34.320 --> 48:41.320]  you have to use kernel capabilities, then you have to use the file system level capabilities
[48:41.320 --> 48:49.560]  then as a Linux or app armor to prevent other kind of access things. But basically with
[48:49.560 --> 48:58.880]  the GSS proxy we get isolation on this level and also we get the content of the credential
[48:58.880 --> 49:06.520]  caches encrypted. So you can store or you can steal credential cache if you get access
[49:06.520 --> 49:14.880]  to that. But it will be encrypted with temporary key that exists only until GSS proxy runs.
[49:14.880 --> 49:22.800]  So even if you steal it, you cannot really use that one. The other part is that there
[49:22.800 --> 49:29.520]  are credential cache collection types that do not allow direct access to the credential
[49:29.520 --> 49:36.240]  cache. So for example a key ring, kernel key ring where you can store and tighten it fairly
[49:36.240 --> 49:44.240]  tight so that the application doesn't get these keys out. The other one is KCM which
[49:44.240 --> 49:50.680]  is also a separate process accessible over the Unix domain socket. You don't get direct
[49:50.680 --> 49:59.080]  access to the files either. So there are some mechanisms. They are not so dramatic as in
[49:59.080 --> 50:05.800]  Windows case where they run it in completely different VM isolated on a hardware level.
[50:05.800 --> 50:14.040]  But we get fairly far away. I've seen people trying to decode the KCM databases but that
[50:14.040 --> 50:21.840]  presumes that they get access to the physical root partitions so they can read the actual
[50:21.840 --> 50:28.320]  files from the KCM back store. But of course that if you're root, if you haven't access
[50:28.320 --> 50:33.720]  to the root partition, your game is lost in most cases.
[50:33.720 --> 50:48.280]  Alexander, many thanks for your interesting talk to give the community.