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

[Nico Williams <[e-mail]>]

On Sat, Feb 18, 2023 at 12:50:57AM +0000, Steve Syfuhs (AP) wrote:
> The rest is a mix of null target name, SPN unknown, local accounts,
> and IP targets. Harcoding is honestly the most painful one.

Oof.

For the first two one might imagine having an extension where the
initiator asks the acceptor what its name is, but, ugh, that would just
paper over an important problem so best not to.  You might just have to
break those apps in order to get rid of NTLM.

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

The failure in question is an early failure, before the NegTokenInit is
sent.  A sentinel OID couldn't help.  It goes like this:

 - The SPNEGO initiator looks over the mechanisms the app wants (or all
   of them) in a local order of preference, then it picks the first one
   for which GSS_Init_sec_context() succeeds.

 - Typically krb5 is first in the list, and if krb5's initSecContext()
   fails, then the SPNEGO initiator goes on to the next item.

 - Now if krb5 fails with service principal unknown (so we have line of
   sight) then SPNEGO ends up trying IAKERB, well, IAKERB's
   initSecContext() will return CONTINUE_NEEDED the first time, then
   later will fail because... the service principal is still unknown.

 - So now instead of failing immediately with a useful error that users
   are accustomed to we fail after at least one round trip and possibly
   with a more obscure error.

The fix I'm proposing now (as opposed to then[*]) is that SPNEGO could
assume that if krb5 failed with service principal unknown, then don't
bother trying IAKERB.  This is a purely local fix to the SPNEGO
initiator; no protocol changes -not even a sentinel OID- are needed.

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

What's a "single-shot protocol"?

Nico
--