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

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

Excellent.

>Heimdal did add support for it a couple of years back (3a6229f6) but I don’t believe MIT supports it.

That's good to know. It's a bit of an edge case anyway. Mostly only affects callers in the kernel for us (they like their rented pools), and that's a relatively small number.
________________________________
From: Luke Howard Bentata <[e-mail]>
Sent: Friday, February 17, 2023 9:08:25 PM
To: Steve Syfuhs (AP) <[e-mail]>
Cc: Nicolas Williams <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [kitten] [EXTERNAL] Re: Windows Intent to revive and implement IAKerb draft-ietf-kitten-iakerb-03

You don't often get email from [e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>


On 18 Feb 2023, at 3:56 pm, Steve Syfuhs (AP) <[e-mail]<mailto:[e-mail]>> wrote:

Ah, I think I follow the failure case now Nico. I'll have to think about this in the generic case. In Windows our implementation is an extension within the core kerb stack, where kerberos exposes a list of mech OIDs it'll let nego try. This is incidentally how we expose u2u as a mech (NTLM, digest, etc. expose their own set of one; NegoEx is its own beast). Since kerb is still first, it'll try as usual and succeed, fail with no KDC, or fail with SPN not found. We keep a small bit of state such that when nego then tries the iakberb OID the kerb stack knows what the original failure was, and either starts the flow if KDC not found or triggers an error to move to the next mech. This doesn't help with non-Windows clients though.

It’s probably not a big deal in practice. All the non-Windows implementations I can think of build SPNEGO and Kerberos from the same source tree (indeed they’re almost always colocated in the same DLL). Adding some Kerberos-specific state to SPNEGO wouldn’t be the end of the world.

— Luke