IAKERB Starter Credentials Solution

[Nico Williams]

On Sat, Apr 26, 2025 at 03:33:10PM -0400, Michael B Allen wrote:
> Yeah, when trying to do iakerb_gss_init_sec_context and there's no TGT (or
> Ticket), then just returning an error is reasonable.
> 
> Applications would have to add new code to set a callback or catch an error
> so neither way is going to be transparent.

Putting up a dialog like OS X used to do is doable, but nowdays
considered a bad UX by Apple and others.  I've never seen that in action
so I can't speak from experienced.

> But of course applications are not going to use the gss_acquire_cred_*
> functions (and they probably should not).

Well, if they are the sort of application for which IAKERB to acquire a
TGT is desirable then yes, they would, else no, they wouldn't.

And PKINIT would just work if either there is no need to unlock a
smartcard, the user can respond to an error by unlocking the smartcard,
the user can be given feedback that they need to unlock the smartcard,
or a dialog pops up about it.  Though, again, all of these are bad UX,
though also the only UX if you really have to have non-interactive apps
be able to acquire credentials.

Also, everything is easier in environments where you only have one
principal for the user, in one realm, and cross-realm trusts can take
care of the rest.  Then you can have the OS cache the user's password
(unless they need to be prompted to unlock a smartcard or furnish a
TOTP).

> When the user gets an error, they will have to use some utility that knows
> to use gss_acquire_cred_with_password with IAKERB to some IAKERB-aware
> service.
> Then, with a TGT in their ccache, the application should now init IAKERB
> successfully.
> 
> Correct?

But that utility might as well be any app that knows it's likely to be
used in an IAKERB-requiring context _and_ interaction is possible.

E.g., RDP, SSHv2 w/ GSS KEYS/userauth, any remote access system like
that.

Filesystem protocols are harder to do initial credential acquisition in
because if the application is just a typical POSIX app then there is no
connection to the place (typically a gssd-type daemon) where the GSS-API
is invoked.  Only having a dialog popped up by that gssd daemon is going
to work in such cases.

The filesystem issues would apply to IPsec/IKEv2 if IKEv2 supported GSS,
or if we had a variant of KINK that supported GSS, in cases where the
IPsec policy that needs credentials can be triggered by anything other
than interactive tunnel up events (e.g., transport mode SAs, though I
understand that's considered obsolete now).  But the RAS case would
apply to tunnel mode IPsec for VPN, again if IPsec supported GSS (which
it does not).

Basically, the idea of IAKERB for initial credential acquisition is just
problematic because of the need for an application protocol where the
initiator is interactive.  To make it blindingly obvious: credential
acquisition is inherently an interactive process, therefore that IAKERB
usage will only really work for interactive apps.

For RDP IAKERB is _great_, and it's MSFT's answer to how to replace
NTLM.  Ideally something like TLS as the transport, w/ GSS-API w/ IAKERB
for userauth, with channel binding to TLS, and interaction as needed.

>From an enterprise perspective the RDP case is very useful because you
get to allow analog-only holes for exfiltration, and you greatly reduce
the attack surface area.

It's possible that RDP or similar will be the only real use cases for
IAKERB.

Nico
--