[2605] in SIPB-AFS-requests
Re: Kerberos server for SIPB.MIT.EDU
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Mon Jan 6 21:15:44 1997
From: mhpower@MIT.EDU
To: ghudson@MIT.EDU
Cc: sipb-afsreq@MIT.EDU
In-Reply-To: "[2602] in SIPB-AFS-requests"
Date: Mon, 06 Jan 1997 21:15:27 EST
> ... giving AFS maintainers implicit access to the
>Kerberos database would compromise maintainer-independence between AFS
>and any service which would use keys in the SIPB kerberos realm.
This is a good point, and I think people would have to be careful not
to start using sipb-realm principals in ways that could lead to
unwanted access to the services they maintain. For example, adding
krbtgt.BANANA-SR.MIT.EDU@SIPB.MIT.EDU to charon's /.klogin file would
probably be bad (in fact, for at least three distinct reasons).
In general, I'd expect that sipb-realm principals would be created for
use in the client side of authentication (AFS client, zephyr client,
etc.), rather than for services on sipb machines that other
people/machines would authenticate to. Because of that, I think any
extra access given to the AFS maintainers would have a small scope.
It's possible that for a short time (probably less than a few months)
the sipb realm might end up with more reliably available V5 servers
than exist in the athena realm. I don't think we should take advantage
of that to base all possible sipb services on our own Kerberos realm.
Instead, I think we should keep track of any problems with our servers
and try to get fixes for them incorporated into the official release.
This might help get V5 more reliably supported in the athena realm,
and that itself would have considerable advantages for sipb services
(e.g., there'd be some security advantages if we no longer had to
support V4-based remote login and shell services on our servers).
Matt
