Simo Sorce <[email protected]> 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 ([email protected]) <https://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
