As Doug has already pointed out, all the schemes that basically know the
users password or the srvtab-capable Kerberos hash thereof all suffer the
problem of how to transmit that information safely, how to keep it in a safe
place, and (more annoyingly) what to do when the user changes password.
The (IMHO better) alternative is to trust the batch system that it is able to
authenticate the job submitter by other means, and simply construct an AFS
token on a secure server. Remains the problem of how to make sure that the
requestor is indeed the batch system and then how to securely transmit the
token - PGP is one way on how to address that. The advantage of such a scheme
is that no passwords ever float around, and that on the 'secure server' side
one has extensive logging and full control on what to grant to whom.
There are several schemes that do this on the 'market', the [ill-fated (?)
and] slight complicated 'khat' is one of them. Platform Computing (the LSF
guys) have their own 'rtokd'. We use our home-made 'forge' to create a ticket
and 'arc' to securely transmit it - how it works can be found in
/afs/cern.ch/project/afs/arc/arc.html.
Things get difficult with DCE/DFS: I haven't seen a 'forge'-type program
yet that constructs the necessary K5 tickets from scratch.
One way is to extract the user's Kerberos key out of the DCE registry - not
easy, but we've managed to implement a prototype by re-linking 'secd' with a
little 'trojan horse' on AIX. That key can then bue put into a k5srvtab to
create credentials - the problem on how to transmit the credentials is again
another one!
However, James Dodd (one of my technical students which some of you might
have come across already in info-dce) recently came up with an as far as I
can see brilliant idea:
when the batch job starts, the batch system instructs a 'secure server' to
set up a (randomly named) DCE 'alias' for the user which lives only for the
duration of the job. The batch job is told the password for the alias, runs
dce_login with that password which grants it all the DFS-rights of the
original user. It can spawn a little keep-alive process which renews the
credentials every now and then. When the job finishes the alias is destroyed.
James has tested the principle which seems to work and is now implementing
it. Remains to be seen where security suffers in this system - it'll be a
'practical' decision in the end.
Comments on the feasability of this approach are welcome!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke http://wwwcn1.cern.ch/~rtb -or- [EMAIL PROTECTED] O__
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland > |
Phone: +41 22 767 8985 Fax: +41 22 767 7155 ( )\( )
