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

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

Thanks folks, good context. I'll review the diffs and threads on this. Happy to help with any logistical issues.

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

Caveat that numbers are anonymized Windows telemetry, so it's inherently biased in our direction. We know fallback from Kerberos to NTLM via SPNego occurs approximately 7% of the time because of line of sight issues. KDC Proxy [MS-KKDCP] technically solves this for us, but is a bit of a deployment joke. Spinning up yet another public-facing web server, plus certificate, plus configuring policy on machines that by definition do not have line of sight to policy sources is rather a pain in the butt for customers.

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.

As it stands, we've actually already implemented IAKerb as per draft 3, less some minor Appendix A interop concerns.

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.

From: Kitten <[e-mail]> On Behalf Of Jeffrey Altman
Sent: Friday, February 17, 2023 6:37 AM
To: [e-mail]
Subject: [EXTERNAL] Re: [kitten] Windows Intent to revive and implement IAKerb draft-ietf-kitten-iakerb-03


It should also be noted that in 2019 it was determined that there was no longer any interest in further development of IAKerb and the Working Group State for the document was set to "Dead WG Document".   Although IAKerb was never removed from the Kitten Charter.

  https://datatracker.ietf.org/wg/kitten/about/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fwg%2Fkitten%2Fabout%2F&data=05%7C01%7Csteve.syfuhs%40microsoft.com%7Cefc22916f2934e43dbdd08db10f47a15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638122414447051754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RFtk6otA1rdnU52XEOMl2x%2F0kVX5%2BT6mFbUZfTr0IPM%3D&reserved=0>

Its unclear to me from a process perspective whether the charter document is simply out of date and IAKerb needs to be once again added as a working group work item OR whether the Dead WG Document state can be removed by publishing an update.

The initial individual draft was published in 2006.  At that time there was a very narrow use case which drove the effort.   Over time the range of use cases grew broader without being reflected in the text of the draft.   Re-reading the draft today for first time in years I believe the draft fails to sufficiently describe the use cases for which it is intended and those which should be considered out of scope.

I am in favor of IAKerb or something like it being adopted and implemented.   I would appreciate it if Steve could describe the 2023 use cases for which Microsoft intends to use it in case they have significantly diverged from those considered in 2006.

Jeffrey Altman
On 2/17/2023 8:31 AM, Jeffrey Altman ([e-mail]<mailto:[e-mail]>) wrote:

Please note that draft 3 does not include all of the feedback provided on draft 2.

The draft 2 feedback starts with this archived message

  https://mailarchive.ietf.org/arch/msg/kitten/5l6CknOZBF39aZps7wQIsl_L-6o/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fkitten%2F5l6CknOZBF39aZps7wQIsl_L-6o%2F&data=05%7C01%7Csteve.syfuhs%40microsoft.com%7Cefc22916f2934e43dbdd08db10f47a15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638122414447051754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=90ulxdfe%2Fjh4RqIVyZ81a5CJR2aiVcig4GJqk9sEs20%3D&reserved=0>

and the diff between drafts 2 and 3 can be found here

  https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-iakerb-03<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-kitten-iakerb-03&data=05%7C01%7Csteve.syfuhs%40microsoft.com%7Cefc22916f2934e43dbdd08db10f47a15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638122414447051754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bmWJl39j%2FF9mXt5poqkAjXfLO8AGrtgb39MX%2B9T4SYM%3D&reserved=0>

The discussion around error handling and default realm determination is particularly important in my opinion.

I do not believe there are any implementations of draft 3.

Jeffrey Altman
On 2/16/2023 6:57 PM, Steve Syfuhs (AP) (Steve.Syfuhs=[e-mail]<mailto:Steve.Syfuhs=[e-mail]>) wrote:
Howdy folks,

I'm a developer on the Windows auth team that oversees Kerberos development. We were handed the torch from Larry, Michiko, and crew when they went off to do other exciting things.

We're currently in the process of implementing IAKerb as per the latest expired draft and want to revive it and see it through to full RFC. Happy to go into detail about why, but the benefits are I think fairly self explanatory.

Unfortunately there's a fair amount of institutional knowledge around this protocol that's been lost to time and I was wondering if someone could provide background on where things were last? What is required in order to see it through?

We have a few open questions, specifically around interop.

What is the state of the MIT implementation? The draft refers to interop with earlier versions. Is this something we need to reasonably care about? The draft says the Finished checksum key usage is implemented as int 42, but specced as 41. Why wasn't 42 used in the spec (that's otherwise a rather obnoxious interop hack)?

As mentioned, happy to go into more detail about our plans.

Cheers
Steve



_______________________________________________

Kitten mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/kitten<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fkitten&data=05%7C01%7Csteve.syfuhs%40microsoft.com%7Cefc22916f2934e43dbdd08db10f47a15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638122414447051754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oFMTyCHTrlzUCxEKY2cf0s0KShGBQroqwO7PjOmCAmw%3D&reserved=0>



_______________________________________________

Kitten mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/kitten<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fkitten&data=05%7C01%7Csteve.syfuhs%40microsoft.com%7Cefc22916f2934e43dbdd08db10f47a15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638122414447051754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oFMTyCHTrlzUCxEKY2cf0s0KShGBQroqwO7PjOmCAmw%3D&reserved=0>