From Newsgroup: comp.protocols.kerberos

I'm drilling down into IAKERB right now and I had a thought ...

Unlike regular Kerberos where the initiator has a ticket from the ccache already acquired in a separate authentication step, IAKERB needs "starter" credentials like a principal name and plaintext password.

So how does an IAKERB initiator get the client principal name and password?

One method might be to invoke a callback from within gss_init_sec_context
that would trigger the user to be prompted for plaintext creds.
While this is closer to what I think is ideal, in practice, the
implementation is non-trivial.

Another method would be to modify kinit to optionally authenticate with an IAKERB-aware service and cache the resulting TGT in the usual way.

More specifically, add an option to krb5.conf like:

[libdefaults]
iakerb_idp = https://idp1.mega.corp/do/iakerb

Now run kinit as usual which uses the supplied plaintext creds to do
Negotiate auth with the specified URL and stuff the acquired TGT into the ccache.

Now IAKERB can init elsewhere without starter creds or problematic
prompting.

Although, the current MIT Kerberos code is not quite right for this because
it seems SPENGO can't use IAKERB as a submech and there would need to be a callback in iakerb_gss_init_sec_context to reach back into kinit and pickup
the plaintext creds.

Mike
--
Michael B Allen
Java AD DS Integration
https://www.ioplex.com/ <http://www.ioplex.com/>
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Sat, Apr 26, 2025 at 10:39:02AM -0400, Michael B Allen wrote:

I'm drilling down into IAKERB right now and I had a thought ...

Unlike regular Kerberos where the initiator has a ticket from the ccache already acquired in a separate authentication step, IAKERB needs "starter" credentials like a principal name and plaintext password.

So how does an IAKERB initiator get the client principal name and password?

See:

- gss_acquire_cred_with_password() / gss_add_cred_with_password()

- gss_acquire_cred_from()

The problem with the above is that there is no way to interactively find
out what the user must supply, but otherwise they work. And if the only
thing the user needs besides a password is a one-time password or a
smartcard then we could have new error codes by which to indicate this
so the application can prompt for those and retry, so the lack of
interactivity is not a big deal.

OS X used to have a dialog pop-up for such things, but that did not work
well.

Rather than a callback I'd prefer to have a new major status code that indicates that the application must call a function to extract the
prompts / supply answers, and this would use the partial security
context handle to sequence things.

Nico
--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Sat, Apr 26, 2025 at 12:36rC>PM Nico Williams <nico@cryptonector.com>
wrote:

Rather than a callback I'd prefer to have a new major status code that indicates that the application must call a function to extract the
prompts / supply answers, and this would use the partial security
context handle to sequence things.

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.
But of course applications are not going to use the gss_acquire_cred_* functions (and they probably should not).
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?
Mike
--
Michael B Allen
Java AD DS Integration
https://www.ioplex.com/ <http://www.ioplex.com/>
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

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
--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Sat, Apr 26, 2025 at 6:02rC>PM Nico Williams <nico@cryptonector.com> wrote:

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 ...

I like to think about what is ideal, and then I do what I can.
Ideally there should be some unix socket service that just processes gss tokens.
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.
This is consistent with what Windows does.
Windows prompts with "Entry your network credentials" and it has the
plaintext password (encrypted of course) so presumably it will skip
prompting for IAKERB completely.
Presumably no such service exists so what can I do?
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.
Kerberos is hard enough to debug as it is.
Honestly, I don't see applications actually making those changes anyway.
Until there's a host service to centrally handle all-things gss and know
how to properly and consistently prompt, I would rather apps just return an error "No credentials, get a TGT and try again".
Of course again, for kinit or whatever login app to get a TGT with IAKERB
it needs to auth to an IAKERB-aware service. HTTPS seems to be the obvious choice IMO.
As a side benefit, because it's authenticated with mutual, there is an opportunity to install an otherwise untrusted CA certificate into /etc/pki/ca-trust/source/ or wherever for the host.
Mike
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

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
--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On 4/26/25 10:39, Michael B Allen wrote:

Another method would be to modify kinit to optionally authenticate with an IAKERB-aware service and cache the resulting TGT in the usual way.

More specifically, add an option to krb5.conf like:

[libdefaults]
iakerb_idp = https://idp1.mega.corp/do/iakerb

If the goal is simply to tunnel an AS/TGS exchange over https using a
web server set up for that purpose, I think MS-KKDCP is a more natural
fit than IAKERB. See:

https://web.mit.edu/kerberos/krb5-latest/doc/admin/https.html
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kkdcp/ --- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Sun, Apr 27, 2025 at 1:48rC>AM Greg Hudson <ghudson@mit.edu> wrote:

On 4/26/25 10:39, Michael B Allen wrote:

Another method would be to modify kinit to optionally authenticate with

an

IAKERB-aware service and cache the resulting TGT in the usual way.

More specifically, add an option to krb5.conf like:

[libdefaults]
iakerb_idp = https://idp1.mega.corp/do/iakerb

If the goal is simply to tunnel an AS/TGS exchange over https using a
web server set up for that purpose, I think MS-KKDCP is a more natural
fit than IAKERB. See:

https://web.mit.edu/kerberos/krb5-latest/doc/admin/https.html

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kkdcp/

Yes!
This is better. It's basically the same just more direct and apparently
already implemented.
Will the MITK gss initiators use the HTTPS proxy to get TGS tickets too?
That would dodge IAKERB entirely.
Thanks,
Mike
--
Michael B Allen
Java AD DS Integration
https://www.ioplex.com/ <http://www.ioplex.com/>
--- Synchronet 3.21d-Linux NewsLink 1.2