On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:
Proven packagers seem to be a fair category to address. Also packagers
responsible for security-related bits of the distribution. Compilers?
Well, as others noted in this thread, any packager has a lot of power.
They can add a weak dep on something everyone has installed and pull
their package in. Of course they likely only get to do that once.
There is probably a value in defining what functions critical to
have
strongly authenticated and identified to the distribution at large. For
example, right now even 2FA OTP requirement is not mandatory for certain
package groups.
As far as I know, it's not possible to enforce otp per group is it?
That would be a nice enhancement.
Additionally, right now, packagers commit with ssh keys or oidc tokens,
in order for a 2fa setup to be effective, we would need to switch that
to kerberos or the like.
> * I'd really prefer to avoid going back to certs. People
have all kinds
> of problems with certs. I think it would cause a lot of confusion.
> (Unless I am misunderstanding what use is proposed for them).
>
> > If Fedora contributors would have had access to Fedora's FreeIPA web UI
>
> We actually do have external access to the web UI.
> We just don't advertise it much.
Ok, that's good to hear in case we need to experiment with our accounts
before the Fedora Accounts UI is expanded to cover other authentication
methods.
Yep.
> > or IPA API directly, we wouldn't even need to have a
conversation about
> > PKINIT and certificates. We could have added instructions how to request
> > and associate a certificate with your account. But since Fedora Accounts
> > system is the frontend to Fedora Project's FreeIPA deployment, we cannot
> > simply do that. However, FreeIPA-wise, smartcards are supported now for
> > Kerberos authentication, so we as Fedora contributors could benefit from
> > that.
>
> What would this use of certificates do here?
> Authenticate you to get a kerberos ticket?
> Allow you to login to the account interface?
The former. I am only considering all of this to allow Kerberos
authentication with stronger methods. Smartcards are more accessible
these days than, say, FIDO2 tokens. A card reader cost is around 10EUR
(Amazon.de gives me ~100 options of USB smartcard readers below 20EUR),
a smartcard is typically your government-issued ID in many countries.
Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close
enough to a lower boundary.
Yeah, it will still be hard to require 100% of packagers, but it might
be doable.
Anyway, using a soft-based smartcard e.g. using NSS database stored
on a
usb flash drive and accessible via PKCS11 could also be an option. The
problem here is to attest to a server side it is protected by the client
but this is a common problem to all different methods. Even storing a
key-pair on your hard drive would work with Kerberos PKINIT without any
problem.
> CentOS folks still use certs for their koji:
>
https://wiki.centos.org/Authentication#TLS_certificate
> (and thats using the same account system/ipa servers as fedora).
>
> > I hope we can plan to work together on this improvement again, similar
> > how we did with the initial rewrite of Fedora Accounts on top of
> > FreeIPA. Again, if this is deemed to be valuable to Fedora contributors,
> > perhaps CPA team could consider scheduling this effort as part of the
> > initiatives.
>
> Yeah, I would like that. Perhaps we could setup a meeting soon and
> dicuss plans? I'm open to video meeting, but we could also do IRC to
> keep things more open...
I am open to it too, may be in couple weeks or so, to allow interested
parties to prepare.
Sure. Can you schedule something when you are ready/available and we can
go from there.
> > Let me round up methods that we have supported now or plan
to add in
> > Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to
> > issuance of a Kerberos ticket that can be used for communicating with
> > the rest of Fedora services:
> > - basic password-based authentication
> > - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself - use of an
> > external RADIUS server for validation of a string passed as
> > a 'password' or 'token' value
> > - use of a certificate stored on a supported PKCS11 token (smartcard,
> > softtoken (SoftHSMv2, NSS) or just in plain keypair files)
> > - use of OAuth2 device authorization grant against some OAuth2 IdP (new
> > in FreeIPA 4.9.10+)
> > - (future) use of a FIDO2/WebAuthn token
> >
> > Fedora accounts system implements the management of the first two
> > methods right now.
>
> And possibly the 3rd...
>
> What does 'device' mean in the 4th one? :)
It is part of OAuth 2.0 specifications, 'Device Authorization Grant
flow' is defined by RFC 8628:
https://www.rfc-editor.org/rfc/rfc8628. It
is not a device in itself but rather a method for devices limited in
expressive capabilities to get access to OAuth2-protected resources on
behalf of a user.
ok. Makes sense.
...snip...
> > Do we have any statistics of how we stand now that Fedora
Accounts is
> > deployed for more than a year and people were enabled to use 2FA tokens
> > through it?
>
> I could try and gather some. What stats would be helpfull?
A particular argument by smooge and others was arount 'passwords or
tokens being lost frequently'. I'd like to see how widespread is this
problem. Can we collect stats on amount of requests to reset passwords,
reset tokens, etc. for a period of a year or so?
We currently have 1560 tokens enrolled.
(Of course some users have more than one, but most seem to have one)
In the 1 year period from 2021-07-01 to 2022-07-01 we had 87 requests to
reset otp. Some of these were people who were confused and didn't actually
even have a otp enabled, but it's hard to count those without going
through each request.
So, it's less than 5% a year it seems like, or a request every 4days if
they were evenly spaced.
kevin