[254] in Kerberos
Re: an_to_ln
daemon@TELECOM.MIT.EDU (Bill Sommerfeld)
Sat Nov 14 00:06:59 1987
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: raeburn@ATHENA.MIT.EDU, srz@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
Not really a denial of service.
Jon can then log into Ken's account, remove the alias, and then delete
all of Ken's files if he's feeling nasty.
Seriously, the way to deal with this so that it doesn't become a
denial of service is to provide a remote service equivalent to
krb_alias. It would require one authenticator for a delete, and two
for an add (basically saying "equivalence these two so that A now maps
to what B maps to"); some care would have to be taken so that replays
of old authenticators in the 'B' slot wouldn't work (B would have to
contain as its checksum the quad_cksum() of A's ticket, or something
like that).
To be complete, there should also be a remote "whoami" service; you
send over the authenticator, and the other end sends back an ascii
string equivalent to what you map into.
That way, the response to that kind of hacking would be:
Jon tries to log into his account; finds that it fails ("jon
has not given permission for jon@ATHENA.MIT.EDU to log in").
Jon runs "rkrb_alias" to find out what he maps into, deletes
the mapping, (falling back to the old one, of course), and starts
winning again.
- Bill
