Simo, thanks for this detailed explanation. I think my general understanding of the protocols was accurate (although I may have not portrayed that earlier) and now I have a better understanding overall.
Thanks again, Joshua Schaeffer On Mon, Mar 27, 2017 at 10:05 AM, Simo Sorce <s...@redhat.com> wrote: > On Wed, 2017-03-22 at 08:59 -0600, Joshua Schaeffer wrote: > > Again, I'm not an expert on any of these protocols, implementations, > > or frameworks so I'd be interested if anybody sees incorrect > > statements in my understanding. As far as your question about the > > proxy environment, I'm in the dark, and somebody else will have to > > comment. > > Hi Joshua I cut your explanation because I found it rather confusing and > misleading in some parts. > > Here's how I'd put down the interactions and relations between the > various protocols you mention, namely: Kerberos, GSSAPI, SASL. > > - Kerberos > It's a network authentication and key distribution protocol, it is > generally used to talk to a an Authentication Service(AS) or a Ticket > Granting Service(TGS) [commonly these are both built in the same service > called the KDC], to obtain tickets. The protocol then is used to > authenticate a client to a service using the tickets obatined by the AS > or TGS services. > > - GSSAPI (Generic Security Services API) > It's an API that abstracts the tasks of authenticating and establishing > a secure channel between 2 services. The "Krb5" mechanism is the most > known one, and often people confuses GSSAPI with just GSS/Krb5, but > GSSAPI supports other mechanisms. Some of the most common ones are > NTLMSSP and SPNEGO (a pseudo mechanism used to negotiate mechanisms) > both introduced by Microsoft for Authentication in Windows domains, but > there are others like EAP, GSI and more .. > GSSAPI mechanisms define token formats that need to be exchange by two > applications when building a secure channel. Secure channel > establishment implicitly involves (mutual) authentication of the peers, > so often GSSAPI is used to authenticate a client to a service, without > then using the established secure channel (the HTTP Negotiate case). > Integrity and Confidentiality protection are normally assumed to be > possible with GSSAPI mechanisms. > > - SASL (Simple Authentication and Security Layer) > Sasl in some ways operates in the same space as GSSAPI, except it > supports a wider variety of authentication methods as well as > negotiating them. > > So SASL and GSSAPI often "play in the same space", however SASL offers a > bridge to GSSAPI with various mechanisms, the defined ones are "GSSAPI", > "GSS-SPNEGO" and "GS2". > SASL/GSSAPI effectively supports only using the GSSAPI's Krb5 mechanism > which adds to the confusiuon around GSSAPI and Kerberos, GSS-SPNEGO was > introduced by Microsoft and supports negotiating the mechanism to be > used, and then GS2 was standardized which supposedly should supersede > both GSSAPI and GSS-SPNEGO but is rarely used in practice so far. > > The stack: > > In protocols like LDAP, IMAP etc that use this stack you have > SASL as a method to abstract what authentication protocol you want to > use and in some cases also to abstract what encryption channel to use, > but it is mostly seen as a way to abstract and support multiple > authentication methods for applications. > > Applications that use SASL and want to perform Kerberos authentication > usually support the SASL/GSSAPI which in most people experience really > translates to SASL/GSSAPI/Krb5 > > So the application that implement "SASL Authentication" for a protocol > (say IMAP), calls the SASL API and tells it to use the GSSAPI mechanism, > which in turn uses it's internal Krb5 mechanism to fetch tickets, and > produce tokens that are returned all the way back to SASL, potentially > wrapped and returned to the application. The application exchanges these > tokens with the server and gets back other tokens that are passed back > in to the SASL API, and all the way down to the lower mechanisms. Once > the negotiation is complete you know if authentication succeeded and can > use the SASL API to get some information about the peer (especially on > the server side to establish the identity of the client). > At this point, depending on the protocol, SASL may be out of the way or > it may be still used to provide privacy/confidentiality protection for > the channel established between the peers. > > So in a nutshell you should see SASL/GSSAPI as 2 things: > 1. an authentication abstraction framework > 2. a secure channel wrapper around the protocol > > HTH, > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
