Proven packagers,
we changed [2,3] the FESCo policy document [1] for provenpackagers to say:
"Provenpackagers SHOULD have two-factor-authentication (2FA) enabled for their FAS accounts."
This is not enforced or checked, but please take steps to conform to the policy if you haven't yet.
[1] https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ [2] It's not visible on the web yet, because antora is doing its thing … slowly. [3] https://pagure.io/fesco/issue/3186
Zbyszek
How do I disable this?, it has made kerberos login much harder. I'm considering ditching provenpackager rights if that is a condition.
Dne 23. 06. 24 v 11:50 dop. Leigh Scott napsal(a):
it has made kerberos login much harder
Can you elaborate?
I use Kerberos login without a problem.
I'm considering ditching provenpackager rights if that is a condition.
Or you can help us to improve the user experience.
I normally use gnome-online-accounts to unlock Kerberos when I login, now I need to use CLI.
On Sun, Jun 23, 2024 at 11:59 AM Miroslav Suchý msuchy@redhat.com wrote:
Dne 23. 06. 24 v 11:50 dop. Leigh Scott napsal(a):
it has made kerberos login much harder
Can you elaborate?
I use Kerberos login without a problem.
I'm considering ditching provenpackager rights if that is a condition.
Or you can help us to improve the user experience.
What reasonable path do any of us have to improve that user experience? Most of the problems are tied up in FreeIPA. This is not exactly a system that any Fedora contributor is necessarily skilled in, and the complexity of the stack makes it difficult for a newcomer to grasp. It's not like the old FAS which was all in Python, even if it was custom.
I've asked before about making GOA and KAccounts support Kerberos-FAS fully even with MFA, and I've been told that it's basically not possible as things currently stand.
I've been against the move to MFA for the sole reason that there has been no effort around supporting it in GOA in a decade. What makes me think it would change now?
-- 真実はいつも一つ!/ Always, there's only one truth!
On Няд, 23 чэр 2024, Neal Gompa wrote:
On Sun, Jun 23, 2024 at 11:59 AM Miroslav Suchý msuchy@redhat.com wrote:
Dne 23. 06. 24 v 11:50 dop. Leigh Scott napsal(a):
it has made kerberos login much harder
Can you elaborate?
I use Kerberos login without a problem.
I'm considering ditching provenpackager rights if that is a condition.
Or you can help us to improve the user experience.
What reasonable path do any of us have to improve that user experience? Most of the problems are tied up in FreeIPA. This is not exactly a system that any Fedora contributor is necessarily skilled in, and the complexity of the stack makes it difficult for a newcomer to grasp. It's not like the old FAS which was all in Python, even if it was custom.
I've asked before about making GOA and KAccounts support Kerberos-FAS fully even with MFA, and I've been told that it's basically not possible as things currently stand.
Can you point me to a discussion where it says it is impossible to implement that in GOA?
The missing part here is a time and effort, not a technical limitation.
GOA already has all needed bits and pieces to support Fedora's use of multi-factor Kerberos methods FreeIPA provides, there is a need to add a way to configure and acquire an anonymous PKINIT ticket which is a couple dozen lines of code.
I've been against the move to MFA for the sole reason that there has been no effort around supporting it in GOA in a decade. What makes me think it would change now?
I have a work in progress branch https://gitlab.gnome.org/abbra/gnome-online-accounts/-/tree/add-fast-channel... that attempts to implement use of Anonymous PKINIT for the FAST channel in GOA. I am talking to Ray Strode to get this further upstream.
On 24/06/2024 10:45, Alexander Bokovoy wrote:
Can you point me to a discussion where it says it is impossible to implement that in GOA?
FAS (kinit) should request the OTP code in a separate prompt.
If kinit asks for a password and OTP codes in separate prompts, GOA will be able to parse it, store the password, and ask the user to enter the OTP code.
On Пан, 24 чэр 2024, Vitaly Zaitsev via devel wrote:
On 24/06/2024 10:45, Alexander Bokovoy wrote:
Can you point me to a discussion where it says it is impossible to implement that in GOA?
FAS (kinit) should request the OTP code in a separate prompt.
This is not how it works in Kerberos. FAS wrapper (fkinit) is handling separate prompts but for kinit itself the question asked by the plugin is only expecting a single answer because the Kerberos client plugin (otp, in this case) only relays the questions asked by the backend (KDC part of 'otp' plugin) and there it is a single question. Communication protocol wise that single answer is treated as a plain text answer which is passed to a RADIUS server as a part of the Accept-Request request.
This is pretty much generic and cannot be modified. The RADIUS server backend that FreeIPA provides does a bit of smart logic to split password and OTP token value in one of use cases internally but this is not visible to the KDC at all.
If kinit asks for a password and OTP codes in separate prompts, GOA will be able to parse it, store the password, and ask the user to enter the OTP code.
No, this will not work at all. The OTP pre-authentication method is not visible to a Kerberos client unless the client is using a special Kerberos extension which allows to securely pass the plain text answers (FAST channel). Without FAST channel established, GOA will not see anything but password-based and smartcard-based exchanges. So splitting prompts does not help.
Once GOA is able to create a FAST channel, then prompts will appear and will be usable in GOA, for all passwordless methods that FreeIPA provides (RADIUS proxy, otp, FIDO2, and external IdP (OAuth2)). And then GOA frontend can detect which plugin asks what with those prompts and add additional logic, like showing prompts differently or combining password and OTP value entered separately.
On Пан, 24 чэр 2024, Alexander Bokovoy wrote:
On Няд, 23 чэр 2024, Neal Gompa wrote:
On Sun, Jun 23, 2024 at 11:59 AM Miroslav Suchý msuchy@redhat.com wrote:
Dne 23. 06. 24 v 11:50 dop. Leigh Scott napsal(a):
it has made kerberos login much harder
Can you elaborate?
I use Kerberos login without a problem.
I'm considering ditching provenpackager rights if that is a condition.
Or you can help us to improve the user experience.
What reasonable path do any of us have to improve that user experience? Most of the problems are tied up in FreeIPA. This is not exactly a system that any Fedora contributor is necessarily skilled in, and the complexity of the stack makes it difficult for a newcomer to grasp. It's not like the old FAS which was all in Python, even if it was custom.
I've asked before about making GOA and KAccounts support Kerberos-FAS fully even with MFA, and I've been told that it's basically not possible as things currently stand.
Can you point me to a discussion where it says it is impossible to implement that in GOA?
The missing part here is a time and effort, not a technical limitation.
GOA already has all needed bits and pieces to support Fedora's use of multi-factor Kerberos methods FreeIPA provides, there is a need to add a way to configure and acquire an anonymous PKINIT ticket which is a couple dozen lines of code.
I've been against the move to MFA for the sole reason that there has been no effort around supporting it in GOA in a decade. What makes me think it would change now?
I have a work in progress branch https://gitlab.gnome.org/abbra/gnome-online-accounts/-/tree/add-fast-channel... that attempts to implement use of Anonymous PKINIT for the FAST channel in GOA. I am talking to Ray Strode to get this further upstream.
Small update. We've got to the point where I am able to handle all FreeIPA supported pre-authentication methods in GNOME Online Accounts. I am working with Ray on fixing up some UX stuff that comes in the way of first probing for a supported method and then asking for the credentials (as opposed to first asking for a password and then authenticating now).
A progress can be tracked in the following merge request: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/250
We aim to finish this for GNOME 47, give or take.
I am on vacation for this and next weeks and might have some time to advance this work...
Am 23.06.24 um 2:20 PM schrieb Sérgio Basto:
On Sun, 2024-06-23 at 09:50 +0000, Leigh Scott wrote:
How do I disable this?, it has made kerberos login much harder. I'm considering ditching provenpackager rights if that is a condition.
This (2FA) is not enforced or checked,
Hopefully this situation will last. I for consider, using F2A for provenpacker access to be meanless and non-helpful "me-too" featuritis.
Ralf
I'm so pissed of with this change I will probably leave the project if it's not reversed.
Il 23/06/24 20:54, Leigh Scott ha scritto:
I have deleted the google authentication app form my phone intentionally, no backup. Please remove the OTP form my fedora account!
I refuse to use 2FA for my account!
Please stop. We've already understood that three emails ago.
If you want to have the 2FA removed from your account see https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/2-factor/#_adminis...
Admins need to verify the users identity before processing these
requests.
Including, but not limited to:
user sends gpg signed email with gpg key attached to their Fedora
account
user can ssh to fedorapeople.org with the ssh private key
associated with a ssh public key associated with their Fedora account rover verification (in case of Red Hat employee).
Video or in person meeting with admin who knows their identity on
sight.
This kind of requests, sent to a public mailing list, are exactly the type of attack 2FA will prevent. You need to verify who you really are to have your token deleted.
Mattia
On 23. 06. 24 20:33, Leigh Scott wrote:
Once set you can't disable it. If this persists I will ditch provenpackager group
Leaving the group won't disable 2FA.
I recommend opening a fedora-infrastructure ticket and asking for help.
On 6/23/24 14:01, Leigh Scott wrote:
On 23. 06. 24 20:33, Leigh Scott wrote:
Leaving the group won't disable 2FA.
I recommend opening a fedora-infrastructure ticket and asking for help.
I can't login as I don't have the otp needed to login
So you say. Or you may be someone who's taken over Leigh's email (or is simply spoofing it) and are making a fuss about it in order to take over the account.
If you wanted this removed, this is not how to do it. I hate to say it, but your attempt to prove a point may have just made you have to start from scratch in Fedora contribution.
On Sun, Jun 23, 2024 at 07:01:02PM GMT, Leigh Scott wrote:
On 23. 06. 24 20:33, Leigh Scott wrote:
Leaving the group won't disable 2FA.
I recommend opening a fedora-infrastructure ticket and asking for help.
I can't login as I don't have the otp needed to login
If you are unable to open a ticket, per https://docs.fedoraproject.org/en-US/infra/day_to_day_fedora/#_emergencyauth... you can mail admin@fedoraproject.org (which you did).
A few things to note:
It's not completely the case that theres no gnome online accounts support. Once you get a kerberos ticket with fkinit or the like, GOA will renew your ticket up to a week if you add it there.
So, you have to enter your OTP once a week.
Also, this policy change says "SHOULD". You can of course not have that enabled, it's not MUST.
You can enroll as many tokens as you like, so you can enroll one in a backup device or system in case you loose your primary token. You only need any one otp to login. Things like keepassxc and bitwarden allow you to setup OTPs these days.
kevin
Il 24/06/24 03:42, Kevin Fenzi ha scritto:
You can enroll as many tokens as you like, so you can enroll one in a backup device or system in case you loose your primary token. You only need any one otp to login. Things like keepassxc and bitwarden allow you to setup OTPs these days.
kevin
IMO, having the token stored in your password manager means going from 2FA to 1FA effectively ;-) if someone gets access to your password manager vault, all accounts will be compromised.
That said, even if the token is stored in the password manager, it is not cushy to be used with kerberos. I have been using 2FA for over a year now and I get used to, but it's clumsy to use it in Fedora infrastructure. I'd really like if we can move everything related to 2FA to use a yubikey or something like that, so that users could just authenticate by having their key inserted in a USB port.
Mattia
Dne 24. 06. 24 v 9:48 dop. Mattia Verga via devel napsal(a):
IMO, having the token stored in your password manager means going from 2FA to 1FA effectively ;-) if someone gets access to your password manager vault, all accounts will be compromised.
Only if you use the same password manager for both: password and OTP.
On 6/24/24 5:08 AM, Miroslav Suchý wrote:
Dne 24. 06. 24 v 9:48 dop. Mattia Verga via devel napsal(a):
IMO, having the token stored in your password manager means going from 2FA to 1FA effectively ;-) if someone gets access to your password manager vault, all accounts will be compromised.
Only if you use the same password manager for both: password and OTP.
It still makes it 1FA. If all you need to get the OTP is know which password managers the user uses, and what is the password for that passowrd manager, OTP goes from being a "something you have" type of authentication factor, to a "something you know" authentication factor, which is the same factor as the password. Multi factor authentication is not about steps, is about what you need to complete the authentication challenge (something you know, something you have, or something you are).
Guinevere Larsen venit, vidit, dixit 2024-06-24 13:53:37:
On 6/24/24 5:08 AM, Miroslav Suchý wrote:
Dne 24. 06. 24 v 9:48 dop. Mattia Verga via devel napsal(a):
IMO, having the token stored in your password manager means going from 2FA to 1FA effectively ;-) if someone gets access to your password manager vault, all accounts will be compromised.
Only if you use the same password manager for both: password and OTP.
It still makes it 1FA. If all you need to get the OTP is know which password managers the user uses, and what is the password for that passowrd manager, OTP goes from being a "something you have" type of authentication factor, to a "something you know" authentication factor, which is the same factor as the password. Multi factor authentication is not about steps, is about what you need to complete the authentication challenge (something you know, something you have, or something you are).
Sure, and the "something you have" is access to the OTP device which in this case is the (token stored in the ) password manager's database.
The password or passphrase which unlocks the password manager is nothing which you could provide as a "factor".
Or else, all cloneable OTP apps would need to be disallowed as 2nd factors, and only physical tokens should count.
Michael
On Mon, Jun 24, 2024 at 9:28 AM Michael J Gruber mjg@fedoraproject.org wrote:
Guinevere Larsen venit, vidit, dixit 2024-06-24 13:53:37:
On 6/24/24 5:08 AM, Miroslav Suchý wrote:
Dne 24. 06. 24 v 9:48 dop. Mattia Verga via devel napsal(a):
IMO, having the token stored in your password manager means going from 2FA to 1FA effectively ;-) if someone gets access to your password manager vault, all accounts will be compromised.
Only if you use the same password manager for both: password and OTP.
It still makes it 1FA. If all you need to get the OTP is know which password managers the user uses, and what is the password for that passowrd manager, OTP goes from being a "something you have" type of authentication factor, to a "something you know" authentication factor, which is the same factor as the password. Multi factor authentication is not about steps, is about what you need to complete the authentication challenge (something you know, something you have, or something you are).
Sure, and the "something you have" is access to the OTP device which in this case is the (token stored in the ) password manager's database.
The password or passphrase which unlocks the password manager is nothing which you could provide as a "factor".
Or else, all cloneable OTP apps would need to be disallowed as 2nd factors, and only physical tokens should count.
Also, why does everyone seem to assume that a password manager isn't ITSELF protected by 2FA? For my lower-concern sites, I am just fine with keeping the TOTP code in the manager because the manager itself is protected by a strong password and a physical FIDO device (Yubikey).
Remember that security is a spectrum, not an end-state. Every person and environment makes a choice between how much security and how much convenience is appropriate. If you want perfect security, you can unplug your PC, fill it with concrete and drop it into the Marianas Trench. Otherwise, you make some compromises...
Once upon a time, Stephen Gallagher sgallagh@redhat.com said:
Remember that security is a spectrum, not an end-state. Every person and environment makes a choice between how much security and how much convenience is appropriate. If you want perfect security, you can unplug your PC, fill it with concrete and drop it into the Marianas Trench. Otherwise, you make some compromises...
Also, even when 2FA is stored in a personal manager, it's still a protection for the site/service against people reusing passwords. If someone reuses (same or similar in a common fashion) a password on sites A and B, and A is compromised, a 2FA protects site B from also being accessed.
On 24/06/2024 15:27, Michael J Gruber wrote:
Or else, all cloneable OTP apps would need to be disallowed as 2nd factors, and only physical tokens should count.
FIDO2 is even worse than OTP since most (or even all) implementations are proprietary (for example, Android requires proprietary GMS to function as a FIDO2 provider) or require the user to purchase a hardware token (most are proprietary black boxes too).
On 6/24/24 10:27 AM, Michael J Gruber wrote:
Guinevere Larsen venit, vidit, dixit 2024-06-24 13:53:37:
On 6/24/24 5:08 AM, Miroslav Suchý wrote:
Dne 24. 06. 24 v 9:48 dop. Mattia Verga via devel napsal(a):
IMO, having the token stored in your password manager means going from 2FA to 1FA effectively ;-) if someone gets access to your password manager vault, all accounts will be compromised.
Only if you use the same password manager for both: password and OTP.
It still makes it 1FA. If all you need to get the OTP is know which password managers the user uses, and what is the password for that passowrd manager, OTP goes from being a "something you have" type of authentication factor, to a "something you know" authentication factor, which is the same factor as the password. Multi factor authentication is not about steps, is about what you need to complete the authentication challenge (something you know, something you have, or something you are).
Sure, and the "something you have" is access to the OTP device which in this case is the (token stored in the ) password manager's database.
if you can count "something you have" like "having access to a database", then I have access to the knowledge of my password and it is still just 1FA. In fact, I also have my thumb, so fingerprint is also "something I have" and there is only one true true authentication method going by this definition.
That's not how security factors work. Something you have must be a physical thing. that's why you're supposed to put your OTP 2FA generator on a different device from where you access the things you access.
The password or passphrase which unlocks the password manager is nothing which you could provide as a "factor".
Or else, all cloneable OTP apps would need to be disallowed as 2nd factors, and only physical tokens should count.
Well... yes. If we go by the strictest definition of a physical authentication factor, if you can clone the physical thing without having physical access to it, you're in trouble. That's why you shouldn't save your private SSH/GPG keys in any old cloud out there for instance. if you have a backup, it should be one that's physically accessible to you and only you at all times.
Now, as Stephen mentioned, compromises are made because security has to work in real life. Backups are more important than ideal security, but people should be aware of when they are deliberately breaking designed security for the convenience, and IMO, adding OTP generation to a cloud database accessible on any device is way beyond a reasonable compromise to use 2FA. You're as free to think it isn't too far for you as you are free to use "Password1" for any online account.
Am 24.06.24 um 13:53 schrieb Guinevere Larsen:
On 6/24/24 5:08 AM, Miroslav Suchý wrote:
Dne 24. 06. 24 v 9:48 dop. Mattia Verga via devel napsal(a):
IMO, having the token stored in your password manager means going from 2FA to 1FA effectively ;-) if someone gets access to your password manager vault, all accounts will be compromised.
Only if you use the same password manager for both: password and OTP.
It still makes it 1FA. If all you need to get the OTP is know which password managers the user uses, and what is the password for that passowrd manager, OTP goes from being a "something you have" type of authentication factor, to a "something you know" authentication factor, which is the same factor as the password. Multi factor authentication is not about steps, is about what you need to complete the authentication challenge (something you know, something you have, or something you are).
One could argue that the "password manager file" is the "something you have" thing.
Kilian
Kilian Hanich via devel devel@lists.fedoraproject.org writes:
One could argue that the "password manager file" is the "something you have" thing.
No, one cannot. The three factors in security are:
1. Something you know, which means other people do NOT know it. It exists in your brain and nowhere else.
2. Something you have, which means nobody else can also have it. It can be held in your hand or stolen but there are not two of them.
3. Something you are, like your retina, fingerprints, DNA, weight, etc. Something that another person cannot "be".
Putting 2FA on your phone is grudgingly accepted because your phone is "something you have". You don't "have" the app, you "have" the phone. You can't share your phone with someone else, and you'll notice if your phone is stolen.
The "password manager file" can be copied, so it can't be "something you have" because someone else could have a copy too. The password for that file might be "something you know" though, and the file might exist on "something you own", but the file itself isn't a security factor.
Am 24.06.24 um 17:51 schrieb DJ Delorie:
Kilian Hanich via devel devel@lists.fedoraproject.org writes:
One could argue that the "password manager file" is the "something you have" thing.
No, one cannot. The three factors in security are:
Something you know, which means other people do NOT know it. It exists in your brain and nowhere else.
Something you have, which means nobody else can also have it. It can be held in your hand or stolen but there are not two of them.
Something you are, like your retina, fingerprints, DNA, weight, etc. Something that another person cannot "be".
Putting 2FA on your phone is grudgingly accepted because your phone is "something you have". You don't "have" the app, you "have" the phone. You can't share your phone with someone else, and you'll notice if your phone is stolen.
The "password manager file" can be copied, so it can't be "something you have" because someone else could have a copy too. The password for that file might be "something you know" though, and the file might exist on "something you own", but the file itself isn't a security factor.
All OTP apps I know of can replicate their stuff to other devices (which can be your Laptop), some of which without deactivating the currently active one (it's often just showing a QR code another phone can scan).
That is pretty much just like copying a file around (although I tad bit more annoying, but not by much).
So, if we really don't count the password manager file because it can be copied easily, one also cannot count the ones from from apps since they can also be easily replicated.
Kilian Hanich khanich.opensource@gmx.de writes:
So, if we really don't count the password manager file because it can be copied easily, one also cannot count the ones from from apps since they can also be easily replicated.
I agree. Hence "grudgingly accepted".
24. kesäkuuta 2024 19.21.02 GMT+03:00 DJ Delorie dj@redhat.com kirjoitti:
Kilian Hanich khanich.opensource@gmx.de writes:
So, if we really don't count the password manager file because it can be copied easily, one also cannot count the ones from from apps since they can also be easily replicated.
I agree. Hence "grudgingly accepted".
I wonder, as there seems to be significant variation on what different people consider true 2FA, should the policy also say something about the expectation on TOTP secret management? Or are we satisfied if proven packagers are able to generate TOTP by whatever means?
Personally, I have all my passwords AND all my TOTP in a single KeePassXC database that is replicated to devices where I need it. Previously, I had a separate app for TOTP, but I could not understand how having two databases with two passwords on my phone was increasing security, so I simplified. My understanding is that the only, but perhaps significant, gains here are that TOTP does not send its long-lived secret over the wire, and I cannot decide to reuse (a set of) secrets for more than one site. That is great, but not "multi factor", like this setup is usually called. Everything would be no less secure, and simpler for me, if I could just disable the traditional password for sites that accept TOTP.
I also have hard time believing that there is a significant fraction of people who do not ever log into their important sites from their phone. So in my opinion the "your phone is your second factor" idea does not fly.
Am 24.06.24 um 09:48 schrieb Mattia Verga via devel:
That said, even if the token is stored in the password manager, it is not cushy to be used with kerberos. I have been using 2FA for over a year now and I get used to, but it's clumsy to use it in Fedora infrastructure. I'd really like if we can move everything related to 2FA to use a yubikey or something like that, so that users could just authenticate by having their key inserted in a USB port.
YubiKeys have two disadvantages:
1. You need to buy one (and not loose them). Sure, they aren't overly expensive, but it's also not free. 2. It's either a hazzle of constantly need to plug it in, or you take up a USB port. And on a Laptop that is always kinda awkward (besides the fact that a lot of modern Laptops don't have a lot of ports).
YubiKeys have ofc a lot of other advantages, but (as always) it's a tradeoff.
Kilian
On Mon, Jun 24, 2024 at 03:41:19PM +0200, Kilian Hanich via devel wrote:
- You need to buy one (and not loose them). Sure, they aren't overly
expensive, but it's also not free.
If we decide that this is a good idea, we might be able to get funding to distribute these to all proven packagers (and perhaps more).
On Пан, 24 чэр 2024, Matthew Miller wrote:
On Mon, Jun 24, 2024 at 03:41:19PM +0200, Kilian Hanich via devel wrote:
- You need to buy one (and not loose them). Sure, they aren't overly
expensive, but it's also not free.
If we decide that this is a good idea, we might be able to get funding to distribute these to all proven packagers (and perhaps more).
BTW, the cheapest and verified to work with Fedora USB token I was able to find is T2F2-NFC-Slim from Token2.eu: https://www.token2.eu/shop/product/token2-t2f2-nfc-slim-fido2-u2f-and-totp-s...
The company actually sponsored FIDO2 passkey support development for FreeIPA by sending this token to me a year ago. It is still in active daily use.
This token supports HOTP, TOTP, and FIDO2 operations, so it can be used with Fedora Accounts today and in future, when Fedora infrastructure upgrades to RHEL 9.4+, it will be able to handle FIDO2 passkey authentication as well.
On Mon, Jun 24, 2024 at 09:02:05PM GMT, Alexander Bokovoy wrote:
BTW, the cheapest and verified to work with Fedora USB token I was able to find is T2F2-NFC-Slim from Token2.eu: https://www.token2.eu/shop/product/token2-t2f2-nfc-slim-fido2-u2f-and-totp-s...
The company actually sponsored FIDO2 passkey support development for FreeIPA by sending this token to me a year ago. It is still in active daily use.
This token supports HOTP, TOTP, and FIDO2 operations, so it can be used with Fedora Accounts today and in future, when Fedora infrastructure upgrades to RHEL 9.4+, it will be able to handle FIDO2 passkey authentication as well.
Yeah, note that we are using RHEL 9.4, but... we need to add FIDO2/passkey management to noggin (the account system/frontend). (Unless I am missing something).
I filed https://github.com/fedora-infra/noggin/issues/1424 on this, please feel free to add info there.
kevin
On Mon, Jun 24, 2024 at 6:02 PM Alexander Bokovoy abokovoy@redhat.com wrote:
BTW, the cheapest and verified to work with Fedora USB token I was able to find is T2F2-NFC-Slim from Token2.eu: https://www.token2.eu/shop/product/token2-t2f2-nfc-slim-fido2-u2f-and-totp-s...
When I was looking for "cheap", I found the the adafruit FIDO2 key is $9.95 (USD):
https://www.adafruit.com/product/3363
This is actually the key-id key, and more info (and where to buy) can be found at:
On 24/06/2024 19:47, Matthew Miller wrote:
If we decide that this is a good idea, we might be able to get funding to distribute these to all proven packagers (and perhaps more).
Even to those countries that the US does not like? :-)
On Mon, Jun 24, 2024 at 5:48 PM Matthew Miller mattdm@fedoraproject.org wrote:
If we decide that this is a good idea, we might be able to get funding to distribute these to all proven packagers (and perhaps more).
FD: I am *strongly* in favor of FIDO2 support.
As I recall from a previous query, there are (around) 90 active proven packagers (and ~250 total who were in the PP group).
At ~$10/key (*) that is around $2500 total for all PPs if everyone needed one (and since FIDO2 keys are becoming more common in many orgs, not everyone would need one).
The larger issue may be re-issue when a key is lost/stolen (and some will be, eventually). Enterprises tend to have various methods to validate individuals and reissue new keys, but Fedora may have to create some new processes.
I also do not know if FIDO2 keys can be shipped to the magic 4 countries, or any of the additional ~34 countries (although I have no idea if any PP's have mailing addresses in those countries).
The larger issue continues to be that while Passkey (the consumer branding for the underlying FIDO2 technology) support is apparently possible with the latest FreeIPA, Ipsilon is (as I understand it) essentially orphaned, and any replacement (keycloak?) does not have a schedule for deployment.
(*) Based on the key-id pricing. When bought in bulk, better deals may be possible from a number of vendors, and some vendors might even be willing to offer better deals (maybe even "free") with various sponsorship deals ("Trusted by Fedora").
On 24/06/2024 23:38, Gary Buhrmaster wrote:
As I recall from a previous query, there are (around) 90 active proven packagers (and ~250 total who were in the PP group).
I think most privacy/security focused developers/maintainers won't plug USB tokens they get from random people on the Internet into their PC/laptop because it could be a BadUSB or something even worse.
The most common attack is when an attacker plants USB devices near the office of the company they want to attack. Connecting such devices is completely NO-GO.
On Tue, Jun 25, 2024 at 4:48 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 24/06/2024 23:38, Gary Buhrmaster wrote:
As I recall from a previous query, there are (around) 90 active proven packagers (and ~250 total who were in the PP group).
I think most privacy/security focused developers/maintainers won't plug USB tokens they get from random people on the Internet into their PC/laptop because it could be a BadUSB or something even worse.
The most common attack is when an attacker plants USB devices near the office of the company they want to attack. Connecting such devices is completely NO-GO.
There's a certain amount of trust required in accepting a USB key from *anyone* (even if you were to order one directly from Yubico, RSA, Adafruit, etc.).
If we move to requiring tokens, I think it's entirely certain that we would allow anyone to provide their own that we enroll. I assume that Matthew's offer was for us to be able to help those who (for one reason or another) cannot afford one. In that situation, the provenpackagers would be making a three way decision: 1) Stop being a provenpackager, 2) buy their own token or 3) accept one provided by Fedora.
I am not a lawyer, but I would assume that if Fedora offered to provide such a token, it would be reviewed by Legal and provide some form of legally-binding assertion that we weren't sending out malicious devices.
On 25/06/2024 15:06, Stephen Gallagher wrote:
I am not a lawyer, but I would assume that if Fedora offered to provide such a token, it would be reviewed by Legal and provide some form of legally-binding assertion that we weren't sending out malicious devices.
Who can guarantee that these devices were not replaced during delivery?
In that situation, the provenpackagers would be making a three way decision: 1) Stop being a provenpackager, 2) buy their own token or 3) accept one provided by Fedora.
4. Allow classic OTP codes.
I would prefer this one since I can use open source applications to generate these codes. I can't find any FIDO2 implementations that are completely open source which doesn't require proprietary technologies like TPM or SGX. Relying on a black box is not an option for me.
On Аўт, 25 чэр 2024, Vitaly Zaitsev via devel wrote:
On 25/06/2024 15:06, Stephen Gallagher wrote:
I am not a lawyer, but I would assume that if Fedora offered to provide such a token, it would be reviewed by Legal and provide some form of legally-binding assertion that we weren't sending out malicious devices.
Who can guarantee that these devices were not replaced during delivery?
In that situation, the provenpackagers would be making a three way decision: 1) Stop being a provenpackager, 2) buy their own token or 3) accept one provided by Fedora.
- Allow classic OTP codes.
I would prefer this one since I can use open source applications to generate these codes. I can't find any FIDO2 implementations that are completely open source which doesn't require proprietary technologies like TPM or SGX. Relying on a black box is not an option for me.
Nobody prevents you from using 'classic OTP codes' either. It is what enabled now as 'OTP' and there is no way to find out whether you are using a hardware token or a software one for TOTP/HOTP. So this is not changing at all.
On Tue, 2024-06-25 at 16:21 +0200, Vitaly Zaitsev via devel wrote:
On 25/06/2024 15:06, Stephen Gallagher wrote:
I am not a lawyer, but I would assume that if Fedora offered to provide such a token, it would be reviewed by Legal and provide some form of legally-binding assertion that we weren't sending out malicious devices.
Who can guarantee that these devices were not replaced during delivery?
In that situation, the provenpackagers would be making a three way decision: 1) Stop being a provenpackager, 2) buy their own token or 3) accept one provided by Fedora.
- Allow classic OTP codes.
I would prefer this one since I can use open source applications to generate these codes. I can't find any FIDO2 implementations that are completely open source which doesn't require proprietary technologies like TPM or SGX. Relying on a black box is not an option for me.
But, uh, any open source application you run is running on a hardware stack vastly more complicated and equally prone to trickery as a simple, cheap USB key.
Who guarantees that no component of your PC was replaced during delivery at any point along its supply chain? Who guarantees the bona fides of everyone who has ever contributed to its various firmwares and their updates, and all its components and *their* various firmwares and their updates? Same questions for your phone.
Really, if you're going to that level of paranoia, you should swear off electronic devices entirely.
In the world of what's realistically possible for Fedora, enabling 2FA and sending everyone a USB stick is a lot better than not enabling 2FA.
On Tue, Jun 25, 2024 at 10:32 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 25/06/2024 15:06, Stephen Gallagher wrote:
I am not a lawyer, but I would assume that if Fedora offered to provide such a token, it would be reviewed by Legal and provide some form of legally-binding assertion that we weren't sending out malicious devices.
Who can guarantee that these devices were not replaced during delivery?
In that situation, the provenpackagers would be making a three way decision: 1) Stop being a provenpackager, 2) buy their own token or 3) accept one provided by Fedora.
- Allow classic OTP codes.
I would prefer this one since I can use open source applications to generate these codes. I can't find any FIDO2 implementations that are completely open source which doesn't require proprietary technologies like TPM or SGX. Relying on a black box is not an option for me.
No one said otherwise. This hypothetical started from "what if we required physical tokens?", so I was noting the possibilities under that restriction.
On Tue, Jun 25, 2024 at 2:22 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
I would prefer this one since I can use open source applications to generate these codes. I can't find any FIDO2 implementations that are completely open source which doesn't require proprietary technologies like TPM or SGX. Relying on a black box is not an option for me.
Solokey and nitrokey both have open source firmware and (for solokey) even the kicad files to build the board itself.
On Tue, Jun 25, 2024 at 10:47:34AM +0200, Vitaly Zaitsev via devel wrote:
On 24/06/2024 23:38, Gary Buhrmaster wrote:
As I recall from a previous query, there are (around) 90 active proven packagers (and ~250 total who were in the PP group).
I think most privacy/security focused developers/maintainers won't plug USB tokens they get from random people on the Internet into their PC/laptop because it could be a BadUSB or something even worse.
The most common attack is when an attacker plants USB devices near the office of the company they want to attack. Connecting such devices is completely NO-GO.
I still cringe thinking of the Google Titan keys that's on every seat for the keynote of OSSNA 2023.
Best,
On 24/06/2024 03:42, Kevin Fenzi wrote:
You can enroll as many tokens as you like, so you can enroll one in a backup device or system in case you loose your primary token.
Backup codes must be generated when the user enables 2FA. They can later use these one-time codes to log in if they lose access to the OTP device.
Il 17/06/24 22:20, Zbigniew Jędrzejewski-Szmek ha scritto:
Proven packagers,
we changed [2,3] the FESCo policy document [1] for provenpackagers to say:
"Provenpackagers SHOULD have two-factor-authentication (2FA) enabled for their FAS accounts."
This is not enforced or checked, but please take steps to conform to the policy if you haven't yet.
[1] https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ [2] It's not visible on the web yet, because antora is doing its thing … slowly. [3] https://pagure.io/fesco/issue/3186
Zbyszek
Perhaps it's a stupid idea, but we already have ssh public keys stored in fas, would it be possible for fkinit to use the private key as second factor? That way, on a system which is considered secure (it has the private key stored in it) we would only require the user to enter the FAS password, while on a smartphone or a temporary device the password+otp would still be required.
Mattia
On Mon, 24 Jun 2024 at 10:39, Mattia Verga via devel devel@lists.fedoraproject.org wrote:
Il 17/06/24 22:20, Zbigniew Jędrzejewski-Szmek ha scritto:
Proven packagers,
we changed [2,3] the FESCo policy document [1] for provenpackagers to say:
"Provenpackagers SHOULD have two-factor-authentication (2FA) enabled for their FAS accounts."
This is not enforced or checked, but please take steps to conform to the policy if you haven't yet.
[1] https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ [2] It's not visible on the web yet, because antora is doing its thing … slowly. [3] https://pagure.io/fesco/issue/3186
Zbyszek
Perhaps it's a stupid idea, but we already have ssh public keys stored in fas, would it be possible for fkinit to use the private key as second factor? That way, on a system which is considered secure (it has the private key stored in it) we would only require the user to enter the FAS password, while on a smartphone or a temporary device the password+otp would still be required.
The corner case which makes this ineffective is 1. Various (proven) packagers like to copy their .ssh/ blindly to whatever systems they are running on. When I was in Systems Administration, I was regularly deleting private key files from various shared systems like people, bastion, etc. 2. Many of those private keys had no extra security on them (aka they were not locked) so they were pretty much open to anyone who could get them. 3. This happened enough over 12 years that I just realized many people don't see it as a problem.
While we could say 'oh that should be a reason to remove (proven) packager from someone' etc.. it puts sysadmin into being a hated nanny, and also only says 'oh you didn't do that to the Fedora systems, but the 800 other places you have placed them that we don't know about.'
This illustrates why "we can't have nice things". You start finding more and more 'common' cases which for X individual makes perfect sense to them and doesn't seem a problem, but overall makes everyone else's life hell when a problem occurs.
The same goes with keyfiles and such. We 'assume' that people keep them on a single laptop that is encrypted with backups that are encrypted.. but a significant minority either keep it on multiple shared systems, don't encrypt their drives, or have open backups somewhere. Eventually one of those gets cracked and you can end up with a chain of problems ranging anywhere from 'ooh all our systems have been crypto-blackmailed' to 'someone else pushed a commit which we didn't find until after a release and now 1 million user laptops are crypto-blackmailed.'
Mattia
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Il 24/06/24 16:54, Stephen Smoogen ha scritto:
The corner case which makes this ineffective is ...
Sure, system security is affected by user actions too, but considering that the alternative is to have the vast majority of users will continue ignoring 2FA because it is not handy, using something in the background which is already present on the PC without requiring more actions from the user I think it would encourage the adoption of 2FA.
I don't know if there's a way to use the ssh keys to act as second factor, or maybe the kerberos authentication process with just the plain password could be encapsulated in a session encrypted with the key pair?
Mattia
On Mon, Jun 24, 2024 at 02:39:13PM GMT, Mattia Verga via devel wrote:
Perhaps it's a stupid idea, but we already have ssh public keys stored in fas, would it be possible for fkinit to use the private key as second factor? That way, on a system which is considered secure (it has the private key stored in it) we would only require the user to enter the FAS password, while on a smartphone or a temporary device the password+otp would still be required.
No, it's not currently possible.
Rememver that we are using IPA as a backend, so it would need support in IPA.
How would it know you wanted to use a ssh key instead of otp? I suppose it would have to try all your keys and see if any worked? It likely would cause a lot of confusion also for those that didn't expect it.
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
kevin
On Mon, 24 Jun 2024 16:53:22 -0000 "Leigh Scott" leigh123linux@gmail.com wrote:
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
kevin
It isn't just once.
- kerberos
- Web login on infra, bugzilla, bodhi, devel list and accounts
If you do nightly shutdown you would need to enter it many times per week.
I do nightly shutdowns, don't use GNOME, but XFCE, and just do refresh the ticket before shutting down from a command line (unless I forget, but you can have a cronjob or another way) and the ticket stays valid for the whole week
Dan
-------- Messaggio originale -------- 24/06/24 18:53, Leigh Scott leigh123linux@gmail.com ha scritto:
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
kevin
It isn't just once.
- kerberos
- Web login on infra, bugzilla, bodhi, devel list and accounts
If you do nightly shutdown you would need to enter it many times per week.
Most of the web logins works with kerberos, you probably just need to set up your browser. See https://fedoraproject.org/wiki/Infrastructure/Kerberos#How_to_use_kerberos_a...
On Mon, Jun 24, 2024 at 04:53:22PM GMT, Leigh Scott wrote:
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
kevin
It isn't just once.
- kerberos
- Web login on infra, bugzilla, bodhi, devel list and accounts
If you do nightly shutdown you would need to enter it many times per week.
Are you not using sssd-kcm?
It stores your kerberos credentials so they survive reboots, etc.
All web logins in infra should honor your kerberos credentials, so if you have a valid ticket, it should just log you in without having to enter anything.
tickets are valid for 24hours and can be renewed for 1 week. (Either via gnome online accounts or just 'kinit -R')
kevin
On 24. 06. 24 19:13, Kevin Fenzi wrote:
tickets are valid for 24hours and can be renewed for 1 week. (Either via gnome online accounts or just 'kinit -R')
How do I do that?
$ fkinit ... all good ...
later:
$ klist Ticket cache: KCM:1000:..... Default principal: churchyard@FEDORAPROJECT.ORG
Valid starting Expires Service principal 24.6.2024 15:42:35 25.6.2024 15:42:21 krbtgt/FEDORAPROJECT.ORG@FEDORAPROJECT.ORG 24.6.2024 15:42:41 25.6.2024 15:42:21 HTTP/koji.fedoraproject.org@FEDORAPROJECT.ORG
$ kinit -R kinit: KDC can't fulfill requested option while renewing credentials
$ kinit -R churchyard@FEDORAPROJECT.ORG kinit: KDC can't fulfill requested option while renewing credentials
On Mon, Jun 24, 2024 at 1:30 PM Miro Hrončok mhroncok@redhat.com wrote:
On 24. 06. 24 19:13, Kevin Fenzi wrote:
tickets are valid for 24hours and can be renewed for 1 week. (Either via gnome online accounts or just 'kinit -R')
How do I do that?
$ fkinit ... all good ...
later:
$ klist Ticket cache: KCM:1000:..... Default principal: churchyard@FEDORAPROJECT.ORG
Valid starting Expires Service principal 24.6.2024 15:42:35 25.6.2024 15:42:21 krbtgt/FEDORAPROJECT.ORG@FEDORAPROJECT.ORG 24.6.2024 15:42:41 25.6.2024 15:42:21 HTTP/koji.fedoraproject.org@FEDORAPROJECT.ORG
$ kinit -R kinit: KDC can't fulfill requested option while renewing credentials
$ kinit -R churchyard@FEDORAPROJECT.ORG kinit: KDC can't fulfill requested option while renewing credentials
Seems like a bug on your end; I just tested it on my end and it worked just fine. Maybe your kerberos configuration is out of date? It's changed a few times over the years and if you ever made any manual edits, they may be overriding newer RPM content.
On Пан, 24 чэр 2024, Leigh Scott wrote:
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
kevin
It isn't just once.
- kerberos
- Web login on infra, bugzilla, bodhi, devel list and accounts
If you do nightly shutdown you would need to enter it many times per week.
Fedora's IPA deployment is set up to have individual Kerberos tickets be issued for 24 hours of validity (give or take) by default, with renewal period up to one week. Thus, a nightly shutdown should not be a problem if you are able to wake up that machine before 24 hour period expires.
Fedora uses KCM: credentials cache collection which helps to persist existing Kerberos tickets over reboots as well.
Aside from the accounts.fedoraproject.org, the rest can authenticate either with Kerberos directly or through Ipsilon IdP which takes Kerberos as well. In practice I have to re-login manually to Fedora services once a week, pretty much.
On Mon, Jun 24, 2024 at 12:54 PM Leigh Scott leigh123linux@gmail.com wrote:
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
kevin
It isn't just once.
- kerberos
- Web login on infra, bugzilla, bodhi, devel list and accounts
Not really an issue if you have GSSAPI set up on your system. Such as by installing fedora-chromium-config-gssapi (for Chrome/Chromium users) or by using Firefox which is set up for GSSAPI out-of-the-box.
If you do nightly shutdown you would need to enter it many times per week.
Not if you're using the Kerberos Credential Manager (KCM) for Kerberos (the default on Fedora for at least several years).
On 24/06/2024 18:26, Stephen Gallagher wrote:
Not really an issue if you have GSSAPI set up on your system. Such as by installing fedora-chromium-config-gssapi (for Chrome/Chromium users) or by using Firefox which is set up for GSSAPI out-of-the-box.
I've never seen Firefox use my kerberos ticket, it always asks me to login. That doesn't bother me though because I have my password manager readily available there, unlike at the command line.
Tom
Am 24.06.24 um 20:14 schrieb Tom Hughes via devel:
On 24/06/2024 18:26, Stephen Gallagher wrote:
Not really an issue if you have GSSAPI set up on your system. Such as by installing fedora-chromium-config-gssapi (for Chrome/Chromium users) or by using Firefox which is set up for GSSAPI out-of-the-box.
I've never seen Firefox use my kerberos ticket, it always asks me to login. That doesn't bother me though because I have my password manager readily available there, unlike at the command line.
Its long time ago that I used it. IIRC the website should be on the site-list of the FF config. The key is
network.negotiate-auth.trusted-uris
maybe also
network.negotiate-auth.delegation-uris
Access it via ui (about:config) or add a system-wide config.
On Mon, Jun 24, 2024 at 09:09:58PM GMT, Leon Fauster via devel wrote:
Am 24.06.24 um 20:14 schrieb Tom Hughes via devel:
On 24/06/2024 18:26, Stephen Gallagher wrote:
Not really an issue if you have GSSAPI set up on your system. Such as by installing fedora-chromium-config-gssapi (for Chrome/Chromium users) or by using Firefox which is set up for GSSAPI out-of-the-box.
I've never seen Firefox use my kerberos ticket, it always asks me to login. That doesn't bother me though because I have my password manager readily available there, unlike at the command line.
Its long time ago that I used it. IIRC the website should be on the site-list of the FF config. The key is
network.negotiate-auth.trusted-uris
maybe also
network.negotiate-auth.delegation-uris
Access it via ui (about:config) or add a system-wide config.
Just FYI, the default for network.negotiate-auth.trusted-uris these days is:
https://
ie, any https uri.
kevin
On Mon, 2024-06-24 at 21:09 +0200, Leon Fauster via devel wrote:
Am 24.06.24 um 20:14 schrieb Tom Hughes via devel:
On 24/06/2024 18:26, Stephen Gallagher wrote:
Not really an issue if you have GSSAPI set up on your system. Such as by installing fedora-chromium-config-gssapi (for Chrome/Chromium users) or by using Firefox which is set up for GSSAPI out-of-the-box.
I've never seen Firefox use my kerberos ticket, it always asks me to login. That doesn't bother me though because I have my password manager readily available there, unlike at the command line.
Its long time ago that I used it. IIRC the website should be on the site-list of the FF config. The key is
network.negotiate-auth.trusted-uris
maybe also
network.negotiate-auth.delegation-uris
NEVER set this, it causes your browser to give away your Kerberos TGT, something you DO NOT WANT to do, ever!.
HTH, Simo.
Am 24.06.24 um 22:29 schrieb Simo Sorce:
On Mon, 2024-06-24 at 21:09 +0200, Leon Fauster via devel wrote:
Am 24.06.24 um 20:14 schrieb Tom Hughes via devel:
On 24/06/2024 18:26, Stephen Gallagher wrote:
Not really an issue if you have GSSAPI set up on your system. Such as by installing fedora-chromium-config-gssapi (for Chrome/Chromium users) or by using Firefox which is set up for GSSAPI out-of-the-box.
I've never seen Firefox use my kerberos ticket, it always asks me to login. That doesn't bother me though because I have my password manager readily available there, unlike at the command line.
Its long time ago that I used it. IIRC the website should be on the site-list of the FF config. The key is
network.negotiate-auth.trusted-uris
maybe also
network.negotiate-auth.delegation-uris
NEVER set this, it causes your browser to give away your Kerberos TGT, something you DO NOT WANT to do, ever!.
Good catch. Its seems my memory recall was not reliable, my bad.
-------- Messaggio originale -------- 24/06/24 18:21, Kevin Fenzi kevin@scrye.com ha scritto:
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
Once a week? When I get a kerberos ticket with fkinit it expires after 24h. Is there a setting to change somewhere to make it last a week?
On Mon, 24 Jun 2024 17:11:07 +0000 Mattia Verga via devel devel@lists.fedoraproject.org wrote:
-------- Messaggio originale -------- 24/06/24 18:21, Kevin Fenzi kevin@scrye.com ha scritto:
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
Once a week? When I get a kerberos ticket with fkinit it expires after 24h. Is there a setting to change somewhere to make it last a week?
just refresh it with "kinit -R", the ticket is renewable for a week
Dan
On Mon, Jun 24, 2024 at 1:11 PM Mattia Verga via devel devel@lists.fedoraproject.org wrote:
-------- Messaggio originale -------- 24/06/24 18:21, Kevin Fenzi kevin@scrye.com ha scritto:
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
Once a week? When I get a kerberos ticket with fkinit it expires after 24h. Is there a setting to change somewhere to make it last a week?
You get a TGT that is valid for 24 hours but can be used to renew (get a new TGT by using the old one) for up to a week. You just need to do the equivalent of `kinit -R` which GNOME's tool can be configured to do for you.
On Mon, Jun 24, 2024 at 05:11:07PM +0000, Mattia Verga via devel wrote:
-------- Messaggio originale -------- 24/06/24 18:21, Kevin Fenzi kevin@scrye.com ha scritto:
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
Once a week? When I get a kerberos ticket with fkinit it expires after 24h. Is there a setting to change somewhere to make it last a week?
Tickets expire after 24 hours, but before expiry, it is possible to request renewal eg
kinit <fas-user-name>@FEDORAPROJECT.ORG -R
this renewable won't prompt for credentials. IIUC, it basically just validates that your krb account hasn't been disabled by the server admin.
klist will tell you the upper limit on renewals before you must fully re-authenticate, and in Fedora it appears to be 7 days.
Note, you *MUST* renew it before it expires, as you can't renew an expired ticket, even if it were still within the renewal lifetime.
Incidentally there's not particularly any need to use fkinit, as it is just a thin wrapper around kinit. It avoids the need to type the "@FEDORAPROJECT.ORG" part of your krb account, and for some reason forces use of the "FILE" credential cache, overriding the system default. The latter feels dubious to me but perhaps there's some good reason for it ?
With regards, Daniel
On Mon, Jun 24, 2024 at 1:30 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Mon, Jun 24, 2024 at 05:11:07PM +0000, Mattia Verga via devel wrote:
-------- Messaggio originale -------- 24/06/24 18:21, Kevin Fenzi kevin@scrye.com ha scritto:
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
Once a week? When I get a kerberos ticket with fkinit it expires after 24h. Is there a setting to change somewhere to make it last a week?
Tickets expire after 24 hours, but before expiry, it is possible to request renewal eg
kinit <fas-user-name>@FEDORAPROJECT.ORG -R
this renewable won't prompt for credentials. IIUC, it basically just validates that your krb account hasn't been disabled by the server admin.
klist will tell you the upper limit on renewals before you must fully re-authenticate, and in Fedora it appears to be 7 days.
Note, you *MUST* renew it before it expires, as you can't renew an expired ticket, even if it were still within the renewal lifetime.
Incidentally there's not particularly any need to use fkinit, as it is just a thin wrapper around kinit. It avoids the need to type the "@FEDORAPROJECT.ORG" part of your krb account, and for some reason forces use of the "FILE" credential cache, overriding the system default. The latter feels dubious to me but perhaps there's some good reason for it ?
It's required if you are using 2FA because it handles the fact that you need to do TWO kinit actions, one to set up the anonymous pre-authentication channel and another to actually send the credentials. I wrote fkinit to abstract those details for Fedora users since it's subtle and easy to get wrong. Also, it doesn't use the FILE credential cache for the final credentials, it uses whatever your system default is. It only uses FILE: to set up the preauthentication channel.
On Mon, Jun 24, 2024 at 01:33:52PM -0400, Stephen Gallagher wrote:
On Mon, Jun 24, 2024 at 1:30 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Mon, Jun 24, 2024 at 05:11:07PM +0000, Mattia Verga via devel wrote:
-------- Messaggio originale -------- 24/06/24 18:21, Kevin Fenzi kevin@scrye.com ha scritto:
I personally don't see why entering a otp once a week is such a burden... but it does seem to be. ;(
Once a week? When I get a kerberos ticket with fkinit it expires after 24h. Is there a setting to change somewhere to make it last a week?
Tickets expire after 24 hours, but before expiry, it is possible to request renewal eg
kinit <fas-user-name>@FEDORAPROJECT.ORG -R
this renewable won't prompt for credentials. IIUC, it basically just validates that your krb account hasn't been disabled by the server admin.
klist will tell you the upper limit on renewals before you must fully re-authenticate, and in Fedora it appears to be 7 days.
Note, you *MUST* renew it before it expires, as you can't renew an expired ticket, even if it were still within the renewal lifetime.
Incidentally there's not particularly any need to use fkinit, as it is just a thin wrapper around kinit. It avoids the need to type the "@FEDORAPROJECT.ORG" part of your krb account, and for some reason forces use of the "FILE" credential cache, overriding the system default. The latter feels dubious to me but perhaps there's some good reason for it ?
It's required if you are using 2FA because it handles the fact that you need to do TWO kinit actions, one to set up the anonymous pre-authentication channel and another to actually send the credentials. I wrote fkinit to abstract those details for Fedora users since it's subtle and easy to get wrong. Also, it doesn't use the FILE credential cache for the final credentials, it uses whatever your system default is. It only uses FILE: to set up the preauthentication channel.
Ah that's interesting to know, thanks!
With regards, Daniel
On Пан, 24 чэр 2024, Kevin Fenzi wrote:
On Mon, Jun 24, 2024 at 02:39:13PM GMT, Mattia Verga via devel wrote:
Perhaps it's a stupid idea, but we already have ssh public keys stored in fas, would it be possible for fkinit to use the private key as second factor? That way, on a system which is considered secure (it has the private key stored in it) we would only require the user to enter the FAS password, while on a smartphone or a temporary device the password+otp would still be required.
No, it's not currently possible.
Rememver that we are using IPA as a backend, so it would need support in IPA.
How would it know you wanted to use a ssh key instead of otp? I suppose it would have to try all your keys and see if any worked? It likely would cause a lot of confusion also for those that didn't expect it.
In order to have any specific authentication logic added to Kerberos, one needs:
- design a new pre-authentication method
- review the proposal and its security properties through IETF and register in Kerberos parameters's IANA registry for 'Pre-authentication and Typed Data' [1]
- implement new pre-authentication method. We did this recently (2020-2023) for PA-REDHAT-IDP-OAUTH2 [3] and PA-REDHAT-PASSKEY [2] in SSSD project
- implement support for new pre-authentication method in FreeIPA ([3] and [4] for idp and passkey methods).
The whole process can easily take couple years.
[1] https://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xht... [3] https://sssd.io/design-pages/passkey_kerberos.html [4] https://freeipa.readthedocs.io/en/latest/designs/external-idp/external-idp.h... [5] https://freeipa.readthedocs.io/en/latest/designs/passkeys.html