[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 <[email protected]> On Behalf Of Ken Hornstein via
Kerberos
Sent: Wednesday, March 13, 2024 12:22 PM
To: Yoann Gini <[email protected]>
Cc: [email protected]
Subject: Re: Looking for a "Kerberos Router"?
[You don't often get email from [email protected]. 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 [email protected]
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 [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
