[1777] in Kerberos_V5_Development
Re: protocol flaw (160 lines) (was: krbdev vs krbcore)
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Sat Sep 21 22:28:15 1996
To: "Donald T. Davis" <don@cam.ov.com>
Cc: "Barry Jaspan" <bjaspan@MIT.EDU>, krbcore@MIT.EDU
In-Reply-To: Your message of "Sat, 21 Sep 1996 21:12:59 EDT."
<199609220113.VAA25633@gza-client1.cam.ov.com>
Date: Sat, 21 Sep 1996 22:28:08 EDT
From: Marc Horowitz <marc@MIT.EDU>
In message <199609220113.VAA25633@gza-client1.cam.ov.com>, "Donald T. Davis" <don@cam.ov.com> writes:
>> marc, i'm concerned here to stay within krb's original
>> design goals: dataless workstations, mobile users.
I don't see how anything I've said violates those goals.
>> further, this is not only a login/xdm problem; i usually
>> encounter the problem when i'm using kerberized telnet
>> on a dialup server.
when you telnet from host A to host B, it is actually login (run by
telnetd), not telnetd itself, which prompts for the username and
password. So, fixing login fixes telnet.
>> i can see that this is sort of a protocol change, but it's a minor
>> one, and it seems a lot cleaner than using the dummy+preauth hack.
It's not "sort of" a protocol change. It will cause every deployed
krb5 client to stop working. This would be unacceptable to my
customers, and probably yours and everyone elses. The complexity
added is small, and invisible to both users and admins.
>> i'm not wild about marc's hesiod-based fix, just because i'd rather
>> not couple krb tightly to hesiod. i have nothing against hesiod,
>> but not every krb site will necessarily want to have to adopt it.
>> am i correct in believing that krb doesn't currently depend on
>> hesiod's availability?
My fix does not couple kerberos to hesiod at all. it simply
recognises that hesiod is vulnerable to the same problem, and attempts
to fix it there, too. Sites which use only one will get a fix, and
sites which use both will have both holes plugged. It introduces no
coupling.
Marc
