[2423] in Kerberos-V5-bugs
Re: pending/154: krb4 interface too lax in security
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri Nov 8 14:55:04 1996
Date: Fri, 8 Nov 1996 14:54:29 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Marc Horowitz <marc@MIT.EDU>
Cc: John Gardiner Myers <jgm@CMU.EDU>, krb5-bugs@MIT.EDU,
gnats-admin@rt-11.MIT.EDU, krb5-prs@rt-11.MIT.EDU,
"Theodore
Y. Ts'o" <tytso@MIT.EDU>
In-Reply-To: Marc Horowitz's message of Tue, 05 Nov 1996 21:21:11 EST,
<9611060221.AA14563@bill-the-cat.MIT.EDU>
Date: Tue, 05 Nov 1996 21:21:11 EST
From: Marc Horowitz <marc@MIT.EDU>
I say don't beat around the bush. If you want to turn off the v4
in_tkt code, then we should have a flag which does just and exactly
that. The semantics are a lot cleaner than a flag which says "whether
or not arbitrary salts are ok", which is going to be meaningless to
95% of the users.
Yes, especially if you have krb524 running, a flag which means "don't do
V4 AS requests" seems like a reasonable thing to do. As long as you
allow V4 transactions, the amount of security this buys you is minimal;
people can still attack the V4 TGT key, but it's better than nothing.
In the long run I suppose we could imagine a V4 library where all of the
V4 tickets are obtained via krb524d, and the V4 compatibility code is
turned off completely. This prevents an attack on the V4 TGT, so
attackers would have to break each single DES V4 service key
individually. After we get triple-DES support in, it might make sense
for an especially paranoid site to use this as an option.
Most of this sounds like a post 1.0 issue, though....
- Ted
