Re: [kitten] Replacing Kerberos

[Nico Williams <[e-mail]>]

On Mon, Feb 27, 2023 at 01:29:13AM +0100, Erin Shepherd wrote:
> > What I meant above by "the ability to use this mechanism as a TLS 1.3
> > PSK" is that TLS applications should be able to use Kerberos / Kerberos
> > replacement in TLS a la RFC 2712 (which is essentially obsolete and
> > broken).
> 
> So effectively a standardised way of using it as a TLS keying material importer?
> Makes a lot of sense.

Sort of, yeah, but it's best to think of it as a PSK.

> > [...]
> 
> Of course. (I do wonder how many GSS-API applications actually handle 
> reordered messages though…)

As far as Internet protocols go, only NFS (over UDP).  NFSv4 obsoletes
running over UDP, so in a way not even NFS.

> > I hear you.  A GSS per-msg tokens only library using OCB only should be
> > very light-weight.  A TLS/DTLS thing would impose a great deal more in
> > the way of dependencies on Heimdal and MIT Kerberos (for example), and
> > still needs a bit more (see above), so it's not terribly appealing (but
> > if I end up on the rough side of consensus on that it's not the end of
> > the world).
> 
> I think this is a bit of a symptom here of the existing GSS-API
> implementations being an outgrowth of Kerberos implementations.
> Despite the defacto standardisation on Kerberos derived message
> tokens, they’re not really exposed as a reusable API

Everything to do with per-message tokens can be standardized so any GSS
mechanisms can use it, and it need not share any cryptosystem details
with Kerberos.

> 	One thing I would really like, as an aside, is a proxy mech
> 	which allows delegating all the context establishment business
> 	to an external process but just returns the master keys to the
> 	caller.

GSS does not preclude this!  Indeed, the way NFS implementations
commonly work is that you have a kernel-mode GSS layer that "upcalls" to
a userland "gssd" process to do all the context establishment, then when
that's done the gssd transfers the session keys to the kernel where the
per-message functions run.

> 	This is an implementation matter though

It is.

> >> I suspect we’d end up with multiple ways of getting our TGT equivalent
> >> for this system, but maybe that’s not the worst thing in the world (in
> >> fact it’s probably just pragmatic)
> > 
> > More negotiation headaches, but of the kind that we've discussed good
> > fixes for in this thread already, so I think it's OK.
> 
> I was thinking just specifically for our hypothetical “Kerberos
> replacement” mechanism:
> 
> Authentication to our KDC should just be able to reuse the “direct”
> GSS-API mechanisms (SCRAM, etc)

The KDC/IdP/whatever-trusted-third-party protocols themselves should
just use TLS, or even just HTTPS (so, TLS).  That's because everyone has
a TLS implementation, and the more we can reuse what everyone has -and
the more we can simplify everything else- the more likely it is that
there will be implementations of the new thing.

HTTP really needs a redirect-for-authentication mechanism.  I've an
Internet-Draft about that.  Basically, a 401 w/ Location: or a 3xx with
WWW-Authenticate, where Authorization: and WWW-Authenticate: headers
must be copied from redirect response to redirected request.  User-
agents will typically need to have a list of origins trusted for this.
The idea is to be able to have a really dumb user-agent that can still
enable a) secure communication between the origins involved, b) any HTTP
authentication scheme can work on the return request, c) everything can
be over HTTPS, d) everything is simple for the user-agent.

(This is inspired by the PowerShell HTTP CLI, which has an option to
enable copying of Authorization: headers from redirect responses to
redirected requests.  HTTP normally forbids copying of _any_ redirect
response headers to redirected requests.  I've a Negotiate-as-a-service
proof of concept showing that a user-agent can use Negotiate using a
redirect scheme and without having to have an implementation of
Negotiate.  This is completely generic as to HTTP auth schemes, too.)

> We should have a proxy-to-“kdc"-via-server mechanism Out Of The Box 

As you noted, that's an implementation detail, but it's certainly worth
mentioning it informatively.

> A bit of me wonders if things should just always be proxied via the
> server to the server’s “KDC", EAP/RADIUS style; it certainly reduces
> the complexity in terms of configuring endpoints with cross-realm
> trust information.

I prefer to not add I/O requirements on the server side.  Even in 2023
there still many thread-per-client, synchronous code applications.  So
much so that a common pattern is to have a reverse proxy do all these
things (e.g., exchanging OIDC codes for tokens) so as to offload the
application.  That at least does mean that adding I/O requirements on
the server side is not the end of the world, but it does still add
friction.

Nico
--