Re: What is the interaction for Kerberos in a proxy environment?
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?
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?
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?
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
What is the interaction for Kerberos in a proxy environment?
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? Regards, Dong Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos