On ke, 14 syys 2022, Kevin Fenzi wrote:
On Wed, Sep 14, 2022 at 05:47:46PM +0300, Alexander Bokovoy wrote:
On ke, 14 syys 2022, Stephen Smoogen wrote:
> On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy <abokovoy@xxxxxxxxxx>
> wrote:
>
> >
> > Sadly, it cannot be just 'any' certificate, it has to be issued by a
> > certificate authority that is trusted by the KDC as well. For example,
> > by FreeIPA CA which is already ran by the Fedora project infrastructure
> > team. An alternative is to set up certificate mapping and validating
> > rules.
> >
> > If someone from Fedora Accounts team wants to experiment with this, I
> > can guide you what to do.
> >
>
> There is no continual running Fedora Accounts 'team'. There are 2-3 system
> administrators split between releng, operations and continual
> firefighting. There are also a team of developers who are split between
> CentOS Stream initiatives and other work. Changes like this need to have
> more than just an 'oh I have finally an afternoon free where all the other
> crap in the build infra is actually working for once.. lets dive into IPA'
I understand all of that myself. I think what is important here is to
plan to work together so that eventually we can implement this.
Right and while I agree with what smooge says there, I'm definitely
interested in improving things as we can. I really would prefer a
detailed plan however, not 'lets enable everything we can and see what
sticks'. :)
Oh, for sure 'enable everything' is not what I or others suggest either.
;)
This whole thread is about agreeing or disagreeing whether Fedora as a
project would want to have better security methods to identify and
authenticate its contributors when performing tasks that have large
impact.
Yep. I'm in agreement that we want to... but there's always tradeoffs.
A few random things to mention:
* I don't think requiring FIDO2 for all packagers is tenable. It may
well be that we could get donations or funding to get hardware for all
packagers, especially if we wait for the current inactive process to
finish, but even so, we will run into problems of people who can't get
one shipped to them or gets lost in the mail, etc. There would also be a
delay "hey, you are now a packager, look for a token in the mail in the
next few weeks before you can do anything"
Proven packagers seem to be a fair category to address. Also packagers
responsible for security-related bits of the distribution. Compilers?
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.
* 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.
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.
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.
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.
We do have https pushes using oauth/oidc token right now.
That is different. Please watch our talk at the Nest for demo and
explanations.
Also, once we upgrade src.fedoraproject.org/pkgs.fedoraproject.org from
RHEL8 to RHEL9, it will be possible to use ecdsa-sk and ed25519-sk ssh
keys and thus use FIDO2 for ssh actions if we wish.
This would be limited to SSH protocol access only. Probably OK but we
want to improve on this for cases where you'd need to define higher
standards on what is allowed to use to login and where. Fedora
infrastructure has limited use for that for most of contributors (we are
rarely getting logged to Fedora hosts ourselves) but removing a need to
use passwords in sudo, for example, is a useful measure (we can achieve
it already with pam_sss_gss and authentication indicators in Kerberos
tickets).
> As much as I enjoy better security, everyone should remember that the ones
> affected are either packagers who are volunteering to make spec files for
> software they need for something else.. or developers who only look at spec
> files as the last hassle they need to do before they can mark on their list
> 'shipped and done'. Most of them do not package/build things very often,
> and it takes years for them to get retrained when some change in the
> workflow occurs.
A particular benefit of using Kerberos authentication to Fedora services
is that it does not need to change the workflow for all those things.
Once you've got your ticket, it works against all the services you are
allowed to access. Sure, actual process of obtaining that ticket might
change -- like with 2FA token one needs to get a wrap ticket first --
but the rest is the same.
Yeah, it's much nicer when everything uses a standard thing and all the
various flows stick to that. Right now our auth for commits to
src.fedoraproject.org is anything but standard. https and ssh use
different paths and this causes a bunch of confusion.
> They are also the only ones around to do the work. Making workflow changes
> like adding certificates, tokens, etc may be needed but they are going to
> need a lot of documentation, continual training, and coaching to actually
> make function. If there is no staff or people available to do this, then
> the change will fail hard.
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?
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
