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

[Luke Howard Bentata <[e-mail]>]

> On 18 Feb 2023, at 1:31 pm, Nico Williams <[e-mail]> wrote:
> 
> 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.

Microsoft’s SPNEGO used to do this, in the case where the acceptor sent the first message (or the initiator sent an empty message).

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-spng/8e71cf53-e867-4b79-b5b5-38c92be3d472 <https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-spng/8e71cf53-e867-4b79-b5b5-38c92be3d472>

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

You could probably avoid a special case in SPNEGO with a context option that contained the mechanisms that had been tried and their status codes, calling GSS_Set_sec_context_option() before the first call to GSS_Init_sec_context() for the fallback mechanism (and ignoring the error if it’s GSS_S_UNAVAILABLE).

Or, you know, just a special case in SPNEGO. We already have one for the 16-bit Kerberos OID.

>> 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”?

I suspect half / single round trip.

— Luke