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
