Re: [kitten] Replacing Kerberos (Re: Windows Intent to revive and implement IAKerb draft-ietf-kitten-iakerb-03)

[Nico Williams <[e-mail]>]

On Mon, Feb 20, 2023 at 03:33:14PM +1100, Luke Howard wrote:
> Ten years ago (!) I implemented (and, with Nico’s help, documented) a
> GSS-API/SASL mechanism based on Mozilla’s BrowserID protocol with the
> following properties:

I had completely forgotten about this until you reminded me a few days
ago :/

> JWT-based
> ECDH key exchange
> Key confirmation / mutual authentication
> Fast symmetric key-based re-authentication
> 1.5 round trip variant for avoiding a replay cache
> Kerberos-style naming
> JWT “authorisation data” through RFC6680 naming extensions
> RFC4121 message protection services / PRF
> Advertisement of server certificates via NegoEx

> https://datatracker.ietf.org/doc/html/draft-howard-gss-browserid

Looking at draft-howard-gss-browserid-07 I see that while this is based
on JWT, the client makes its own tokens using a key certified by the
IdP, right?

Nowadays I think the primary variation should be where the IdP makes the
token (rather than the client) bearing an ECDH public key provided by
the client (when it requests the token) and where the IdP can also
indicate what the server's ECDH public key is.  Though I still also like
the draft-howard-gss-browserid-07, it's just that factoring out
certificates will make it easier for others to implement.

To make things even easier you might submit a new I-D with just a
certificate-less variant, and then resubmit the original if there's
interest in the certificate-based variant.

Nico
--