From Newsgroup: comp.protocols.kerberos

Hello,

I'm looking for a way to "route" Kerberos requests incoming to a single IP to different backend depending on the requested realms.

This issue I'm trying to solve is related to the scalability of automated deployment for new Kerberos realms on a cloud infrastructure.

My company is an IDP startup where we currently rely only on mTLS and WebAuthN only (no password support at all), and we would also like to support also Kerberos with PKINIT.

However, as a SaaS company, we need to think at the scalability and integration in our deployment pattern. Currently our production clusters use TLS SNI to evaluate incoming communication and to route them to the appropriate tenant.

Which allow us to have end to end TLS communication between our customers and their tenant. Which is mandatory for our mTLS. But without consuming one public IP per tenant to keep cost under control.

Here with Kerberos, I'm wondering how we can achieve something equivalent, using a shared IP for multiple Kerberos realms and having the incoming requests routed to the appropriate backend by some kind of inspection.

Current solution we seen require to write custom decoder for existing ingress solutions. But before going that way I prefer to ask if another solution exist.

Is there a way to deploy some kind of proxy/router in between clients on a public network and different KDC inside our different Kubernetes namespaces?

Best regards
Yoann Gini
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On 3/13/24 06:48, Yoann Gini wrote:

I'm looking for a way to "route" Kerberos requests incoming to a single
IP to different backend depending on the requested realms.

I don't have a direct answer to your question.

But I thought that you could host multiple Kerberos realm databases on
the same server and that the client + server would mostly transparently
work with this.

With this in mind I would wonder if it's possible to have a (set of)
front end systems replicate from multiple back end systems as a common
point of access.

I could easily be wrong.

NeedMoreCOFFEE
--
Grant. . . .
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Here with Kerberos, I'm wondering how we can achieve something
equivalent, using a shared IP for multiple Kerberos realms and having
the incoming requests routed to the appropriate backend by some kind of >inspection.

I think that is certainly _possible_, but I don't believe there is
anything that does that today. You'd have to parse the Kerberos message
(which is ASN.1 and there are plenty of things that can handle that)
and extract out the realm of the server principal and route the message appropriately. One thing that leaps out at me is that by default a lot
of Kerberos messages default to UDP transport so that might be a bit
trickier to proxy them (but not impossible).

--Ken
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Hello,

Le 13 mars 2024 |a 15:16, Ken Hornstein <kenh@cmf.nrl.navy.mil> a |-crit :

Here with Kerberos, I'm wondering how we can achieve something
equivalent, using a shared IP for multiple Kerberos realms and having
the incoming requests routed to the appropriate backend by some kind of
inspection.

I think that is certainly _possible_, but I don't believe there is
anything that does that today. You'd have to parse the Kerberos message (which is ASN.1 and there are plenty of things that can handle that)
and extract out the realm of the server principal and route the message appropriately.

Yes, that's the main option we see so far, but before jumping on the "let write our own proxy" solution I wanted to be sure that we don't miss something like proxy feature in an Kerberos implementation or some kind of cascading scenario.

One thing that leaps out at me is that by default a lot
of Kerberos messages default to UDP transport so that might be a bit
trickier to proxy them (but not impossible).

Yes, that's another aspect of the issue, our expectations so far are on support for TCP only clients. Since it's for mobile users that we are looking to have this support, it shouldn't be an issue.
Thanks.--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On 13. Mar 2024, at 12:48, Yoann Gini <yoann.gini@gmail.com> wrote:

Which allow us to have end to end TLS communication between our customers and their tenant. Which is mandatory for our mTLS. But without consuming one public IP per tenant to keep cost under control.

Here with Kerberos, I'm wondering how we can achieve something equivalent, using a shared IP for multiple Kerberos realms and having the incoming requests routed to the appropriate backend by some kind of inspection.

Set it up with a publicly routable IPv6 network, with one IP per tenant. YourCOre not going to run out of a /64 anytime soon, so the cost should stay constant.

-Marco
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

One thing that leaps out at me is that by default a lot of Kerberos
messages default to UDP transport so that might be a bit trickier to
proxy them (but not impossible).

Yes, that's another aspect of the issue, our expectations so far are on >support for TCP only clients. Since it's for mobile users that we are
looking to have this support, it shouldn't be an issue.

I would caution you that I think that is something you're going to have
to grapple with much sooner than you think.

A long time ago we had developed a small Kerberos proxy that forwarded
on Kerberos messages by prepending the source IP address/port to the
UDP message (our KDC at the time was modified to recognize this
and sent the prepended bytes back to the proxy so it could send it to
the correct originator).

--Ken
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Le 13 mars 2024 |a 15:44, Marco Rebhan <me@dblsaiko.net> a |-crit :

On 13. Mar 2024, at 12:48, Yoann Gini <yoann.gini@gmail.com <mailto:yoann.gini@gmail.com>> wrote:

Which allow us to have end to end TLS communication between our customers and their tenant. Which is mandatory for our mTLS. But without consuming one public IP per tenant to keep cost under control.

Here with Kerberos, I'm wondering how we can achieve something equivalent, using a shared IP for multiple Kerberos realms and having the incoming requests routed to the appropriate backend by some kind of inspection.

Set it up with a publicly routable IPv6 network, with one IP per tenant. YourCOre not going to run out of a /64 anytime soon, so the cost should stay constant.

That's an option not reachable so far.
I don't know in your country but in France and EU for what I see so far, we are really really late on IPv6.
OVH in France does not offer IPv6 on Kubernetes cluster, and most home router does not have it enabled.
It would have been my first choice indeed. When we started this project a year ago we for sure decided to be dual stack, but we couldn't afford the limitation set by others on the lack of spread of IPv6.--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Le 13 mars 2024 |a 15:52, Ken Hornstein <kenh@cmf.nrl.navy.mil> a |-crit :

One thing that leaps out at me is that by default a lot of Kerberos
messages default to UDP transport so that might be a bit trickier to
proxy them (but not impossible).

Yes, that's another aspect of the issue, our expectations so far are on
support for TCP only clients. Since it's for mobile users that we are
looking to have this support, it shouldn't be an issue.

I would caution you that I think that is something you're going to have
to grapple with much sooner than you think.

A long time ago we had developed a small Kerberos proxy that forwarded
on Kerberos messages by prepending the source IP address/port to the
UDP message (our KDC at the time was modified to recognize this
and sent the prepended bytes back to the proxy so it could send it to
the correct originator).

OK, did you had to support iOS and macOS endpoint on that context? (we are looking for Kerberos support for them, to use with Apple SSO Kerberos features)--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

A long time ago we had developed a small Kerberos proxy that forwarded
on Kerberos messages by prepending the source IP address/port to the
UDP message (our KDC at the time was modified to recognize this and
sent the prepended bytes back to the proxy so it could send it to the
correct originator).

OK, did you had to support iOS and macOS endpoint on that context?
(we are looking for Kerberos support for them, to use with Apple SSO
Kerberos features)

This WAY predated iOS! (the proxy was for the Kerberos 4 protocol) But
I can say with certainty that the MacOS X Kerberos libraries (based on
Heimdal) will default to UDP in many cases. And on MacOS X you can run
into a case where you might be using a different Kerberos implementation
than the operating system libraries.

--Ken
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Looking at Apple documentation I see the support for something I had never heard of: Kerberos Key Distribution Center Proxy.

Looks like a solution to encapsulate Kerberos requests into an HTTPS.

Any experience on this here?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Looking at Apple documentation I see the support for something I had
never heard of: Kerberos Key Distribution Center Proxy.

Looks like a solution to encapsulate Kerberos requests into an HTTPS.

Any experience on this here?

I personally have not used that, but I know that MIT Kerberos supports
that (as far as I can tell, that protocol exists just because firewall
people are dumb, but that's neither here nor there). That contains
a wrapper ASN.1 structure which has the target realm in it so you
could use that for routing (although the target domain is listed as an
optional element to the KDC_PROXY_MESSAGE so that suggests to me you
can't rely on it). So you're still going to have to write code to parse
an ASN.1 structure to do backend routing.

It does occur to me that maybe if you have different KDC hostnames but
the same IP address you could use TLS SNI or hostname routing which
you indicated you already use and maybe that would be simpler? That
presumes the client implementations set the SNI field (I see that it
does send a "Host" header, and it looks like MIT Kerberos does set the
SNI hostname).

--Ken
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Le 13 mars 2024 |a 17:21, Ken Hornstein <kenh@cmf.nrl.navy.mil> a |-crit :

It does occur to me that maybe if you have different KDC hostnames but
the same IP address you could use TLS SNI or hostname routing which
you indicated you already use and maybe that would be simpler? That
presumes the client implementations set the SNI field (I see that it
does send a "Host" header, and it looks like MIT Kerberos does set the
SNI hostname).

This is what I have in mind looking at the documentation of kkdcp (reading as exchanging here). Using SNI to select the KDC.
I will give it a try, it looks like the option I need here.
And yes, all of those complexities would have been avoided by network teams just supporting IPv6 and not blocking random ports for no reasonsrCa--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

This is well tested:
https://github.com/latchset/kdcproxy


On Wed, 2024-03-13 at 17:32 +0100, Yoann Gini wrote:

Le 13 mars 2024 |a 17:21, Ken Hornstein <kenh@cmf.nrl.navy.mil> a |-crit :

It does occur to me that maybe if you have different KDC hostnames but
the same IP address you could use TLS SNI or hostname routing which
you indicated you already use and maybe that would be simpler? That presumes the client implementations set the SNI field (I see that it
does send a "Host" header, and it looks like MIT Kerberos does set the
SNI hostname).

This is what I have in mind looking at the documentation of kkdcp (reading as exchanging here). Using SNI to select the KDC.

I will give it a try, it looks like the option I need here.

And yes, all of those complexities would have been avoided by network teams just supporting IPv6 and not blocking random ports for no reasonsrCa
________________________________________________
Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos

--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc









--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Thank you, I will put this on test.

This is well tested:
https://github.com/latchset/kdcproxy
On Wed, 2024-03-13 at 17:32 +0100, Yoann Gini wrote:

Le 13 mars 2024 |a 17:21, Ken Hornstein a |-crit :

It does occur to me that maybe if you have different KDC hostnames but

the same IP address you could use TLS SNI or hostname routing which

you indicated you already use and maybe that would be simpler? That

presumes the client implementations set the SNI field (I see that it

does send a "Host" header, and it looks like MIT Kerberos does set the

SNI hostname).

This is what I have in mind looking at the documentation of kkdcp (reading as exchanging here). Using SNI to select the KDC.



I will give it a try, it looks like the option I need here.



And yes, all of those complexities would have been avoided by network teams just supporting IPv6 and not blocking random ports for no reasonsrCa

One thing that leaps out at me is that by default a lot of Kerberos

messages default to UDP transport so that might be a bit trickier to

proxy them (but not impossible).
https://www.vpnpalvelut.com/

Yes, that's another aspect of the issue, our expectations so far are on

support for TCP only clients. Since it's for mobile users that we are

looking to have this support, it shouldn't be an issue.



I would caution you that I think that is something you're going to have


to grapple with much sooner than you think.



A long time ago we had developed a small Kerberos proxy that forwarded


on Kerberos messages by prepending the source IP address/port to the


UDP message (our KDC at the time was modified to recognize this


and sent the prepended bytes back to the proxy so it could send it to


the correct originator).--- Synchronet 3.21d-Linux NewsLink 1.2