Peter Saint-Andre wrote:
XMPP ROUTER
/ | \
CM CM CM
\ | /
LOAD BALANCER
/ | \
C C C
The problem is that a client doesn't know which CM it has connected to
(e.g., cm6.example.com), since that information is hidden by the load
balancer in the middle (all clients appear to be connected to the IP
address of the load balancer). For non-Kerberos deployments that doesn't
matter, but it does matter for Kerberos deployments since a client needs
to know the address of its service.
I never liked hostbased service names ;-)
For "old-fashioned" 2-token Kerberos authentication (which is the
authentication exchange currently covered by the official Kerberos 5
gssapi mechanisms (rfc-1964 and rfc-4121), the sharing of the
server credentials is a problem. (session replay to servers sharing
credentials but not sharing the replay cache).
If Kerberos user2user authentication is used (exclusively), such a
vulnerability from sharing the server credentials does not exist.
Microsoft has implemented the 3-token user2user authentication exchange
in addition to the 2-token authentication exchange of the IETF-defined
Kerberos 5 gssapi mechanism, it has already been available in Windows 2000.
The correct approach of using the 2-token exchange in a distributed
environment was implemented by DCE many many years ago, but requires
a secure directory, something not available in traditional Kerberos.
The most sensible and infrastructure-independent approach (i.e. independent
of how load-balancing is done within the backend and where within
the backend the secure communication is terminated) for traditional
Kerberos authentication would be to standardize the user2user
authentication exchange and use that (no use of _hostbased_
service names).
Today, this option is only available if you go proprietary
(or implementation-specific).
