Looking for a "Kerberos Router"?

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

[You don't often get email from kerberos at 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 at 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 at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos