SOCKS and/or HTTP CONNECT proxy #1151
Comments
|
IAKERB would be better, no?
|
If I understand correctly, IAKERB is a mechanism for forwarding the user<->KDC exchanges through a GSSAPI channel already being established between user<->service, rather than through a side channel opened by libkrb5, to acquire a service ticket given a tgt. (Please correct me if I misunderstood!)
|
|
MIT has shipped with IAKERB for a long time, macOS has its own implementation (which is open source, so could be integrated into Heimdal – they use Heimdal), and it's coming in a future version of Windows. But yes, more work than SOCKS support. |
|
Heimdal does have KDC-over-HTTP support, but not KDC-over-HTTPS -- that would require using OpenSSL for TLS, or maybe s2n. I've been wanting to import
Correct.
Well, it doesn't, unless you defer kinit till
Heimdal does not support IAKERB, no.
Well, Microsoft has expressed interest in extending IAKERB so that it can be used to replace NTLM(!), but apart from that bit of vaporware: not at all. I'd rather do something simpler:
so that FIDO/UDF/whatever can be something the service implements and then it vends a serialized Kerberos credential. As it happens, something like that exists in-tree right now ( To some degree I'm asking: why even bother with Kerberos? Well, there's a few reasons, though not all exactly compelling:
My own preference (see recent-ish posts on the IETF KITTEN WG list) would be to extend JWT so that it can provide all the functionality that GSS-API Kerberos apps typically expect:
but also to extend JWT so that it has a standard fetch-a-token protocol that browsers and other HTTP user-agents can follow. |
Well, to be pedantic, Heimdal does (in Apple's implementation). So it wouldn't be impossible to merge their code. |
Ah, I didn't know. I mean, I suppose we could, but MIT's experience with IAKERB wasn't great. OTOH, if @SteveSyfuhs is serious about building an NTLM replacement out of IAKERB then we might have to. Still, that wouldn't get us much closer to having what @riastradh is asking for. |
|
Good news! Futurama.gif
We are still serious about IAKerb. It's currently in a quantum superposition of both being in code and not in code because I'm an idiot and broke some stuff.
That said, the OP request is not a behavior we intend to solve with IAkerb. We still assume the acceptor will have some line of sight, so in the case where the client is both the initiator and acceptor (say Windows interactive logon), we would still require a line-of-sight transport like MS-KKDCP (kerb over http/s).
All of that said FAST with armoring is also an option, which shields a lot of information on the wire. Though admittedly still leaves some things in the clear.
…________________________________
From: Nico Williams ***@***.***>
Sent: Monday, June 5, 2023 5:51:27 PM
To: heimdal/heimdal ***@***.***>
Cc: Steve Syfuhs ***@***.***>; Mention ***@***.***>
Subject: Re: [heimdal/heimdal] SOCKS and/or HTTP CONNECT proxy (Issue #1151)
Heimdal does not support IAKERB, no.
Well, to be pedantic, Heimdal does (in Apple's implementation). So it wouldn't be impossible to merge their code.
Ah, I didn't know. I mean, I suppose we could, but MIT's experience with IAKERB wasn't great. OTOH, if @SteveSyfuhs<https://github.com/SteveSyfuhs> is serious about building an NTLM replacement out of IAKERB then we might have to. Still, that wouldn't get us much closer to having what @riastradh<https://github.com/riastradh> is asking for.
—
Reply to this email directly, view it on GitHub<#1151 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJHTYJDHH66JLARK6O7PYDXJZ5I7ANCNFSM6AAAAAAY3S4QIQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
:)
The realm name and the client's IP remain in the clear. Now the client's IP will always be in the clear, and KDCs might want to see it. A VPN or a proxy will take care of the realm name. This is fairly hard work here. But on the plus side, if we did a kinit-over-HTTPS sort of thing that might take care of OP's desire for FIDO/UDF and proxying. |
For the purpose of this issue, the premise is that I, as a user of client-side SSO, want to be able to log into existing Kerberos realms that I have no control over, but I don't want to expose records of my location when I log in, or reveal to others on the network who I am or what I'm logging into. (For the U2F/FIDO or IAKERB questions, which necessarily involve changes to a realm at the very least to upgrade the KDC software, let's discuss those in other issues -- U2F/FIDO, IAKERB.) |
|
I don't have much skin in the heimdal game, so obviously my opinion is just that. HTTPS is the transport de rigueur for all things and any transport otherwise in the stack is going to be scrutinized by everyone, except perhaps for a direct TLS or QUIC thing with less framing. But also HTTPS is a known quantity and everyone's favorite OS already supports it natively.
…________________________________
From: riastradh ***@***.***>
Sent: Monday, June 5, 2023 6:51:22 PM
To: heimdal/heimdal ***@***.***>
Cc: Steve Syfuhs ***@***.***>; Mention ***@***.***>
Subject: Re: [heimdal/heimdal] SOCKS and/or HTTP CONNECT proxy (Issue #1151)
To some degree I'm asking: why even bother with Kerberos?
For the purpose of this issue, the premise is that I, as a user of client-side SSO, want to be able to log into existing Kerberos realms that I have no control over, but I don't want to expose records of my location when I log in, or reveal to others on the network who I am or what I'm logging into.
(For the U2F/FIDO or IAKERB questions, which necessarily involve changes to a realm at the very least to upgrade the KDC software, let's discuss those in other issues -- U2F/FIDO<#1152>, IAKERB<#1153>.)
—
Reply to this email directly, view it on GitHub<#1151 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJHTYIE5DHJYKFQXOYATXTXJ2EJVANCNFSM6AAAAAAY3S4QIQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Heh, well, I share your opinion. Honestly, I want to replace Kerberos with something like I've described (JWT + bits needed to replace Kerberos as a drop-in), and any protocols for talking to a KDC-like entity should run over HTTPS. |
All network traffic to KDC goes through the SOCKS4a proxy if it is configured. This is deliberately kept simple -- and is not generalized to SOCKS4 or SOCKS5 or other types of proxies -- so it is easy to audit for network and DNS leaks. (SOCKS5 might be OK but takes more work to implement.) XXX Need to audit Heimdal for other kinds of traffic too. XXX Need to combine with heimdal#1155 to plug DNS leaks. XXX Need to figure out where the socks4a.c code should go. fix heimdal#1151
All network traffic to KDC goes through the SOCKS4a proxy if it is configured. This is deliberately kept simple -- and is not generalized to SOCKS4 or SOCKS5 or other types of proxies -- so it is easy to audit for network and DNS leaks. (SOCKS4 works in IP addresses, and so invites DNS leaks. SOCKS5 can be OK, if used judiciously, but takes more work to implement.) XXX Need to audit Heimdal for other kinds of traffic too outside libkrb5. Subsequent changes on this branch will address other parts of libkrb5. XXX Need to combine with heimdal#1155 to plug DNS leaks. XXX Need to figure out where the socks4a.c code should go. fix heimdal#1151
All network traffic to KDC goes through the SOCKS4a proxy if it is configured. This is deliberately kept simple -- and is not generalized to SOCKS4 or SOCKS5 or other types of proxies -- so it is easy to audit for network and DNS leaks. (SOCKS4 works in IP addresses, and so invites DNS leaks. SOCKS5 can be OK, if used judiciously, but takes more work to implement.) XXX Need to audit Heimdal for other kinds of traffic too outside libkrb5. Subsequent changes on this branch will address other parts of libkrb5. XXX Need to combine with heimdal#1155 to plug DNS leaks. XXX Need to figure out where the socks4a.c code should go. fix heimdal#1151
All network traffic to KDC goes through the SOCKS4a proxy if it is configured. This is deliberately kept simple -- and is not generalized to SOCKS4 or SOCKS5 or other types of proxies -- so it is easy to audit for network and DNS leaks. (SOCKS4 works in IP addresses, and so invites DNS leaks. SOCKS5 can be OK, if used judiciously, but takes more work to implement.) XXX Need to audit Heimdal for other kinds of traffic too outside libkrb5. Subsequent changes on this branch will address other parts of libkrb5. XXX Need to combine with heimdal#1155 to plug DNS leaks. XXX Need to figure out where the socks4a.c code should go. fix heimdal#1151
All network traffic to KDC goes through the SOCKS4a proxy if it is configured. This is deliberately kept simple -- and is not generalized to SOCKS4 or SOCKS5 or other types of proxies -- so it is easy to audit for network and DNS leaks. (SOCKS4 works in IP addresses, and so invites DNS leaks. SOCKS5 can be OK, if used judiciously, but takes more work to implement.) XXX Need to audit Heimdal for other kinds of traffic too outside libkrb5. Subsequent changes on this branch will address other parts of libkrb5. XXX Need to combine with heimdal#1155 to plug DNS leaks. XXX Need to figure out where the socks4a.c code should go. fix heimdal#1151
All network traffic to KDC goes through the SOCKS4a proxy if it is configured. This is deliberately kept simple -- and is not generalized to SOCKS4 or SOCKS5 or other types of proxies -- so it is easy to audit for network and DNS leaks. (SOCKS4 works in IP addresses, and so invites DNS leaks. SOCKS5 can be OK, if used judiciously, but takes more work to implement.) XXX Need to audit Heimdal for other kinds of traffic too outside libkrb5. Subsequent changes on this branch will address other parts of libkrb5. XXX Need to combine with heimdal#1155 to plug DNS leaks. XXX Need to figure out where the socks4a.c code should go. fix heimdal#1151
All network traffic to KDC goes through the SOCKS4a proxy if it is configured. This is deliberately kept simple -- and is not generalized to SOCKS4 or SOCKS5 or other types of proxies -- so it is easy to audit for network and DNS leaks. (SOCKS4 works in IP addresses, and so invites DNS leaks. SOCKS5 can be OK, if used judiciously, but takes more work to implement.) XXX Need to audit Heimdal for other kinds of traffic too outside libkrb5. Subsequent changes on this branch will address other parts of libkrb5. XXX Need to combine with heimdal#1155 to plug DNS leaks. XXX Need to figure out where the socks4a.c code should go. fix heimdal#1151
All network traffic to KDC goes through the SOCKS4a proxy if it is configured. This is deliberately kept simple -- and is not generalized to SOCKS4 or SOCKS5 or other types of proxies -- so it is easy to audit for network and DNS leaks. (SOCKS4 works in IP addresses, and so invites DNS leaks. SOCKS5 can be OK, if used judiciously, but takes more work to implement.) This only affects krb5_sendto -- the other initiator of network traffic in libkrb5, krb5_change_password, will be fixed to respect socks4a_proxy in a subsequent commit. XXX Need to figure out where the socks4a.c code should go. fix heimdal#1151
All network traffic to KDC goes through the SOCKS4a proxy if it is configured. This is deliberately kept simple -- and is not generalized to SOCKS4 or SOCKS5 or other types of proxies -- so it is easy to audit for network and DNS leaks. (SOCKS4 works in IP addresses, and so invites DNS leaks. SOCKS5 can be OK, if used judiciously, but takes more work to implement.) This only affects krb5_sendto -- the other initiator of network traffic in libkrb5, krb5_change_password, will be fixed to respect socks4a_proxy in a subsequent commit. XXX Need to figure out where the socks4a.c code should go. fix heimdal#1151
A co-worker found this issue while we were investigating a bug report for kdcproxy related to Apple's copy of Heimdal. Apple's implementation of MS-KKDCP protocol violates the spec and is incompatible with MIT Kerberos, Active Directory, and FreeIPA's kdcproxy. You might want to wait until Apple has acknowledged and fixed the bug. |
Is your feature request related to a problem? Please describe.
kinit, kgetcred, gss_init_sec_context, and applications that use these via libkrb5 or libgssapi or equivalent all do DNS lookups and talk in the clear directly to a KDC over the internet.
This leaks two things:
Describe the solution you'd like
krb5.conf should have an option for connecting to the KDC via TCP through a SOCKS proxy and/or an HTTP CONNECT proxy, leaving all name resolution to the proxy.
This way, all these connections can be done through Tor, for any application that is able to use Tor for connections to the service, or through an ssh -D forward. (Of course, it requires domain-to-realm and realm-to-KDC mapping to be hard-coded in the local krb5.conf, and DNS mapping to be disabled.)
Describe alternatives you've considered
Heimdal currently has an option
http_proxybut it is only used for KDCs reached through HTTP anyway, which I believe is off by default.Heimdal currently has an option
dns_proxybut (a) it only covers the DNS queries (like the service name canonicalization which shouldn't be happening anyway, domain-to-realm mapping, and KDC SRV/A/AAAA records), not communication with the KDC itself, and (b) it is a bizarre protocol that came out of nowhere and probably isn't very useful.Additional context
Portrait of Heimdall apparently wearing some kind of socks, with a chicken on his head
The text was updated successfully, but these errors were encountered: