Looking for a "Kerberos Router"?

[Yoann Gini]

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

[Grant Taylor]

Post by Yoann Gini
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

[Ken Hornstein]

Post by Yoann Gini
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

[Yoann Gini]

Hello,

Post by Ken Hornstein

Post by Yoann Gini
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.

Post by Ken Hornstein
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.

[Marco Rebhan]

Post by Yoann Gini
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. You’re not going to run out of a /64 anytime soon, so the cost should stay constant.

-Marco

[Ken Hornstein]

Post by Yoann Gini

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

[Yoann Gini]

Post by Marco Rebhan

Post by Yoann Gini
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. You’re 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.

[Yoann Gini]

Post by Ken Hornstein

Post by Yoann Gini

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)

[Ken Hornstein]

Post by Yoann Gini

Post by Ken Hornstein
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

[Yoann Gini]

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?

[Ken Hornstein]

Post by Yoann Gini
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

[Yoann Gini]

Post by Ken Hornstein
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 reasons…

[Brent Kimberley]

[MS-KKDCP]: Kerberos Key Distribution Center (KDC) Proxy Protoco
https learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kkdcp/5bcebb8d-b747-4ee5-9453-428aec1c5c38?source=recommendations

1 Introduction
The Kerberos Key Distribution Center (KDC) Proxy Protocol (KKDCP) is used by an HTTP-based KKDCP server and KKDCP client to relay the Kerberos Network Authentication Service (V5) protocol [RFC4120] and Kerberos change password [RFC3244] messages between a Kerberos client and a KDC.
Note Throughout the remainder of this specification the Kerberos Network Authentication Service (V5) protocol will be referred to simply as Kerberos V5. Kerberos Network Authentication Service (V5) protocol [RFC4120] and Kerberos change password [RFC3244] messages will be referred to simply as Kerberos messages.
Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are normative. All other sections and examples in this specification are informative.

2.1 Transport
Messages are transported by using HTTP POST as specified in [RFC2616]. These messages are sent via Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) by default. The URI uses the virtual directory /KdcProxy unless otherwise configured. The body of the HTTP message contains the KDC_PROXY_MESSAGE (section 2.2.2).
KDC proxy messages are defined using Abstract Syntax Notation One (ASN.1), as specified in [X680], and encoded using Distinguished Encoding Rules (DER), as specified in [X690] section 10.

2.2 Message Syntax
KKDCP does not alter the syntax of any Kerberos messages.

2.2.2 KDC_PROXY_MESSAGE
This structure is a KDC proxy message that contains the Kerberos message to be proxied and optional information for DC location at the KKDCP server.

KDC-PROXY-MESSAGE::= SEQUENCE {
kerb-message [0] OCTET STRING,
target-domain [1] KERB-REALM OPTIONAL,
dclocator-hint [2] INTEGER OPTIONAL
}
kerb-message: A Kerberos message, including the 4 octet length value specified in [RFC4120] section 7.2.2 in network byte order.
target-domain: An optional KerberosString ([RFC4120] section 5.2.1) that represents the realm to which the Kerberos message is sent, which is required for client messages and is not used in server messages. This value is not case-sensitive.
dclocator-hint: An optional Flags ([MS-NRPC] section 3.5.4.3.1) which contains additional data to be used to find a domain controller for the Kerberos message.


5.1 Security Considerations for Implementers
Because KKDCP is typically used in the Internet, messages are only protected when HTTPS is used, and the KKDCP server's certificate is valid. When using HTTP, the KKDCP client is sending clear text Kerberos messages, which are vulnerable to attacks discussed in Kerberos V5 ([RFC4120] section 10), unless FAST [RFC6113] is used.

When the KKDCP server relays messages from Internet KKDCP clients to the KDC, it opens unauthenticated access to the KDC from the Internet, unless TLS client authentication is required. KKDCP servers can also provide some level of protection by only relaying valid Kerberos messages, and by throttling messages. KKDCP servers open KDCs to the Internet, exposing them to denial-of-service attacks (using Kerberos messages) that were previously only possible via other authentication protocols, such as NTLM.


-----Original Message-----
From: Kerberos <kerberos-***@mit.edu> On Behalf Of Ken Hornstein via Kerberos
Sent: Wednesday, March 13, 2024 12:22 PM
To: Yoann Gini <***@gmail.com>
Cc: ***@mit.edu
Subject: Re: Looking for a "Kerberos Router"?

Post by Yoann Gini
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
________________________________________________
Kerberos mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

[Paul Cayley]

See RFC 4559 and related 
MS support keep via https
Quest Vintela and others field kit that supports this
IBM and SiteMider have guidance and support





On Wednesday, March 13, 2024, 9:56 AM, Brent Kimberley via Kerberos <***@mit.edu> wrote:

[MS-KKDCP]: Kerberos Key Distribution Center (KDC) Proxy Protoco
https learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kkdcp/5bcebb8d-b747-4ee5-9453-428aec1c5c38?source=recommendations

1 Introduction
The Kerberos Key Distribution Center (KDC) Proxy Protocol (KKDCP) is used by an HTTP-based KKDCP server and KKDCP client to relay the Kerberos Network Authentication Service (V5) protocol [RFC4120] and Kerberos change password [RFC3244] messages between a Kerberos client and a KDC.
Note  Throughout the remainder of this specification the Kerberos Network Authentication Service (V5) protocol will be referred to simply as Kerberos V5. Kerberos Network Authentication Service (V5) protocol [RFC4120] and Kerberos change password [RFC3244] messages will be referred to simply as Kerberos messages.
Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are normative. All other sections and examples in this specification are informative.

2.1 Transport
Messages are transported by using HTTP POST as specified in [RFC2616]. These messages are sent via Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) by default. The URI uses the virtual directory /KdcProxy unless otherwise configured. The body of the HTTP message contains the KDC_PROXY_MESSAGE (section 2.2.2).
KDC proxy messages are defined using Abstract Syntax Notation One (ASN.1), as specified in [X680], and encoded using Distinguished Encoding Rules (DER), as specified in [X690] section 10.

2.2 Message Syntax
KKDCP does not alter the syntax of any Kerberos messages.

2.2.2 KDC_PROXY_MESSAGE
This structure is a KDC proxy message that contains the Kerberos message to be proxied and optional information for DC location at the KKDCP server.

KDC-PROXY-MESSAGE::= SEQUENCE {
    kerb-message          [0] OCTET STRING,
    target-domain          [1] KERB-REALM OPTIONAL,
    dclocator-hint        [2] INTEGER OPTIONAL
}
kerb-message: A Kerberos message, including the 4 octet length value specified in [RFC4120] section 7.2.2 in network byte order.
target-domain: An optional KerberosString ([RFC4120] section 5.2.1) that represents the realm to which the Kerberos message is sent, which is required for client messages and is not used in server messages. This value is not case-sensitive.
dclocator-hint: An optional Flags ([MS-NRPC] section 3.5.4.3.1) which contains additional data to be used to find a domain controller for the Kerberos message.


5.1 Security Considerations for Implementers
Because KKDCP is typically used in the Internet, messages are only protected when HTTPS is used, and the KKDCP server's certificate is valid. When using HTTP, the KKDCP client is sending clear text Kerberos messages, which are vulnerable to attacks discussed in Kerberos V5 ([RFC4120] section 10), unless FAST [RFC6113] is used.

When the KKDCP server relays messages from Internet KKDCP clients to the KDC, it opens unauthenticated access to the KDC from the Internet, unless TLS client authentication is required. KKDCP servers can also provide some level of protection by only relaying valid Kerberos messages, and by throttling messages. KKDCP servers open KDCs to the Internet, exposing them to denial-of-service attacks (using Kerberos messages) that were previously only possible via other authentication protocols, such as NTLM.


-----Original Message-----
From: Kerberos <kerberos-***@mit.edu> On Behalf Of Ken Hornstein via Kerberos
Sent: Wednesday, March 13, 2024 12:22 PM
To: Yoann Gini <***@gmail.com>
Cc: ***@mit.edu
Subject: Re: Looking for a "Kerberos Router"?

Post by Yoann Gini
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
________________________________________________
Kerberos mailing list          ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

________________________________________________
Kerberos mailing list          ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

[Simo Sorce]

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

Post by Yoann Gini

Post by Ken Hornstein
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 reasons…
________________________________________________
https://mailman.mit.edu/mailman/listinfo/kerberos

[Brent Kimberley]

To the best of my knowledge, all IPV6 ports should be closed by design and only opened if/when approved.

-----Original Message-----
From: Kerberos <kerberos-***@mit.edu> On Behalf Of Simo Sorce
Sent: Wednesday, March 13, 2024 4:48 PM
To: Yoann Gini <***@gmail.com>; Ken Hornstein <***@cmf.nrl.navy.mil>
Cc: ***@mit.edu
Subject: Re: Looking for a "Kerberos Router"?

[You don't often get email from ***@redhat.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

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

Post by Yoann Gini

Post by Ken Hornstein
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 reasons... ________________________________________________
https://mail/
man.mit.edu%2Fmailman%2Flistinfo%2Fkerberos&data=05%7C02%7Cbrent.kimbe
rley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b6
9b1f9da198dc3f16%7C0%7C0%7C638459596905112923%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
%7C%7C%7C&sdata=dZYepxHAXNhDO%2F4F%2FpLx7fDYgT6xEYGEKtjEK7l1H74%3D&res
erved=0

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









________________________________________________
Kerberos mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

[Brent Kimberley]

The site philosophy can be expressed as fail open / fail closed /fail safe / fail deadly...
________________________________
From: Brent Kimberley
Sent: Wednesday, March 13, 2024 5:41:58 PM
To: Simo Sorce <***@redhat.com>; Yoann Gini <***@gmail.com>; Ken Hornstein <***@cmf.nrl.navy.mil>
Cc: ***@mit.edu <***@mit.edu>
Subject: RE: Looking for a "Kerberos Router"?

To the best of my knowledge, all IPV6 ports should be closed by design and only opened if/when approved.

-----Original Message-----
From: Kerberos <kerberos-***@mit.edu> On Behalf Of Simo Sorce
Sent: Wednesday, March 13, 2024 4:48 PM
To: Yoann Gini <***@gmail.com>; Ken Hornstein <***@cmf.nrl.navy.mil>
Cc: ***@mit.edu
Subject: Re: Looking for a "Kerberos Router"?

[You don't often get email from ***@redhat.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

This is well tested:
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flatchset%2Fkdcproxy&data=05%7C02%7Cbrent.kimberley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b69b1f9da198dc3f16%7C0%7C0%7C638459596905104881%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4H0nZRxcUm0XdRKqLsydlI06oDz2pfHxBiKC7HxZmv4%3D&reserved=0<https://github.com/latchset/kdcproxy>

Post by Yoann Gini

Post by Ken Hornstein
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 reasons… ________________________________________________
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail<https://mail/>
man.mit.edu%2Fmailman%2Flistinfo%2Fkerberos&data=05%7C02%7Cbrent.kimbe
rley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b6
9b1f9da198dc3f16%7C0%7C0%7C638459596905112923%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
%7C%7C%7C&sdata=dZYepxHAXNhDO%2F4F%2FpLx7fDYgT6xEYGEKtjEK7l1H74%3D&res
erved=0

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









________________________________________________
Kerberos mailing list ***@mit.edu
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.mit.edu%2Fmailman%2Flistinfo%2Fkerberos&data=05%7C02%7Cbrent.kimberley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b69b1f9da198dc3f16%7C0%7C0%7C638459596905118780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dzii88nyGoDkbNfjgCWFYvNUHCh%2B%2FiR4CIc%2FQggCEjs%3D&reserved=0<https://mailman.mit.edu/mailman/listinfo/kerberos>
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.