Re: [kitten] Replacing Kerberos

[Erin Shepherd <[e-mail]>]

> On 19 Feb 2023, at 03:11, Nico Williams <[e-mail]> wrote:
> 
> - the ability to easily create server/acceptor software for it
> 
>   This is a reference to ASN.1/DER _still_ being too much to ask for
>   most developers.
> 
> - the ability to make a GSS/SSP/SA(SL) mechanism, which means:
> 
>    - the ability to exchange keys
>    - some ciphersuite for wrap and MIC tokens
> - the ability to use this mechanism as a TLS 1.3 PSK

How do people feel about the security layer just being raw TLS 1.3 bootstrapped using PSK, or as close to that as possible? (Not quite sure what to do with the GSS MIC functions here, though. Maybe just draw a MAC key from a TLS exporter?)

I say this in part because re-using Kerberos encryption types as other mechs have done makes implementing a new mech outside of Kerberos a gigantic pain in the arse. If we use TLS 1.3 PSKs, you can just use a TLS stack, which you probably already have.

(Maybe we could define this framework style, provide a knob which can be used to turn this on for supporting existing mechs, and update those existing mechs to support it, and then just make it the only option for the new mech)

One other thing I’d like to suggest, since we were just talking about it:

- Builtin-in ability to proxy credential acquisition through the acceptor, IAKerb-style, where the “KDC” authentication is itself just recursively tunnelled GSS-API (so we can do SCRAM or something)

Probably should be optional on both ends, but I think building this in will avoid a bunch of the complications seen with IAKerb.

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)


- Erin