SOCKS and/or HTTP CONNECT proxy

[riastradh]

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:

1. the realm you're logging into and the principal you're logging in as, to anyone on the network between you and the KDC, such as eavesdroppers sitting across the coffee shop; and
2. your location (IP address), to the KDC.

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_proxy but it is only used for KDCs reached through HTTP anyway, which I believe is off by default.

Heimdal currently has an option dns_proxy but (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

[lhoward]

IAKERB would be better, no?

[riastradh]

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!)

1. How does that help with kinit?

2. Does Heimdal support IAKERB?

   Looks like no (should perhaps file a separate issue for that!) -- and I suspect the effort to implement SOCKS proxy support would be considerably less.

3. How widely deployed is IAKERB in services?

[lhoward]

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.

[nicowilliams]

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 s2n into Heimdal so that we can make a GSS-API mechanism that speaks TLS when no application framing is added -- that's basically what SChannel is, but with SSPI instead of GSS. So I'd be inclined to use s2n to implement KDC-over-HTTPS.

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!)

Correct.

1. How does that help with kinit?

Well, it doesn't, unless you defer kinit till gss_init_sec_context() time or have a GSS mechanism you can use as a kinit of sorts.

2. Does Heimdal support IAKERB?
   Looks like no (should perhaps file a separate issue for that!) -- and I suspect the effort to implement SOCKS proxy support would be considerably less.

Heimdal does not support IAKERB, no.

3. How widely deployed is IAKERB in services?

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:

• kinit as an HTTPS service

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 (kdc/bx509d.c) which implements an online CA, but also a /get-ticket end-point that uses... the CA internally to mint a PKINIT client certificate then uses that to get a ticket using PKINIT. Now, it's written in C, and I'd rather we stop writing at least new services in C and go to something more memory safe, and it doesn't support random authentication mechanisms either. But if you have a suitable HTTP server that can do TLS and FIDO/UDF, then it's a great starting point.

To some degree I'm asking: why even bother with Kerberos? Well, there's a few reasons, though not all exactly compelling:

• post-quantum a Needham-Schröder protocol could be used to amortize the cost of slow/bulky PK
• installed base

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:

• Kerberos principal names
• key exchange
• 1, 2, and 3 message protocol options

but also to extend JWT so that it has a standard fetch-a-token protocol that browsers and other HTTP user-agents can follow.

[lhoward]

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.

[nicowilliams]

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 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.

[SteveSyfuhs]

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: ***@***.***>

[nicowilliams]

Good news! Futurama.gif

:)

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.

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.

[riastradh]

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, IAKERB.)

[SteveSyfuhs]

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: ***@***.***>

[nicowilliams]

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.

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.

[tiran]

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.

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.