Re: [kitten] [EXTERNAL] Re: Windows Intent to revive and implement IAKerb draft-ietf-kitten-iakerb-03

[Nico Williams <[e-mail]>]

On Fri, Feb 17, 2023 at 07:04:02PM +0000, Steve Syfuhs (AP) wrote:
> As for why we care - Luke is spot on. NTLM deprecation. Despite the
> good intentions of our corporate overlords over the last few years,
> Kerberos ain't going away anytime soon, and with that NTLM certainly
> isn't going away without us giving it a good shove. So...

I'd like for something to be able to replace Kerberos, but we shouldn't
have that discussion in this thread, so I'll shut up about that :)

> 52% of NTLM usage is because of hardcoding the package in GSS or SSPI.
> We know why this happens some of the time - lack of visibility into
> outer negotiation processes like HTTP - and sometimes just lack of
> knowledge on the implementers part. Internally, we're working with the
> top offenders to move them to SPNego. Once that happens we predict it
> will increase line of sight issues a fair bit, though relative to the
> rest of the fallback reasons.

So you could lie to the app and say "you got NTLM" but actually do
IAKERB?  Seems reasonable to me; NTLM must die.

> 100% - 52% - 7% != 0%, so obviously there would have to be some other
> things going on to kill NTLM. We have a plan, but aren't ready to talk
> about it yet. Suffice to say IAKerb is an integral part of it.

Any idea what the remaining 41% are about?

The one thing I'll say is that when MIT enabled IAKERB by default in
SPNEGO that broke things for users.  See
https://krbdev.mit.edu/rt/Ticket/History.html?id=8021 whose description
says:

| We implemented IAKERB in 1.9. SPNEGO automatically tries all
| mechanisms except for SPNEGO itself, so it tries IAKERB after regular
| krb5. In practice, this is rarely useful and often serves to
| complicate scenarios which would otherwise be simple. For instance, if
| the user has credentials but we cannot get a service ticket for the
| target host, we try IAKERB instead of failing locally; most of the
| time this is unnecessary work and obscures the resulting error
| message.

That captures the issues I saw exactly.  But let me rephrase.  In some
cases it took longer to fail and then the resulting error was different
from what users understood already, while in other cases -IIRC- we saw
failures where the _app_ could not do more than one round-trip and then
the error definitely had to be very different from "service principal
unknown".

In order to fallback to pick IAKERB in SPNEGO because krb5 failed,
SPNEGO has to know that the failure was due to line of sight issues and
not that the server principal is unknown.

The fix in #8021 was to make SPNEGO never try IAKERB by default.  It can
still be negotiated IIRC, but the app has to opt-into it.

Thinking about it now, a better fix would be to allow SPNEGO to try
falling back to IAKERB IFF initSecContext() w/ krb5 failed with a KDC
unreachable error.  That requires hard-coding -in the SPNEGO initiator
implementation- knowledge of the special relationship between IAKERB and
krb5 -- this might be unpleasant to us implementors givne that we've
striven to keep SPNEGO implementations totally generic, but so what.

Assuming you already have a TGT for the user, then having SPNEGO know
when to fall back on IAKERB and when not to should suffice.

Otherwise you might run into an API design issue with how to defer
initial credential acquisition to initSecContext() time in a backwards-
compatible way.  But I assume that if you want to do initial credential
acquisition using IAKERB then you probably only need to do that when
connecting to a remote access gateway, in which case backwards-compat in
APIs is probably not a concern.

Nico
--