Re: domain-based service names redux
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: domain-based service names redux



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).


-Martin


_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.