[1044] in Kerberos_V5_Development
full explanation of proposed krb5_sname_to_princ change
daemon@ATHENA.MIT.EDU (Sam Hartman)
Mon Apr 1 11:50:35 1996
To: krbdev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 01 Apr 1996 11:50:22 -0500
Ted asked me to go through the background of my proposed
change, then to fully explain what I was trying to do.
Basically, I'm trying to solve the problem of machines that
have multiple A records in DNS--machines like athena.dialup.mit.edu,
et al. Newer versions of Bind tend to round-robbin these addresses,
so you are likely to get different answers if you call gethostbyname()
on the same domain twice in a row.
The current model works as follows:
* gethostbyname() to decide what to connect to.
* connect
* in krb5_sname_to_princ, call gethostbyname() again to get the
cannonical name to use for the Kerberos principal.
So, if you connect to vongole, you are likely to get marinara
tickets. This confuses users significantly, because it never works.
My proposal is to somehow save the address you actually
connect to, and do a gethostbyaddr on this address. The
cannonicalization of this address should be the specific name of the
host you actually connected to. It is important to note that this
will still work if you actually use the name athena.dialup.mit.edu as
the official name for multiple hosts, although you will have to have a
host/athena.dialup.mit.edu key on each host.
The case in which my proposal works worse than the current
system is if you have multiple different PTR records for the same IP
address. Honestly, I think multiple A records is so much more useful
than multiple PTR records for the same name (is that even legal?) that
this is a minor concern.
It may also create a problem if you try to connect to a host
that doesn't support reverse-resolution correctly, but I think several
other things break in this situation as well.
Another problem with the proposal is that GSS_NT_SERVICE names
in GSSAPI are not dealt with. I do not have a solution for GSSAPI; I
suspect that there is not a good answer.
As far as actual interface changes, I don't want to take a
sockaddr_in on a krb5 call. Instead, I would rather take a
krb5_address. Unfortunately, there isn't a good API to generate these
from a sockaddr_in. Also, as I was thinking about things, I realized
that you normally want to set up an auth context,call
krb5_sname_to_princ, call krb5_mk_req or krb5_sendauth, etc. As part
of setting up the context, you call krb5_genfulladdrs. So, it sounds
reasonable to me for there to be a version of krb5_sname_to_princ that
took an authcontext instead of a hostname; it would get the IP address
from the authcontext.
--Sam
