What is the interaction for Kerberos in a proxy environment?

[Joshua Schaeffer]

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 <simo at 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
>
>