Hacker News Reader

Comment by project2501a | Hacker News Reader

Where do I find money to fund my rewrite of Kerberos 5 in Rust, removing the dumb options and Kerberos 4 compatibility and eventually create Kerberos 6 + AD that will solve a metric buttload of issues in Linux and knock a major peg of MS off?

View on HN

Kerberos solves the problem that doing public key authentication is slow on a i386

kerberos solves the problem that you can have short one time tokens using your password.

Add public key infrastructure support, make ldap the default store and you got AD. Even better, you can throw all the OAuth crap down the drain.

now, starting services with a password becomes an issue of booting the machine.

No one would build KRB4/5 today, it makes no sense. It's only advantage over an X.509 cert based system is speed on really really slow CPUs.

That doesn't seem right to me, assuming you still want the paradigm of one-time principal-to-domain authentication with just-in-time principal-to-resource authentication. While I think you could probably use x509 certs to streamline and modernize the ticket-granting-and-session-key dance, you'd still be doing a lot of the same high-level things.

Depending on the use-case, Kerberos (/this imagined x509 Kerberos) or Oauth2 still seems suitable for single-authenticator/multiple-services paradigm.

Ask IBM/RedHat. They did a lot of foundational work with SSSD (aka "too many 'S' D").

Kerberos is not a great protocol, though.

> Kerberos is not a great protocol

Understatement of the week

sssd is a dogpile of dogcrap. I have 15 tickets on github about fixing their manpages.

and you really need to read the kerberos book before picking up sssd.

Ultimately Kerberos is used to authenticated basically everything in a Windows on-prem environment and in a way that is largely transparent to the user. Silent SSO is a very nice feature. Even if you're doing OIDC or SAML, those protocols do not define what is actually performing authentication at the IdP which, again, ultimately ends up being Kerberos if you're people are on-prem. So whatever your feelings are about Kerberos as a protocol, it doesn't matter if that's what Windows uses. And again, it cannot be obsoleted by other protocols. Even if you're using a newer fido thing like passkeys or client certs or whatever, ultimately the device has to be authenticated to get that passkey or cert or whatever it is installed into the authenticator app of the device. So Kerberos is king on prem. MIT Kerberos on Linux is not really compatible with Windows Kerberos in ways that cause problems that are not solved by re-writing Kerberos in another language. More important issues have to do with sharing credentials and getting trust info and other such things.

> Ultimately Kerberos is used to authenticated basically everything in a Windows on-prem environment and in a way that is largely transparent to the user. Silent SSO is a very nice feature.

When it works. And when it doesn't work (which is most of the time if you're outside of corporate LAN) you simply can't debug what's happening.

> MIT Kerberos on Linux is not really compatible with Windows Kerberos

It actually is! Long, long time ago I managed to join Windows into a pure Kerberos domain. Everything worked, including things like GSSAPI authentication in Putty or MySQL. It involved some `ksetup.exe` incantations, I think this guide might be still relevant: https://docs.oracle.com/cd/E19316-01/820-3746/gisqf/index.ht...

Of course, there was no group synchronization (because no AD).

That was about 20 years ago. Back then, I was working on helping companies migrate to Linux, and I toyed with an idea of having a background service to periodically sync groups from the Linux SMB server with the local users.

Memory safety or type safety are the least of Kerberos' issues. The protocol itself is fundamentally flawed.

What issues on Linux would this actually solve?

simplify gssapi, for one. single authentication and authorization: submit on slurm? ask kerberos + ldap. can i upload to this service? as kerberos + ldap. Policies applied on this computer? ask kerberos + ldap

i may be naive a bit, i'll accept that, but I really like how AD works (which is essentially kerberos + ldap)

I tried to set up network file sharing with NFS the other day and it was like pulling teeth. You need Kerberos if you want to map user names instead of user ids and still have some security.

Ultimately I gave up and used samba instead, but it does seem like there's a big gap in linux offerings for "home/small business network file sharing" with shared auth

sshfs doesn't work for you?

It's a great option to have, but ultimately it's at-best pretty slow.

It's for a drive holding primarily media files, my experiences with sshfs have been that it is slow. My goal here was to have a network drive mounted on login for two different accounts on my linux desktop, and the same users (my partner and I) on different accounts (because apple) on two different macbooks. It's a typical home network, with a firewall, so the extra security of ssh would be nice but isn't really critical for us - any malware on the computers we use would already have network access and our ssh keys.

I also want to share the home printer/scanner, which I believe samba can do, but obviously sshfs won't. Side note - I would love to see a standard protocol and server for a 3d printer. We have a Bambu and the software is... alright... but doesn't play nice sharing an account between computers.

Ultimately I set up samba on the server, with mapped users, and a line in fstab on the desktop. Plain old NFS might have worked for the desktop but the users don't have the same UIDs between the desktop and the server and... reconciling that seemed painful.

I did try to make kerberos work with NFS for a few days but the experience was akin to staring into the sun.

Did you respond to the wrong comment?

Reply on news.ycombinator.com