[1052] in Kerberos_V5_Development
Re: full explanation of proposed krb5_sname_to_princ change
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sat Apr 13 14:52:55 1996
To: "Theodore Ts'o" <tytso@MIT.EDU>
Cc: Sam Hartman <hartmans@MIT.EDU>, krbdev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 13 Apr 1996 14:52:39 -0400
In-Reply-To: Theodore Ts'o's message of Thu, 11 Apr 1996 12:15:33 -0400
>>>>> "Theodore" == Theodore Ts'o <tytso@MIT.EDU> writes:
First of all, sorry about the incredibly broken quoting on my
last message. Emacs 19.30 does interesting things with adaptive-fill
that I didn't expect.
Theodore> The only case where your solution would work and mine
Theodore> would fail is if athena.dialup.mit.edu resolves one of
Theodore> the above three addresses --- but so do
Theodore> dialup-1.mit.edu, dialup-2.mit.edu, and
Theodore> dialup-3.mit.edu. But I'd just as soon consider that a
Theodore> pathalogical case, and not deal with it. I can't think
Theodore> of a good excuse for doing anything like that.
Agreed that this is the only different case.
One other DNS question before I go ahead an implement the
cannonicalization function. How do we (medium-term, before secure DNS
is deployed) want to handle the problem of deciding whether the server
principal we are mutually authenticating to is a reasonable principal
for the input the user gave. This wasn't a major problem before
forwarded tickets started working enough of the time to be useful.
However, it's all too easy to spoof DNS. Picture the following
scenerio:
* an administrator does something along the lines of rlogin
moira2.mit.edu -l root -x -f
* The DNS query returns moira2.mit.edu is a cname for charon.mit.edu.
* The system cannonicalizes charon, finding it resolves to itself
(charon.mit.edu)
* The client forwards tickets to charon.mit.edu
I don't really see that these problems need to be related, but
we might as well decide how to deal with all DNS issues then implement
as time permit, so that if there are any interactions we can deal with
them.
--Sam
