[3776] in Release_7.7_team
Kerberos v4 Interrealm disabled from Athena KDCs: potentially affects AFS and Zephyr use
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Mon Mar 17 00:32:18 2003
Message-Id: <200303170532.AAA32614@riff-raff.mit.edu>
To: ops@MIT.EDU, release-team@MIT.EDU
X-Bcc-To: athena-outage@mit.edu
Reply-To: release-team@MIT.EDU
Date: Mon, 17 Mar 2003 00:32:10 -0500
From: Garry Zacheiss <zacheiss@MIT.EDU>
Earlier today, vulnerabilities in the Kerberos v4 protocol were
made public. These vulnerabilities specifically affect support for
interrealm authentication in Kerberos v4; please see:
http://lists.netsys.com/pipermail/full-disclosure/2003-March/004525.html
for detailed information regarding the vulnerabilities.
As a result of this disclosure, Kerberos v4 interrealm support
has been disabled on the ATHENA.MIT.EDU KDCs. This change will not
affect Athena users authenticating to Athena services.
This change may affect AFS and Zephyr use in some cases, and
those cases are detailed below.
1.) Use of interrealm Zephyr.
Users who authenticate directly to the MIT zephyr servers using a
non-ATHENA.MIT.EDU Kerberos principal; for example, by kinit'ing as a
non-ATHENA.MIT.EDU principal on an Athena workstation or a non-Athena
workstation whose zhm is pointed at the MIT zephyr servers will not be
able to get subscriptions, instead receiving an error of the form:
zwgc: Kerberos principal unknown while setting location
zwgc: Kerberos principal unknown while loading subscription files
Users at sites who participate in MIT zephyr via server-to-server
interrealm (several CMU.EDU realms, etc.) will experience some slightly
confusing behavior. When the zephyr servers for the remote realm have
their authentication expire sometime early Monday morning, these users
will no longer be able to get subscriptions at MIT, although they will
still be able to send unauthentically. MIT users will be likewise
affected when attempting to send or receive zephyrs from remote realms
that have disabled Kerberos v4 interrealm.
There is no workaround available in either case.
2.) Authentication to MIT AFS cells from a non-ATHENA.MIT.EDU Kerberos
principal.
Effectively immediately, users who do this will need to use a
Kerberos v5 based aklog.
On Athena 9.1 workstations, /bin/athena/aklog is still krb4 based,
and will not work for this purpose. A Kerberos v5 based aklog will be
incorporated in the Athena 9.2 release this summer, and is available on
current Athena machines as "aklog5" in the sipb locker. Because we do
not believe there is a large number of users doing this, we do not
currently anticipate incorporating a v5 based aklog into Athena 9.1.
However, if you feel we've underestimated demand for this service,
please feel free to send mail to release-team@mit.edu.
Users authenticating to MIT AFS cells from non-ATHENA.MIT.EDU
Kerberos principals should contact their local system administrators to
request that aklog be upgraded to one that is v5 based, such as the
Heimdal "afslog" or Ken Hornstein's aklog from the afs-krb5 migration
kit; note that this aklog is packaged for Redhat Linux as part of the
openafs.org openafs-krb5 RPM, and is available on Debian Linux as well.
3.) Authentication to foreign AFS cells from Athena workstations using an
ATHENA.MIT.EDU principal.
This should only become an issue as other realms disable their
interrealm Kerberos v4 support. Users encountering this issue will see
an error message of the form:
aklog: Couldn't get foo.edu AFS tickets: Principal unknown (kerberos)
when issuing the command "aklog foo.edu" on an Athena workstation.
Users encountering this issue should try using the "aklog5" command
in the sipb locker. This will only work if the remote site has updated
both their krb524d and their AFS installation to fairly recent versions
(MIT krb5 1.2.6 or later, OpenAFS 1.2.8 or later). These users should
be referred to the administrators of the remote site for further
assistance.
I hope this information is helpful; please let us know by sending
mail to release-team@mit.edu if you have any questions. Feel free to
forward this to anyone who didn't originally receive it and would find
it useful.
Garry
