[411] in Kerberos-V5-bugs
Re: Some bugs, some questions, and a Next.cf
daemon@ATHENA.MIT.EDU (Andrew Gross)
Wed Jan 26 00:49:01 1994
Date: Tue, 25 Jan 94 21:48:42 -0800
From: Andrew Gross <drew@drew.extern.ucsd.edu>
To: drew@drew.extern.ucsd.edu, marc@MIT.EDU
Cc: krb5-bugs@athena.mit.edu.
> >> krshd/krlogind choose the right pricipal based on the interface being
> >> used
>
> It's not clear to me that krlogind shouldn't always be using the same
> principal for a given host, even if it is multi-homed. It's also not
> clear how to make the client dtrt all the time, either :-/
> Marc
Hello,
I was somewhat unclear about what I was doing; mostly because
I interpreted my problem as the entire multihomed case.
There are two cases as I see it (feel free to add more):
1) Each interface maps: host -> ip -> host
In this case Kerberos doesn't know the difference and we don't need
any changes.
2) One or more interfaces either (a) map host1 -> ip -> host2,
i.e. sluggo-fddi -> 132.249.40.50 -> sluggo ,
or (b) as in a firewall, each interface behaves as a separate machine,
i.e. at home I have a machine called dark with principal
host/dark@DARK.UCSD.EDU for the ethernet interface and a principal
host/drew.extern.ucsd.edu@DARK.UCSD.EDU for the SLIP interface.
It is the case 2(b) that I have a patch for. In this case I have
krlogind (krshd) do a gethostbyname on the IP address that getsockname
returns. kdb5_edit has been modified to extract multiple principals
into the v5srvtab. Thus each case is handled properly. It is not
clear here whether or not the client should be able to do this (for
instance hiding the internals of a network behind a firewall).
In the case 2(a) it seems that the client can handle the naming
problem and that my solution will not work as the gethostbyname will
return the wrong name. It seems wasteful to have the client do two
lookups to get the host2 name but I can't think of a better way to do
it. The client then connects to the IP address but puts host2 into
the kcmd request instead of host1 . I'll argue that one might want to
do this if, say, the FDDI ring is down and sluggo-ether is still
accessable.
Thanks,
Andrew
