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

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

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.

For single shot I just mean encapsulation protocols that can't round-trip. A good example is when HTTP does a POST. The server will accept and trigger continuation and drop the body, but the client won't retry the POST for idempotent reasons. I'm kind of in the camp that this would be better solved by moving up the stack to OAuth or OpenID or something better suited for web flows. We know we can't solve all cases and are not trying to. Just the biggies. Let the rest die through attrition.

You have captured the exact problem with unknown names. We can extend the protocol to solicit an SPN, and it turns out if you're willing to look the other way on good protocol manners, this can work today within spec. We just lose server auth. This *is* a net-win for security still, just not much of one.

NegoEx does have better control over the nego state machine, but it has its own issues, predominantly lack of adoption and complexity. The thing I like about iakerb within SPNego is that it's trivially simple to understand.

One other thing I was thinking about. We came across a fun fragmentation bug in SPNego that's probably been around forever. When one party has a limited buffer size and we aren't allowed to allocate, we will fragment the message, where the other party sends an empty message to indicate gimme-more until full. The client->server flow has always worked, but the server->client flow was never implemented (when is the REP ever bigger than the REQ? Now any time it's not an AP). The bug, aside from lack of implementation, is that callers tend to assume responses with continuation are not empty and fail if they are. I've fixed it by always sending a specific value to indicate more is requested, but who knows how that plays with interop. Frankly I haven't done my research within all the RFCs to see if there's already an answer for this, but figured I'd include it here if folks have thoughts.
________________________________
From: Luke Howard Bentata <[e-mail]>
Sent: Friday, February 17, 2023 7:18:33 PM
To: Nicolas Williams <[e-mail]>
Cc: Steve Syfuhs (AP) <[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 1:31 pm, Nico Williams <[e-mail]<mailto:[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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-spng%2F8e71cf53-e867-4b79-b5b5-38c92be3d472&data=05%7C01%7CSteve.Syfuhs%40microsoft.com%7C7b7f609d77e24ea7591e08db115ed8c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638122871310386271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DVP8Sl9gWKuCCUNuNj%2FNqoMvHbTGVLNZEkPdKl9q%2FrI%3D&reserved=0>

=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