Re: 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  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

Re: What is the interaction for Kerberos in a proxy environment?

[Simo Sorce]

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

Re: What is the interaction for Kerberos in a proxy environment?

[Simo Sorce]

On Wed, 2017-03-22 at 11:23 +1300, chen dong 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.
> 
> Per my understanding about Kerberos implementation, it is all inside the
> TCP. I haven't checked the implementation but I guess that Kerberos TGT is
> sent by the client to the kerberized service over TCP. My question is how
> does this happen in a Proxy-in-the-middle environment? How does the
> kerberized service know that the Proxy-in-the-middle is trusted, and which
> client the request is from? In the client side, how can the client know
> where the kerberized service is and where is the Proxy-in-the-middle?

Kerberos is built to prevent Man-in-the-Middle, that said when Kerberos,
via GSSAPI and SPNEGO is used in a browser does not actually normally
use Channel Bindings (that is it does not bind the authentication to the
outer HTTPS channel) so proxy-in-the-middle normally works.

There are some setting in Windows environments to enable Channel
Bindings (It's called Extended Protection for Authentication), and when
that is enabled and enforced a Proxy-in-the-middle would cause
authentication failures.

HTH,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: What is the interaction for Kerberos in a proxy environment?

[Joshua Schaeffer]

On Tue, Mar 21, 2017 at 4:23 PM, chen dong  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

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos