[95] in Athena_Backup_System
Re: use of kerberos
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue May 9 01:23:55 1995
Date: Tue, 9 May 1995 01:23:36 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: Jonathon Weiss <jweiss@MIT.EDU>
Cc: athena-backup@MIT.EDU, kim@MIT.EDU, jis@MIT.EDU
In-Reply-To: [94]
[ I was asked to comment on this proposal, so here goes: ]
The master will have two srvtabs on it. One will be in
/etc/athena/srvtab and will contain a key for rcmd.host@REALM, where
host is tha name of the master and REALM is the name of the local
realm (ATHENA.MIT.EDU in our case). This will bner owned by root and
used for logging into the master, if you ever need to do that. This
srvtab will have nothing to do with the operation of ABS. The other
srvtab will contain a key for absmaster.host@REALM. This will be
owned by thew user that runs the ABS master software on the master.
This is the key that will be used by anything trying to talk to the
ABS master server.
The tape slaves will each have two srvtabs. These will be organized
in a parallel fashion to the organization on the master. The only
difference is that the key that ABS will use will be
absslave.host@REALM.
Kerberos V5 uses a slightly different name for naming service
principals. Here's the translation table:
rcmd.tsx-11@REALM host/tsx-11.mit.edu@REALM
absmaster.host@REALM absmaster/host.mit.edu@REALM
I suspect we will need to supply authentication with each udp connection.
I'd suggest you strongly reconsider doing this. Kerberos verifications
are expensive; especially if you need to do it for every single packet.
Instead, consider establishing a virtual connection between two hosts
indexed by connection id (which will be a large number based on the time
the association was created) and protect the packet with a MK_PRIV or
MK_SAFE using the Kerberos session key associated with virtual
connection. This way, each udp packet is protected, without needing to
supply authentication with each packet. If the server crashes and comes
back up, then it won't recognize the connection id sent to it by the
client along with each mk_priv or mk_safe protected packet, and it can
send an error message to the client to force it to reauthenticate and
then resend the packet.
I'd also strongly suggest that you look at the GSSAPI as the API to use
to access Kerberos V5. You can find a description of GSSAPI in RFC-1508
and RFC-1509. (attach rfc to obtain the RFC files). I gave a one-hour
presentation on the GSS API a few weeks ago, and a number of DCNS-dev
people attended; I'd be happy to repeat that presentation for the Backup
team, or some subset of them, if that would help. (Note that I leave
for Germany tomorrow, so it'll have to be after I get back).
- Ted
