Tune the kerberos validity windows to better accommodate a low-friction experience for contributors. There are two windows that make sense to tune.
The current 24 hour validity window feels like it'd make the most sense. People generally start their day at the same time and the likelihood they will be active during that time to be able to re-authenticate seems ideal. In combination with a 7 day fixed renewal window, it makes things feel like a work week. Makes sense.
The caveat is you need to have a valid TGT to be able to renew. So practically, we have a 24 hour window. If you have automated the renewal and are active when the renewal is detected to need to happen, this can feel like a 7 day authentication window.
I propose we set the validity of TGTs to 7 days.
If there are concerns with having cached valid credentials for such a long window, alternatively consider 72 hours (3 days).
If credentials are required to expire ~daily, please consider 28 hours validity as not everyone starts each day at the same exact time.
Please also keep in mind that even when there are local cached credentials, they are validated by the KDC and can be instantly invalidated if required.
The current 7 day renewal window allows for keeping a fresh ticket for up to 7 days after you first get a TGT. The renewal needs to take place with a currently valid TGT with something like kinit -R or other tooling. Gnome Online Accounts (GOA) can do this automatically.
kinit -R
The caveat is that the renewal window is a fixed window. It does not get extended when doing a renewal. It is a ceiling to the amount of time before re-authentication is forced.
I propose we set the renewal window to 30 days.
Regarding scraping of local cached credentials, the current default is to use Kerberos Cache Manager (KCM) to protect the cache. KCM is encrypted at a system level and the key is stored on-disk readable by root. KCM will not protect against an offline attack. There are simple techniques to read this cache if root level access is available.
Full disk encryption (FDE) helps mitigate this, but only if a LUKS passphrase is set. I expect a TPM2 managed FDE impacts this protection.
Metadata Update from @phsmoura: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: low-gain, low-trouble, ops
So, this is historical, we just took the same settings used by Red Hat at the time.
I don't want to change this without input from infosec folks.
Perhaps we could make it more visible how to automate renewals if folks want to do that (GOA does that, but it's a bit confusing if you have otp enrolled).
I think 30days is... way too long, but thats just my opinion.
I'll try and get some more input on this...
Well, currently we never have to reauthenticate, because as you've mentioned gnome-online-accounts currently handles reauthentication and can do so indefinitely so long as no OTP is required.
I would require reauthentication once per year, if ever. Reauthenticating somebody who has already previously authenticated does have some security value, but that value needs to be weighed against annoyance. If we have to go into gnome-online-accounts on a regular basis to deal with authentication errors caused by the OTP, that's going to be annoying.
(Red Hat is actually the gold standard for what not to do. E.g. https://issues.redhat.com and https://bugzilla.redhat.com both require that I reauthenticate every single time I close my browser. There is zero security benefit to such an aggressive policy, and it discourages participation on our issue trackers.)
I realize this post may elicit some groans and curses, but I remember reading in some of the security guidance that was authored by Mike McGrath that a lot of the settings he suggested had roots in NIST guidance. I work with DISA STIGs, which all trace back to controls listed in NIST SP 800-53 (currently at rev 5). The information I'm sharing here is all published at https://public.cyber.mil and (should be) public knowledge.
The group of folks who wrote the RHEL STIGs (Red Hat, DISA, and some others) only give guidance to "not enable Kerberos unless you have a documented need, and if you do enable it, it had better be FIPS-compliant." So now, after one line in a memo, you have systems without much guidance using Kerberos because they're integrated with Active Directory somehow.
We get most of our Kerberos-related guidance from the MS Windows Server STIG, and the ticket lifetimes are MUCH shorter than 30 days.
(From the MS Windows Server 2022 STIG...)
NIST SP 800-53 Rev 5 :: IA-2 (8) Implement replay-resistant authentication mechanisms for access to privileged accounts and/or non-privileged accounts.
NIST SP 800-53 REV 5 :: IA-7 Implement mechanisms for authentication to a cryptographic module that meets the requirements of applicable laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication.
As I understand it, this means my TGTs live for 10 hours at a time, and I can renew them for 7 days. My service tickets (access a given resource, eg; access a file share, log into a website, etc.) are also only good for 10 hours. I'm also guessing, based on these settings, that if we had a laptop go off for telework or something that it'd need to be able to talk to the domain within 7 days or "fall off" as those poor Windows systems are prone to do.
Anyways, I'm not proposing that we adopt DISA's guidance in this regard, but I wanted to share it for reference as some kind of baseline for comparison.
Agreed. I'm raising this as a contributor UX issue and do want to make sure it's secure.
This would be great. Also, including an update to fkinit that would automatically renew if you have an eligible TGT would be smart. Extending the validity window and automatically renewing, for me, would likely cover most of my workflows.
fkinit
This concern is valid. I wonder how different it is to contributor SSH keys? A contributor can do alot more with a valid kerberos ticket than just a ssh key... but is still able to do alot and they never expire. SSH keys also have no way to enforce a passphrase.
What I'm trying to raise is that functionally the current TGT is 24 hours when TOTP is enabled. Practically, and if you know how to do it, it could be 7 days.
V-254389 User ticket renewal max lifetime: 7 days: Sounds good if when I go to authenticate it's a step-up authentication and all I need to do is enter a valid TOTP. V-254388 User ticket lifetime: 10 hours: would require automatic refresh that doesn't need user input.
V-254389 User ticket renewal max lifetime: 7 days
V-254388 User ticket lifetime: 10 hours
For non-TOTP authentication, it seems like it's easy to just let GOA (or other) automation keep everything fresh until the ceiling (max lifetime.) Due to non-TOTP, all that needs to happen is unlocking of the keychain... and as mentioned already... that means perpetual authentication. With a saved keychain password for the realm, this is perpetual and there is never a step-up authentication.
The challenge here is that for the local TGT to be invalidated requires the account in FAS to be disabled after the ticket is issued. A shorter period is smart. The account is able to be left active and all issued TGTs are invalidated automatically.
Obviously this only applies when TOTP is enabled or an encrypted keychain is used for the GOA/etc automatic renewal.
Log in to comment on this ticket.