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

[Simo Sorce <[e-mail]>]

Uhmm,
Ignore the server authentication verification part, I was thinking
about local auth with a fraudulent user and KDC and mixed in here when
thinking about fraudulent server (and its local fraudulent KDC). 

The rest hopefully is not similarly flawed :)

On Sun, 2023-02-19 at 12:39 -0500, Simo Sorce wrote:
> Hi Steve,
> in the past I wanted to build a "local" KDC into each server (I think
> Apple may have something like that actually), so that you could always
> fallback to do a AS request against the server directly (with the
> server name as a pseudo Realm, and if it replied you'd just use
> kerberos as a fancy challenge-response protocol.
> 
> In order to reduce latency you'd want to return directly a service
> ticket together with a TGT. You could return directly a service ticket
> only, but if you want to allows different services on a host to have
> different keys you'd do TGT+ticket.
> Of course this is not much of a concern for Windows where traditionally
> it handles credentials as a system service and never exposes them to
> services and it never supported using multiple keys for different
> service (that I know of).
> Therefore having a custom workflow that returns a service ticket
> directly is probably fine. It would still be nice to try to avoid
> multiple round trips if possible.
> 
> One of the issues here is figuring out how to avoid this fallback to
> become a way to exploit clients.
> One issue with direct to server authentication is that you have no
> trust anchors to determine if the server is really who it claims to be.
> Their "local KDC" can send back to the client any garbage if a classic
> AS request/reply is used. And then simply accept any garbage sent in a
> tgs request as well.
>  
> So you cannot just fallback w/o some checks, or servers can be
> impersonated somewhat easily when there is no line of sight (laptop
> travels away from the mothership and suddenly any request to "known"
> servers becomes a fallback path because KDCs are not available).
> 
> I assume this can be easily fixed by returning something that can be
> verified by the client, encrypted with the shared session key, probably
> even a reverse encrypted timestamp auth (from KDC to client this time)
> might suffice.
> 
> Anyway this will be different enough from IAKerb that would really be
> beneficial to discuss it in IETF before a full implementation is done.
> 
> Of course another way to replace NTLM, is to just adopt some more
> modern challenge-response mechanism like SCRAM or a PAKE, but then the
> protocol should really have strong algorithmic agility in it, so that
> we do not end up like with NTLM again in 20 years.
> 
> I assume you want to use something like IAKerb because that protocol
> already allows you to carry authorization data, and it would be a pain
> to replace NTLM with another thing that does the same thing, just
> different. It allows to reuse a lot of existing code. OTOH IAkerb will
> not easily allow for single round-trip auth ... 
> 
> 
> Speaking of which I wonder if it would be possible to discuss changing
> (gutting?) SPNEGO, quite radically.
> 
> The reason why SPNEGO is a pain is the case of needing multiple
> roundtrips. But that is due only to the fact that we want to carry half
> of the negotiation "in band" over HTTP.
> However if we had a KDC service that can return a bearer token that a
> service can then simply accept by using a much simplified workflow, the
> need for multiple roundtrips over HTTP (or any similar protocol) would
> entirely go away.
> 
> This is similar to what Nico mentioned in his emails I think, but I
> would embed this in the TGS service, and just carry a new mech OID in
> SPNEGO, the client could do completely optimistic authentication and
> pre-send a bearer token wrapped in  SPNEGO (only over HTTPS of course)
> and send the new OID with the bearer token (after all if you got it
> from the TGS, it means the KDC believes the server can handle it).
> 
> The bearer token could even be a JWT that carries claims (or anything
> analogous), and could be verified either directly on the service
> (standalone server case), or shipped somewhere else for verification
> and then cached (complex load balanced or otherwise terminated services
> where frontend and backends are disjoint).
> 
> Adding channel-bindings support would not be hard as long as the client
> can do TGS requests after the HTTPS channel is already established,
> especially if something like a JWT is employed. (But it would require
> new TGS requests every time a new HTTPS connection is made, probably
> not for everyday cases as it adds up in latency again.
> 
> 
> Just throwing it out here, because I sure would love to make it
> possible (and easier) to use kerberos-backed out on the Web, without
> all the issues that come with multiple-roundtrips, which are what I
> find breaks most of these scenarios (the complexity of the protocol
> itself and the unfamiliarity of any non-password/bearer based auth
> scheme aside).
> 
> Simo.
> 
> On Fri, 2023-02-17 at 19:04 +0000, Steve Syfuhs (AP) wrote:
> > 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>
> > _______________________________________________
> > Kitten mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/kitten
> 

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc