Re: heimdal http proxy
On 9/28/21 2:31 PM, Charles Hedrick wrote: If all the proxy is doing is forwarding content, it might work. But in that case it’s not obvious how much security we’re gaining by the proxy. It may be that just enabling access directly to port 88 would be as good. (I control the network, mostly.) Any sense how risky it is to expose port 88 to the internet? I was assuming that the proxy would have it's own authentication requirements. Thus the proxy would act somewhat like a bouncer in front of the KDC. Somewhat like putting the KDC behind a VPN or SPI w/ port knocking. -- Allow people that have some modicum of knowledge access to the KDC while preventing any Joe Random on the Internet from accessing the KDC. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
On Wed, 2021-09-29 at 13:41 -0600, Grant Taylor wrote: > On 9/28/21 2:31 PM, Charles Hedrick wrote: > > If all the proxy is doing is forwarding content, it might work. But > > in that case it’s not obvious how much security we’re gaining > > by the proxy. It may be that just enabling access directly to port > > 88 would be as good. (I control the network, mostly.) Any sense how > > risky it is to expose port 88 to the internet? > > I was assuming that the proxy would have it's own authentication > requirements. Thus the proxy would act somewhat like a bouncer in front > of the KDC. > > Somewhat like putting the KDC behind a VPN or SPI w/ port knocking. -- > Allow people that have some modicum of knowledge access to the KDC while > preventing any Joe Random on the Internet from accessing the KDC. In truth, most of the value for the proxy (MS-KKDCP style) is that it uses a standard port open in most places, and wraps everything in TLS so that most inspection from broken HTTP middleboxes is prevented). There is the added TLS channel encryption that can prevent a lot of MITM as well given the client SHOULD validate the certificate of the proxy. HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
>If all the proxy is doing is forwarding content, it might work. But in >that case it’s not obvious how much security we’re gaining by the >proxy. It may be that just enabling access directly to port 88 would be >as good. (I control the network, mostly.) Any sense how risky it is to >expose port 88 to the internet? For what it's worth, we do. Protocol wise, Kerberos is literally designed to operate over untrusted networks, so I'm fine with the protocol being accessible from the Internet. Implementation-wise, the people I personally know who do that are running one of the open-source Kerberos implementations. It is my understanding that Microsoft does NOT recommend opening the Kerberos port on your domain controller to the Internet, but if you are making it available via a web proxy I'm not sure how that doesn't qualify. I'm not sure why that is Microsoft's guidance (note that I have only heard that second hand and I have not verified it). --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
If all the proxy is doing is forwarding content, it might work. But in that case it’s not obvious how much security we’re gaining by the proxy. It may be that just enabling access directly to port 88 would be as good. (I control the network, mostly.) Any sense how risky it is to expose port 88 to the internet? > On Sep 12, 2021, at 12:53 PM, Grant Taylor wrote: > > On 9/12/21 5:49 AM, Jeffrey Altman wrote: >> The answer is "yes", but someone would need to development the >> implementation and submit a pull request. > > Here's a silly thought. > > What about using something like socat to listen on local port 88 and have it > use the upstream proxy via CONNECT requests (possibly with authentication) to > reach the internal KDC, thus making the socat duck quack as if it's the KDC. > > It's a bit of a hack. But would it suffice for limited use? > > > > -- > Grant. . . . > unix || die > > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
On 9/12/21 5:49 AM, Jeffrey Altman wrote: The answer is "yes", but someone would need to development the implementation and submit a pull request. Here's a silly thought. What about using something like socat to listen on local port 88 and have it use the upstream proxy via CONNECT requests (possibly with authentication) to reach the internal KDC, thus making the socat duck quack as if it's the KDC. It's a bit of a hack. But would it suffice for limited use? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
>The hope is that the proxy will read requests and validate them. Thus >passing through the proxy would be less dangerous that exposing port 88 >directly. If that’s not true, we should consider the risks of making >port 88 available, or give up. I'm curious as to exactly what validation for requests you think the HTTP proxy is doing that the KDC is not. The only meaningful validation I can think of would require the proxy to handle all of the functions of the KDC itself (and honestly, I suspect the only validation that the proxy is doing is, "Looks like a valid HTTP request that doesn't have any of the common SQL injection attacks in the URL"). I mean, I've certainly been in the situation where we are required to do something dumb to satisfy a overly-broad security requirement, but I always try to acknowledge the dumbness. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
On Sun, Sep 12, 2021 at 07:49:57AM -0400, Jeffrey Altman wrote: > On 9/11/2021 11:22 AM, Charles Hedrick (hedr...@rutgers.edu) wrote: > > We don’t currently explore our Kerberos servers to the Internet, but we do > > have an https proxy for MIT kerberos. Heimal apparently has its own HTTP > > proxy. Does anyone know of software to implement the proxy? > I believe the question that should be asked is > > "Can an https proxy client compatible with MIT Kerberos be implemented > for Heidmal?" My understanding is that MIT Kerberos just implemented compatibility for Microsoft's MS-KKDCP protocol, https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kkdcp/5bcebb8d-b747-4ee5-9453-428aec1c5c38 -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
On 9/11/2021 11:22 AM, Charles Hedrick (hedr...@rutgers.edu) wrote: > I’d like to be able to use Kerberos SPNEGO at home. Unfortunately the Mac > uses Heimdal. One premise of this thread is that Apple uses Heimdal as developed at https://www.heimdal.software/ aka https://github.com/heimdal/ Apple does not. Apple uses a fork from Heimdal circa 2008. Apple publishes its changes and some of them are manually cloned into https://github.com/heimdal/heimdal but most are not. > We don’t currently explore our Kerberos servers to the Internet, but we do > have an https proxy for MIT kerberos. Heimal apparently has its own HTTP > proxy. Does anyone know of software to implement the proxy? I believe the question that should be asked is "Can an https proxy client compatible with MIT Kerberos be implemented for Heidmal?" The answer is "yes", but someone would need to development the implementation and submit a pull request. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
On 9/11/21 7:35 PM, Charles Hedrick wrote: The hope is that the proxy will read requests and validate them. Thus passing through the proxy would be less dangerous that exposing port 88 directly. If that’s not true, we should consider the risks of making port 88 available, or give up. I would be quite surprised if you can find an HTTP(S) proxy that will scrutinize CONNECT traffic going to Kerberos related services. The thing that the proxy probably can do is authorization checking of who is allowed to do the CONNECT to Kerberos. E.g. authenticate to the proxy before issuing the CONNECT. Somewhat analogous to a VPN. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
>Another use case is getting tickets for Mac users. We have a few users >that ssh into enough different hosts that they want to use kerberized >ssh. Unless we open port 88 to the outside, they have to install Mac >ports and use the MIT kinit. So they can't open port 88 to the outside, but port 88-via-80 is fine? --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
The hope is that the proxy will read requests and validate them. Thus passing through the proxy would be less dangerous that exposing port 88 directly. If that’s not true, we should consider the risks of making port 88 available, or give up. > On Sep 11, 2021, at 7:07 PM, Ken Hornstein wrote: > > >> >> Another use case is getting tickets for Mac users. We have a few users >> that ssh into enough different hosts that they want to use kerberized >> ssh. Unless we open port 88 to the outside, they have to install Mac >> ports and use the MIT kinit. > > So they can't open port 88 to the outside, but port 88-via-80 is fine? > > --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
Another use case is getting tickets for Mac users. We have a few users that ssh into enough different hosts that they want to use kerberized ssh. Unless we open port 88 to the outside, they have to install Mac ports and use the MIT kinit. While it seems simple to me, it’s not for real users. If they could point Heimdal to a proxy I think it would be easier to support. It won’t work for two factor, since Apples Heimdal kinit doesn’t support that, but most of users don’t use two factors, just privileged users. The easier solution would be for Apple to move to MIT, but I have no way to make that happen. > On Sep 11, 2021, at 2:22 PM, Rick van Rein wrote: > > Hello Charles, > >> I???d like to be able to use Kerberos SPNEGO at home. Unfortunately the Mac >> uses Heimdal. > > SPNEGO has really a low security level. I am surprised this is considered > acceptable for a https proxy. > > We are working on two better solutions, with software that classifies only > little over "proof of concept'. > > - TLS-KDH to integrate Kerberos authentication with ECDH encryption; > this combination is in fact Quantum Proof > > https://datatracker.ietf.org/doc/html/draft-vanrein-tls-kdh > > - HTTP-SASL integrates SASL as a HTTP authentication mechanism, and this > is meant to allow Kerberos as well. In contrast with SPNEGO, it would > be possible to require Channel Binding (at least to the webserver _name_). > > https://datatracker.ietf.org/doc/html/draft-vanrein-httpauth-sasl > > > Take note: These have not even been proposed on this list, simply due to > lack of time to actively discuss it (been mostly occupied with this and > related implementations). So at best this could be a future opportunity. > Still, your usecase may help to propell the work forward, so please share > if this would be helpful for your situation. You may want to pass this > by your sysadmin too. > > > Cheers, > -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
My use case is a few web applications. Linux user group management, editing our wiki, and responding to help desk tickets. Generic web apps that I would like to use at home. We support CAS, but our university CAS server has disabled SSO. Since I already have a Kerberos ticket to use ssh, it would be nice to be able to get into the web apps without having to do CAS and Duo each time. (My Kerberos tickets also require two factor authentication to get them.) We use Kerberos and GSSAPI for other things, but not that I’d need at home. > On Sep 11, 2021, at 2:22 PM, Rick van Rein wrote: > > Hello Charles, > >> I???d like to be able to use Kerberos SPNEGO at home. Unfortunately the Mac >> uses Heimdal. > > SPNEGO has really a low security level. I am surprised this is considered > acceptable for a https proxy. > > We are working on two better solutions, with software that classifies only > little over "proof of concept'. > > - TLS-KDH to integrate Kerberos authentication with ECDH encryption; > this combination is in fact Quantum Proof > > https://datatracker.ietf.org/doc/html/draft-vanrein-tls-kdh > > - HTTP-SASL integrates SASL as a HTTP authentication mechanism, and this > is meant to allow Kerberos as well. In contrast with SPNEGO, it would > be possible to require Channel Binding (at least to the webserver _name_). > > https://datatracker.ietf.org/doc/html/draft-vanrein-httpauth-sasl > > > Take note: These have not even been proposed on this list, simply due to > lack of time to actively discuss it (been mostly occupied with this and > related implementations). So at best this could be a future opportunity. > Still, your usecase may help to propell the work forward, so please share > if this would be helpful for your situation. You may want to pass this > by your sysadmin too. > > > Cheers, > -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
At home I’m outside our firewall. We have an https proxy that works fine for MIT implementations, but not heimdal. Heimdal has an http proxy configuration available in krb5.conf, but that’s useless without an actual proxy server. I’m looking for an implementation of the proxy. I also don’t see any example of the format needed to define the proxy in krb5.conf. An alternative is to open port 88 from the outside. I’m not sure how risky that actually is. The Kdc is a pretty mature piece of software. > On Sep 11, 2021, at 4:13 PM, Roland C. Dowdeswell wrote: > > On Sat, Sep 11, 2021 at 03:22:26PM +, Charles Hedrick wrote: >> > >> I’d like to be able to use Kerberos SPNEGO at home. Unfortunately >> the Mac uses Heimdal. >> >> We don’t currently explore our Kerberos servers to the Internet, >> but we do have an https proxy for MIT kerberos. Heimal apparently has >> its own HTTP proxy. Does anyone know of software to implement the proxy? > > Heimdal does support SPNEGO. Can you be more specific about what you > are trying that is not working? > > Thanks, > > -- >Roland C. Dowdeswell https://Imrryr.ORG/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
On Sat, Sep 11, 2021 at 03:22:26PM +, Charles Hedrick wrote: > > I’d like to be able to use Kerberos SPNEGO at home. Unfortunately > the Mac uses Heimdal. > > We don’t currently explore our Kerberos servers to the Internet, > but we do have an https proxy for MIT kerberos. Heimal apparently has > its own HTTP proxy. Does anyone know of software to implement the proxy? Heimdal does support SPNEGO. Can you be more specific about what you are trying that is not working? Thanks, -- Roland C. Dowdeswell https://Imrryr.ORG/ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: heimdal http proxy
Hello Charles, > I???d like to be able to use Kerberos SPNEGO at home. Unfortunately the Mac > uses Heimdal. SPNEGO has really a low security level. I am surprised this is considered acceptable for a https proxy. We are working on two better solutions, with software that classifies only little over "proof of concept'. - TLS-KDH to integrate Kerberos authentication with ECDH encryption; this combination is in fact Quantum Proof https://datatracker.ietf.org/doc/html/draft-vanrein-tls-kdh - HTTP-SASL integrates SASL as a HTTP authentication mechanism, and this is meant to allow Kerberos as well. In contrast with SPNEGO, it would be possible to require Channel Binding (at least to the webserver _name_). https://datatracker.ietf.org/doc/html/draft-vanrein-httpauth-sasl Take note: These have not even been proposed on this list, simply due to lack of time to actively discuss it (been mostly occupied with this and related implementations). So at best this could be a future opportunity. Still, your usecase may help to propell the work forward, so please share if this would be helpful for your situation. You may want to pass this by your sysadmin too. Cheers, -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
