I???d like to be able to use Kerberos SPNEGO at home. Unfortunately the Mac uses Heimdal.
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?
On Sep 11, 2021, at 4:13 PM, Roland C. Dowdeswell <elric@imrryr.org> wrote:
On Sat, Sep 11, 2021 at 03:22:26PM +0000, 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/
On Sep 11, 2021, at 2:22 PM, Rick van Rein <rick@openfortress.nl> 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
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.
On Sep 11, 2021, at 2:22 PM, Rick van Rein <rick@openfortress.nl> 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
On Sep 11, 2021, at 7:07 PM, Ken Hornstein <kenh@cmf.nrl.navy.mil> 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
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’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?I believe the question that should be asked is
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 9/11/2021 11:22 AM, Charles Hedrick (hedrick@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?"
The answer is "yes", but someone would need to development the implementation and submit a pull request.
On Sep 12, 2021, at 12:53 PM, Grant Taylor <gtaylor@tnetconsulting.net> 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
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?
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 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 231:41:09 |
| Calls: | 6,624 |
| Files: | 12,171 |
| Messages: | 5,319,441 |