Re: Looking for a "Kerberos Router"?

[Brent Kimberley via Kerberos]

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 ; Yoann Gini ; Ken 
Hornstein 
Cc: kerberos@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  On Behalf Of Simo Sorce
Sent: Wednesday, March 13, 2024 4:48 PM
To: Yoann Gini ; Ken Hornstein 
Cc: kerberos@mit.edu
Subject: Re: Looking for a "Kerberos Router"?

[You don't often get email from s...@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=05%7C02%7Cbrent.kimberley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b69b1f9da198dc3f16%7C0%7C0%7C638459596905104881%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=4H0nZRxcUm0XdRKqLsydlI06oDz2pfHxBiKC7HxZmv4%3D=0<https://github.com/latchset/kdcproxy>


On Wed, 2024-03-13 at 17:32 +0100, Yoann Gini wrote:
>
> > Le 13 mars 2024 à 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 reasons… 
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail<https://mail/>
> man.mit.edu%2Fmailman%2Flistinfo%2Fkerberos=05%7C02%7Cbrent.kimbe
> rley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b6
> 9b1f9da198dc3f16%7C0%7C0%7C638459596905112923%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> %7C%7C%7C=dZYepxHAXNhDO%2F4F%2FpLx7fDYgT6xEYGEKtjEK7l1H74%3D
> erved=0


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










Kerberos mailing list   Kerberos@mit.edu
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.mit.edu%2Fmailman%2Flistinfo%2Fkerberos=05%7C02%7Cbrent.kimberley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b69b1f9da198dc3f16%7C0%7C0%7C638459596905118780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=dzii88nyGoDkbNfjgCWFYvNUHCh%2B%2FiR4CIc%2FQggCEjs%3D=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.

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

RE: Looking for a "Kerberos Router"?

[Brent Kimberley via Kerberos]

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

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

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

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 à 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 reasons... 
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mail/
> man.mit.edu%2Fmailman%2Flistinfo%2Fkerberos=05%7C02%7Cbrent.kimbe
> rley%40durham.ca%7Cde3f8941d2b64fc0ec6f08dc439ee352%7C52d7c9c2d54941b6
> 9b1f9da198dc3f16%7C0%7C0%7C638459596905112923%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> %7C%7C%7C=dZYepxHAXNhDO%2F4F%2FpLx7fDYgT6xEYGEKtjEK7l1H74%3D
> erved=0


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










Kerberos mailing list   Kerberos@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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Looking for a "Kerberos Router"?

[Simo Sorce]

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 à 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 reasons…
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos


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










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

Re: Looking for a "Kerberos Router"?

[Paul Cayley via Kerberos]

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 
 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  On Behalf Of Ken Hornstein via 
Kerberos
Sent: Wednesday, March 13, 2024 12:22 PM
To: Yoann Gini 
Cc: kerberos@mit.edu
Subject: Re: Looking for a "Kerberos Router"?

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

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

RE: Looking for a "Kerberos Router"?

[Brent Kimberley via Kerberos]

[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  On Behalf Of Ken Hornstein via 
Kerberos
Sent: Wednesday, March 13, 2024 12:22 PM
To: Yoann Gini 
Cc: kerberos@mit.edu
Subject: Re: Looking for a "Kerberos Router"?

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

>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   Kerberos@mit.edu
https://mai

Re: Looking for a "Kerberos Router"?

[Yoann Gini]

> Le 13 mars 2024 à 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 reasons…

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

Re: Looking for a "Kerberos Router"?

[Ken Hornstein via 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

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

Re: Looking for a "Kerberos Router"?

[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?

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

Re: Looking for a "Kerberos Router"?

[Ken Hornstein via 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

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

Re: Looking for a "Kerberos Router"?

[Yoann Gini]

> Le 13 mars 2024 à 15:52, Ken Hornstein  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)

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

Re: Looking for a "Kerberos Router"?

[Yoann Gini]

> Le 13 mars 2024 à 15:44, Marco Rebhan  a écrit :
> 
>> On 13. Mar 2024, at 12:48, Yoann Gini > > 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. 
> 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.

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

Re: Looking for a "Kerberos Router"?

[Ken Hornstein via 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

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

Re: Looking for a "Kerberos Router"?

[Marco Rebhan via Kerberos]

> On 13. Mar 2024, at 12:48, Yoann Gini  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. You’re 
not going to run out of a /64 anytime soon, so the cost should stay constant.

-Marco

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

Re: Looking for a "Kerberos Router"?

[Yoann Gini]

Hello,

> Le 13 mars 2024 à 15:16, Ken Hornstein  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.

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

Re: Looking for a "Kerberos Router"?

[Ken Hornstein via 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

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