appl/simple/client/sim_client.c uses internal APIs
Russ Allbery
eagle at eyrie.org
Mon Feb 27 18:53:29 EST 2023
Simo Sorce <simo at redhat.com> writes:
> On Fri, 2023-02-24 at 16:27 -0800, Russ Allbery wrote:
>> Essentially everything that I don't like about GSSAPI is a direct
>> consequence of the fact that it's a generic authentication protocol
>> that in theory (although essentially never in practice outside of toys
>> and science experiments) could negotiate a mechanism other than
>> Kerberos. Supporting that generality forces the addition of
>> irreducible complexity to the API.
> Sorry Russ,
> I do not know about toys or science experiments, but I have been using
> GSSAPI in real HTTP applications to do either NTLM or Krb5 just fine.
> And before that in SMB applications (although Samba is more complicated
> because of its history).
Argh, sorry, I got this backwards, and I think this is the same mistake
that I have made before. For some reason it is stuck in my head that
SPNEGO is used to negotiate GSSAPI when it's the other way around: SPNEGO
is a GSSAPI mechanism.
Thank you all for the interesting feedback on this thread. I think my
original statement had a few things wrong, and I appreciate all the
corrections.
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.
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'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.
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.)
--
Russ Allbery (eagle at eyrie.org) <https://www.eyrie.org/~eagle/>
More information about the Kerberos
mailing list