What is the interaction for Kerberos in a proxy environment?

[Joshua Schaeffer]

On Tue, Mar 21, 2017 at 4:23 PM, chen dong <chendong.jy at gmail.com> wrote:

> I am not sure that my statement is right here. If I am wrong, please
> correct me.
>
> As Kerberos protocol works atop of TCP protocol. Kerberos protocol has its
> own different implementation such MIT Kerberos. And on top of Kerberos,
> there is a virtual layer SASL - simple authentication and security layer,
> this SASL layer can use different mechanism including Kerberos. There is a
> up layer implementation called GSSAPI - generic security system API. It
> also holds different mechanisms underneath including Kerberos. no sure the
> relation ship between SASL and GSSAPI.
>
>
I thought I chime in about this questions here as I want to make sure my
own understanding is also correct. So I'll give my own interpretation and
let smarter people correct me :)

I wouldn't call SASL a virtual layer, but more of a sandwich layer. SASL is
a security framework that is used to allow two protocols to communicate
with each other using a common, negotiated authentication mechanism. The
common examples are:

   - LDAP and Kerberos
   - IMAP and SMTP (I think)

I only work with LDAP and Kerberos so that's the example I go with. SASL
allows any implementation of the Kerberos protocol (MIT, Heimdal, etc) to
securely communicate with any implementation of the LDAP protocol
(OpenLDAP, Apache DS, Sun ONE, etc). The SASL protocol does not provide
security or authentication, it is a means by which the protocols can
communicate a common mechanism by which they then can establish security
and authentication. It does not pass the secure messages between the two
protocols itself. In the case of LDAP and Kerberos the most common
mechanism by which the two protocols can communicate is GSSAPI. Both LDAP
and Kerberos understand the GSSAPI implementation (a.k.a. they provide that
application programming interface) so when SASL is used each program agrees
to use GSSAPI as it is common between them.

GSSAPI is not a protocol, but an API that allows the two programs to send
secure messages. The API itself does not provide security, merely a
mechanism (a "hook" so to speak) that the two programs can commonly use to
securely communicate with each other. Without it every program would have
to know how speak to individual programs. Obviously this is the point of
API's in general, to allow systems to connect to other systems without
direct implementation.

In my own documentation on setting up OpenLDAP with MIT Kerberos I wrote
this about SASL and GSSAPI. It's just a rehash of what I just said, but I'd
be interested to see if anyone can point out mistakes I made in the
description:

The integration with SASL needs to be completed. Several packages need to
> be installed and configured. The first is to install SASL and GSSAPI.
> Because we are using the MIT Kerberos implementation, the MIT GSSAPI
> package will be used. SASL or Simple Authentication and Security Layer is a
> security framework that allows two protocols to authenticate, securely, to
> each other. In this case we need the LDAP protocol which is implemented by
> slapd to authenticate with the Kerberos protocol which is implemented by
> MIT Kerberos. SASL requires that a common auth mechanism be used between
> the two protocols. The mechanism must be supported by both protocols in
> order to be used. SASL does not provide the authentication but rather a
> layer or space that the two protocols can communicate an authentication
> mechanism. The mechanism here is GSSAPI. This mechanism doesn’t provide the
> authentication either, however it does provide an API that allows
> applications and protocols to securely communicate to each other using the
> API.


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.

Thanks,
Joshua