Remove Kerberos support

[michaelrsweet]

Remove Kerberos support from cupsd and libcups.

[kucharskim]

Out of curiosity, why?

[michaelrsweet]

@kucharskim Kerberos is obsolete and has been a constant source of pain over the years for printing - see my OpenPrinting Summit slides over the last five years for the details.

Microsoft has adopted OAuth 2.0 for Active Directory, which is also where IPP and CUPS are moving.

[DemiMarie]

@kucharskim Kerberos is obsolete and has been a constant source of pain over the years for printing - see my OpenPrinting Summit slides over the last five years for the details.

Microsoft has adopted OAuth 2.0 for Active Directory, which is also where IPP and CUPS are moving.

This confuses me. Active Directory Domain Services is built around Kerberos, as is FreeIPA. Are you referring to Azure AD or Active Directory Federation Services?

[michaelrsweet]

@DemiMarie Yes, all of Microsoft's new technologies...

[DemiMarie]

@michaelrsweet That is a valid point, though there will need to be a way to provision access tokens (from a central management solution, for example) without requiring a browser (my main problem with OAuth).

[ensc]

Yes, all of Microsoft's new technologies...

who cares about Microsoft?

Atm, I login on my machine and get a krb5 ticket over pam_sss. Formerly I was immediately able to print with lpr, but now (without gssapi support) I am asked for a password.

What is the timeline for the complete removal of gssapi? Will oauth2 related infrastructure commonly available at this time? E.g. will kerberos servers in major enterprise linux distributions provide support for it? Will other services which are realised by gssapi (e.g. imap, various web services, nfs4) ported to this authentication method?

[michaelrsweet]

@ensc WRT Kerberized printing, Windows SMB is the 99.999% use case. In the post-driver world, a printer application running in the user session handles all of the Kerberos needed.

CUPS + Kerberos has always been a hack, and every few years something breaks with one of the two Kerberos implementations or Samba that we have to deal with. The HTTP authentication method we use ("Negotiate") is based on a Microsoft experimental RFC and the hacks that we use to get a current, valid auth ticket from the KDC (namely, to run in the user's login session) doesn't actually require that CUPS directly supports Kerberos, just that it knows to run the SMB backend as the login user.

The timeline is documented (roughly) on the CUPS wiki. The plan is to introduce OAuth support in CUPS 2.5 (probably 2023 now) and remove Kerberos/GSSAPI support in CUPS 3.0 (2024-2025) so that there is some overlap. And knowing the LTS/enterprise Linux distros, we'll still be seeing them ship CUPS 2.x for a very long time anyways.

I don't know whether you will see a hybrid Kerberos KDC/OAuth authorization server solution. My personal experience with Kerberized NFS has been all bad (network outages and congestion cause mounts to go FUBAR), and I honestly haven't had any experience using IMAP, SMTP, etc. with Kerberos - usually Kerberos was used for SSO to the network/VPN, and then separate credentials were used for email.

OAuth + IMAP/SMTP is a supported thing already, but for network file systems you'd probably need to use OAuth + HTTP (WebDAV) or SMB.

[ensc]

In the post-driver world, a printer application running in the user session handles all of the Kerberos needed.

This means, lpr will work as before? E.g. no prompt for password and reuse of existing credentials?

The HTTP authentication method we use ("Negotiate") is based on a Microsoft experimental RFC

fwiw, technique behind ("Negotiate") existed far before Microsoft's RFC. E.g. mod_auth_kerb is dated back to 2002 at least.

And knowing the LTS/enterprise Linux distros, we'll still be seeing them ship CUPS 2.x for a very long time anyways.

This means, there will be no SSO printing solution for desktop linux for some years because print servers (operated by enterprise distros which do not support OAuth yet) can not be used by clients which speak OAuth only.

My personal experience with Kerberized NFS has been all bad

this has nothing todo with krb5 but by things like firefox which place their sqlite3 databases in /home. NFS4 file locks usually fail to recover after several hours of standby/suspend. KRB5 NFS itself works perfectly.

you'd probably need to use ... SMB

SMB is one of the things which is really want to avoid...

[michaelrsweet]

@ensc Yes, lpr will work as before.

[michaelrsweet]

This is now done in libcups. Kerberos code will not be introduced in the new cups-sharing server.