[37920] in Kerberos
Re: What is the interaction for Kerberos in a proxy environment?
daemon@ATHENA.MIT.EDU (Simo Sorce)
Mon Mar 27 12:06:15 2017
Message-ID: <1490630753.5861.124.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Joshua Schaeffer <jschaeffer0922@gmail.com>
Date: Mon, 27 Mar 2017 12:05:53 -0400
In-Reply-To: <CAFNRWC6z3Oo8YS115vTkv1kj+uboC2SFYKLm66YGu6WSGx1VWg@mail.gmail.com>
Mime-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
