[1889] in Kerberos-V5-bugs
Re: ss-960411 Checksum Problems
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Apr 18 18:18:46 1996
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: Sam Hartman <hartmans@MIT.EDU>, Doug Engert <DEEngert@anl.gov>,
krb5-bugs@MIT.EDU, raeburn@cygnus.com
From: Sam Hartman <hartmans@MIT.EDU>
Date: 18 Apr 1996 18:18:37 -0400
In-Reply-To: "Theodore Y. Ts'o"'s message of Thu, 18 Apr 1996 13:54:34 -0400
>>>>> ""Theodore" == "Theodore Y Ts'o" <tytso@MIT.EDU> writes:
"Theodore> Apparently, pre-Beta5 clients generate bogus
"Theodore> checksums. Considering that we are still in beta, and
"Theodore> that there is substancially enhanced security if you
"Theodore> use checksums, I strongly believe that checksums should
"Theodore> be used if supplied.
"Theodore> Well, the problem is that most of the people who are
"Theodore> using Kerberos V5 today are using pre-beta5 clients.
"Theodore> Not too many people are using beta 5, since it's a
"Theodore> pretty broken release. As a result, I don't want to
"Theodore> cause to much backwards compatibility headaches.
"Theodore> I'd much rather see the code #ifdef'ed to allow
"Theodore> compatibility with pre-beta5 clients, and advertise
"Theodore> that this is a provisional limited-time feature, thus
"Theodore> encouraging people to upgrade. In a future release, we
"Theodore> can turn off this backwards compatibility fix.
I would like you to reconsider this for the following reasons:
* People are already going to have to adjust their rlogind
configurations to deal with the options changes advertized on krbdev
and comp.protocols.kerberos back in January. Therefore, now is a good
time to get people to revisit the options they use and make them aware
of new issues.
* I would argue that considering sysadmins are already going to have
to look at the new options structure, requiring them to make a
concious decision to support backward compatability at a security cost
is reasonable.
* I don't think it is ever a good idea to have the default behavior
create security exposures.
* Your solution precludes an operational mode that I would argue is
useful. In the old code with -54 or -54e in use, the security of the
connection was dependent on the client. I.E. a new client with a -54e
server was secure. Under your proposed solution, using a -54e server
would be insecure regardless of the client security. The advantage of
allowing the client to be the determining factor in the security of a
connection when talking to a new server is that it allows
administrators to use newer clients while allowing principals with
less authorization to use older clients. (Unfortunately, this isn't
as useful as I hoped it would be, because sufficiently old clients
will not work with a -54 server. However, I still think it is useful
enough to be supported.)
* The krlogind option structure is much cleaner now, and adding a -i
(ingore checksums) options wouldn't make things much more complicated.
If a user can't configure the new krlogind, they will have a difficult
time setting up krb5.conf, etc.
"Theodore> This would involve backing out Ken's patch. In
"Theodore> particular, the warning if you have -54c would
"Theodore> reappear--you should never require checksums if you are
"Theodore> enabling Kerberos4, and then adding the new backward
"Theodore> compatability option that would have the same behavior
"Theodore> Ken has the mainline code path currently take.
"Theodore> The problem with the old way of doing things was that
"Theodore> even if you were using Kerberos V5, and you had a valid
"Theodore> checksum, krlogin was still issueing the same the
"Theodore> warning syslog for no good reason. That was broken.
I think it's perfectly reasonable to warn about a combination
of options that is internally inconsistent. I.E. my point is that the
combination -54c is equivelent to -54, because you do not gain any
additional security over -54 if checksums are validated when present.
I realize that backward compatability makes this difficult, and
requires this to be rethought, but I argue that under the old
code, -54c was almost certainly a user error. It is reasonable to
warn users that they should rethink their options and settle on -5c or
-54, but not try to combine basically incompatible operating modes.
"Theodore> As far as checksum security and Kerberos V4, the place
"Theodore> to warn system administrators about that sort of thing
"Theodore> is in the documentation, not by causing a syslog to
"Theodore> appear every single time someone logs in using Kerberos
"Theodore> V4.
It's in the documentation as well.
"Theodore> - Ted
Thanks for your time,
--Sam
