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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
