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

["Steve Syfuhs (AP)" <[e-mail]>]

The rest is a mix of null target name, SPN unknown, local accounts, and IP targets. Harcoding is honestly the most painful one.

Our plan for dealing with the failure scenario you mention below is through a mechanism we're referring to as 'late fallback' where we stuff a sentry OID in the mech list. If both initiator and acceptor SPNego libraries understand what that OID is, it'll treat it as a signal that both parties know that failures at any stage of the exchange can trigger a move to the next mech. Windows-wise you'll always understand both IAKerb and this late fallback or you'll understand neither. We have some work to make it not fall back insecurely, but I think we can figure it out such that we don't take an explicit dependency on knowing IAKerb exists. Ideally we figure out how to get that into an RFC, this one or some nego extension, otherwise it'll be documented as part of one of our [MS-] specs.

That doesn't cover the single-shot protocols. At this stage of our adventure our answer is to block them from using IAKerb by target name and service class. If admins really care, they can change the opt-in/opt-out rules.

-----Original Message-----
From: Nico Williams <[e-mail]> 
Sent: Friday, February 17, 2023 4:24 PM
To: Steve Syfuhs (AP) <[e-mail]>
Cc: Jeffrey Altman <[e-mail]>; [e-mail]
Subject: Re: [kitten] [EXTERNAL] Re: Windows Intent to revive and implement IAKerb draft-ietf-kitten-iakerb-03

In other words, the fix for rt #8021 was expedient and correct-enough, but not really correct, while the correct fix would pollute the SPNEGO implementation with knowledge of mechanism details it has heretofore managed to avoid.

If we implement IAKERB in Heimdal we'll want to implement the more correct fix that makes us sad.

Nico
-- 

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkrbdev.mit.edu%2Frt%2FTicket%2FHistory.html%3Fid%3D8021&data=05%7C01%7CSteve.Syfuhs%40microsoft.com%7C6e8a38ae670a41b6fe8708db1144f244%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638122760049599708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZJCwrx4k8SbNwW8V1G4IQ9677GX0V5mma3ScphLDPUU%3D&reserved=0 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
--