[39516] in Kerberos
Re: IAKERB Starter Credentials Solution
daemon@ATHENA.MIT.EDU (Nico Williams)
Sat Apr 26 20:47:33 2025
Date: Sat, 26 Apr 2025 19:46:13 -0500
From: Nico Williams <nico@cryptonector.com>
To: Michael B Allen <ioplex@gmail.com>
Cc: kerberos <kerberos@mit.edu>
Message-ID: <aA1+VaGCHTYgTTjK@ubby>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAGMFw4gHvZ9nRLx1Q=sWCXagHXEi_XJvMkczZK2hy62Vq9aKzg@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Sat, Apr 26, 2025 at 07:32:35PM -0400, Michael B Allen wrote:
> Ideally there should be some unix socket service that just processes gss
> tokens.
That's gssd, variously named.
> Being a separate process it can do crypto without exposing base keys and
> even store the plaintext password (encrypted of course) used to login to
> the device and achieve true SSO.
> It would provide persistence so that transient processes can get creds
> without prompting.
> It would normalize the prompting.
If you want apps not to see even passwords, then you can only do this by
having a visual desktop and dialog pop-ups _or_ (and/or) the OS can
use the login and screen unlock interactions + caching.
> Presumably no such service exists so what can I do?
No, it does. It's called gssd, or rpc.gssd, etc.
> You seem to be suggesting that each of potentially multiple applications
> should be able to trap on an error, prompt for initial credentials (in
> whatever way) and then do an a-typical gss_acquire_cred_with_password with
> just the IAKERB mech.
No, I'm suggesting that only the login screen, screen unlock screen, and
RDP-like apps should bother with interaction for initial credential
acquisition.
Nico
--
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
