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

[Nico Williams <[e-mail]>]

On Sun, Feb 19, 2023 at 02:43:54PM -0500, Ken Hornstein wrote:
> >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).
> 
> You know, the frustrating thing to me (as a Kerberos fan) is that
> the multiple roundtrips problem isn't a Kerberos problem but more
> related to all of the stuff layered on top of Kerberos (GSS, SPNEGO,
> etc etc).  I see how we got here, but I always was a bit skeptical of
> the value-add of all of those layers in practice.

I suspect that Simo is referring to HTTP 401, 200, 401, 200, .. problem.
That can happen with any HTTP authentication scheme, and I've seen that.
The solution is to use cookies.

GSS-API adds no round trips.  SPNEGO only adds a round trip if the
initiator's optimistic choice fails.  Kerberos w/o mutual auth needn't
add even one round trip to the application layer protocol (though having
huge tickets doesn't help) provided the application is using the
sub-session keys (i.e., GSS per-message tokens or KRB-PRIV/SAFE).

The problem with Kerberos is not the round trips.

The biggest problem with Kerberos is that the world has been moving to
HTTP for everything, and in HTTP land the number of user-agent
implementations is enormous, and most don't support Negotiate.
Credential orchestration needs to be self-service in all deployments,
regardless of whether we're talking about Kerberos or PKI.

  (For this problem I've build an experimental Negotiate-as-a-service.)

Another problem with Kerberos is credential orchestration -especially
server credentials ("keytabs")- and the need for KDC synchronization.
Just as there's a Let's Encrypt for the web that makes TLS server
credential provisioning much simpler, Kerberos and anything else that
requires server credentials also needs that.  Without this feature it's
all just hard to use and scale.

The lack of a standard "kadmin" protocol for fetching keys (and rotating
them) is a serious interoperability problem that causes integration and
provisioning pain.  (Maybe we should propose Heimdal's httpkadmind
protocol?)

There's also KDC synchronization that can be annoying.

  (For this problem in Heimdal we've build a virtual service principal
   namespace feature that derives service keys from the namespace's
   keys, the principals' names, and each key rotation epoch.)

It's not like it's all great with other authentication protocols.

 - JWT lacks a fetch-a-rock protocol (like the TGS protocol).  Such a
   protocol would have to be dead simple.

 - OIDC requires both, clients _and_ servers to talk to OIDC issuers.

 - OIDC and SAML transport authentication material in URI q-params.

 - Client certificate support coverage is terrible and hard to use from
   apps (especially where there's reverse proxy involved), plus the few
   apps that support client certs don't have any support for using SANs!

 - DIGEST is obsolete.

 - SCRAM was obsolete the day it was born.

 - PAKEs are not a general purpose solution.

There are good reasons why Kerberos is still around; the shortcomings of
other systems are among them.  But there's been zero work in 30 years on
making Kerberos easy to deploy, orchestrate, and operate.  The number of
people who are intimate with the protocol and who have the energy and
funding to tackle these issues is dwindling.  That's not a recipe for
success.

Nico
--