[428] in Moira
SIS/Moira summary
daemon@ATHENA.MIT.EDU (Mark Rosenstein)
Wed Jul 8 13:10:36 1992
Date: Wed, 8 Jul 92 13:09:38 -0400
From: Mark Rosenstein <mar@MIT.EDU>
To: trb@MIT.EDU
Cc: moiradev@MIT.EDU, thorne@MIT.EDU
This is a summary of Moira's interaction with SIS for you to decide if
we need a security audit.
-Mark
Moira provides two services for SIS: registration of extra kerberos
instances, and providing a signed loginname to MIT ID mapping for each
eligible user.
EXTRA KERBEROS INSTANCE HANDLING
The extra kerberos instance is referred to as the "secure" instance
within moira because that's what it was called when the code was
written. There is an integer field in each user record called
"secure". If this value is zero, then the user has not received his
secure instance. If the value is non-zero, it is the unix time of
when the secure instance was registered. Integer unix time rather
than an Ingres date field was chosen to make comparisions outside of
the database easier. It is important to know when the instance was
granted because we do not allow it to be used for two weeks following
registration.
The actual registration of the extra kerberos instance is handled by
the reg_svr. Two new operations were added to the reg_svr protocol,
one to check whether a user has registered for a secure instance, and
another to register the secure instance. Both of these operations
receive a packet which has:
* the login name in cleartext
* a kerberos credential for changepw.[moira-server] from the user
* a record encrypted in the session key from the above credential
+ the user's ID number
+ the desired password
The service instance "changepw" was chosen because you cannot get this
ticket from a ticket-granting-ticket, it must be fetched with the
user's password. The reg_svr will only set the password if the secure
field was zero and the passed ID number matches the one on the
account.
A new nightly service has been provided called "letter". When this
service update is run, it scans the users in moira for anyone who
registered for a secure instance since the last time it was run. It
does this by storing the last time that it ran in the "secure" field
for user 0, which is a special user record. For each of these users,
it extracts their full name and address (as provided by the
registrar/personel), login name and date they registered. It uses
these values to fill in a form letter which is hand-edited postscript.
When it "delivers" this file to the server (which is again the moira
server), the script first attempts to determine whether the previous
night's file printed successfull by comparing the output of 'lpquota -l'
with the cached copy of yesterday's file. If this indicates
yesterday's file printed, the old copy is deleted. If not, today's
file is appended to yesterday's and this whole thing is printed.
SIS CONFIGURATION DATA
What SIS needs from moira is a set of signed mappings between login
name and MIT ID number for everyone eligible to use SIS. Eligible to
use SIS means that it has been at least 14 days since they registered
their extra kerberos instance. So we extract this data and send it to
SIS in the clear over the net (it should probably be encrypted).
The tricky part here is the signature management. The moira queries
to add a user to the database and to modify a user account both accept
a signature from the client. If a signature is sent, moira will
verify that the signature is good before storing it in the database
(it must do this as it decomposes the signature when storing it to
save space). If the signature is bad, the moira query will fail. If
no signature is sent, moira will accept the query and not record a
signature in the database. This is necessary because a client can set
a user's login name to the special token "CREATE_UNIQUE_LOGIN" which
the server will change to a unique string, invalidating any signature
the client could have generated. It also allows older clients to
function with the current server.
When data is bulk-loaded from the registrar/personel, it will not be
signed. The reg_svr also will not sign users when the register for
their Athena account. We will periodically bulk-sign users who have
recently registered if we are confident that Moira's security has not
been breached. The first pass of this bulk signing was done by
"sms@ATHENA.MIT.EDU", which turns out to be a bad choice since that
key is in the srvtab on moira; someone violating moira's security
could generate such signatures. This bulk signing should be done by a
kerberos principal whose password must be typed in, perhaps
"moira.extra@ATHENA.MIT.EDU" would be a good choice.
The SIS server maintains a list of valid signers. Currently this list
includes:
carla, carla.root, pjb, pjb.root
lavin, dot, reidmp
hoffmann.root, tom.root, jis.root, tytso.root, jon.root
mar, probe
sms
The SIS server verifies the signature at the time of the request.
