Re: appl/simple/client/sim_client.c uses internal APIs

On Mon, Feb 27, 2023 at 03:53:29PM -0800, Russ Allbery wrote:
> My basic point is that I understand the need to first negotiate a security
> mechanism and then use that security mechanism, but I don't like the
> layering of multiple negotiation mechanisms, so I'm not a big fan of SASL
> and GSSAPI/SPNEGO being separate and HTTP using yet another negotiation
> protocol via WWW-Authenticate headers, although I understand why this
> happened.

We try never to have multiple layers of negotiation of mechanisms.  In
the case of HTTP, sadly, we do have that via Negotiate [RFC 4559].

Now, Negotiate is Informational, and if Microsoft had created Negotiate
via the normal IETF process, then we would never have had Negotiate use
SPNEGO, and we wouldn't have called it Negotiate.

RFC 4559 wasn't GSS-API's fault, nor SSPI's, nor SPNEGO's.  It was some
person's fault at Microsoft who probably didn't know about multi-layer
negotiation issues and who didn't ask.  It's also possible that at the
time that MSFT was creating Negotiate internally we might not have
understood multi-layer negotiation issues at the IETF anyways, though we
definitely knew by 2006 (and that's why SSHv2 forbids the use of
SPNEGO).

> Ideally, I'd like to have three concepts: a negotiation protocol, a
> security protocol for Kerberos, and an encoding layer for both of those
> protocols into the application protocol (HTTP, IMAP, whatever) that deals
> with problems like how to put this into valid HTTP requests.  I feel like

We can standardize mechanisms to be able to function in many application
protocols because in general applications provide for some synchronous
message exchange for authentication and that's enough.

But we can't get down to one way to negotiate authentication mechanisms
because application protocols going back several decades tend do it
differently.  HTTP has a negotiation protocol, and so do SASL apps, and
some GSS apps have their own negotiation while other GSS apps use
SPNEGO.  We can't retroactively change 30 years of application protocol
history.  We could try to abstract out some regularity between HTTP,
SASL apps and non-SPNEGO GSS apps (see also recent threads on the KITTEN
WG list).

> we've collectively taken multiple shots at this over the years and we keep
> getting closer, but we keep ending up with the divisions between the
> layers being murky and having multiple negotiation layers, and that in
> turn makes the code more complicated.  And this is probably a pipe dream
> at this point, since all this stuff is very baked into long-standing
> protocols that are unlikely to change significantly.

The consensus seems to be that the application has to do mechanism
negotiation itself.  That said, application protocol negotiation may
need enriching with metadata much like MSFT enriched SPNEGO with in
NegoEx.

> More actionably, for a lot of applications I think there's some merit in
> dispensing with the negitiation layer and having one single supported
> security mechanism and that's it.  This was the idea behind Wireguard, and
> I think it's an interesting model.  This isn't suitable for IMAP or HTTP
> or whatnot for obvious reasons, but it adds a lot of simplicity when one
> knows what security mechanism is in play because the (often private)
> protocol only supports a single one and can just use it directly.  And
> this is what becomes impossible when GSSAPI is the only recommended way of
> using Kerberos, because then you can't get rid of the generic layer of the
> API even if you don't need it, so you're stuck with having multiple
> identity concepts, etc.  (I do understand all of the other problems with
> the raw Kerberos API, though, and I'm not saying it should be used
> instead.  The API that I actually want doesn't exist, I think.)

Over on the KITTEN WG list we have a thread right now about Kerberos
replacement.  Let's look at some requirements:

 - has to have a bearer token mode

 - has to have a .5 round trip key exchange mode

 - has to have a 1 round trip key confirmation and ciphersuite
   negotiation mode

 - has to be simple for clients, and in particular has to be amenable to
   having a really dumb client that just proxies messages between the
   server and an authentication service

 - has to be simple to orchestrate server credentials for

 - no more than 1.5 round trips?

   (But one might want to have allowance for a recovery-from-errors
   extra leg.  For example, with Kerberos if the server's keys rotate
   and the server loses the old keys and the client has a ticket
   encrypted in the old keys, right now that's a hard error, but RFC
   4121 could be extended to allow the acceptor to return
   GSS_S_CONTINUE_NEEDED and the initiator to recover by fetching a new
   ticket and then sending a new AP-REQ.)

Kerberos fails the simplicity requirement, but otherwise mostly fits.
JWT only ticks the bearer token and simplicity items.  The old
AUTH_DH/mech_dh, if modernized, would tick all of the boxes.

But JWT could be enriched to meet all the requirements, and that is my
proposal.  (As well, JWT has a symmetrically-keyed mode that looks a lot
like Kerberos.)

Nico
-- 
________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos