[120] in Kerberos
Re: a different proposal for authori
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:30:49 1987
From BCN@WARD.CS.WASHINGTON.EDU Mon Oct 20 23:28:27 1986
Date: Mon 20 Oct 86 20:26:36-PDT
From: Clifford Neuman <BCN@WARD.CS.WASHINGTON.EDU>
Subject: Re: a different proposal for authorization, etc.
To: jis@BITSY.MIT.EDU
Cc: Saltzer@ATHENA.MIT.EDU, jg@ATHENA.MIT.EDU,
miller%erlang.DEC@DECWRL.DEC.COM, kerberos@ATHENA.MIT.EDU,
watchmakers@ATHENA.MIT.EDU, developers@ATHENA.MIT.EDU
In-Reply-To: <8610150418.AA09755@BITSY.MIT.EDU>
Alot of the discussions that have been going on on this list recently
with respect to kerberos mirror many of issues that have been
discussed before. I will first discuss authentication forwadring.
Having rlogin generate a new set of tickets for the destination host
is clearly the way to go. There are a few problems though. First,
one does not want to do this automatically (or at least without
providing an override). As a security-concious user, you are not
going to desire the forwarding of your credentials to a new system
that you know is not secure. Perhaps this would be acceptable if you
made the life of those credentials sufficiently short, but once
credentials expire in the middle of the rlogin session, the simple
path no longer exists for renewing them and you are back where you
started.
Another possible solution, although not as clean, would require some
kind of call back mechanism from the remote system that would allow
the desired tickets (or perhaps a shortlived tgt) to be obtained as
necessary. Once the user has logged out of the remote system, further
requests would be disallowed. Although a bit more secure, this
doesn't solve the problem completely. The problem is one of deciding
just how far you want to trust an untrustworthy agent.
Steve suggested restricting the lifetime of new tickets to the
remaining life of the ticket granting ticket. If I recall correctly,
this is allready the case.
Now onto the next topic, X. At the moment, service keys do not reside
on the public workstations. I expect that this is the way things will
remain since their security can't be assured. The first approach one
might consider taking to solve this problem is to use the key for the
client who is currently logged in. This is bad since we want to get
rid of this key as quickly as possible after it has been entered.
In discussions with mike and tony (regarding the noticication server)
I presented a possible scheme where an intial unauthenticated request
triggers a reply that is the initial message of a mutual
authentication exchange. Unfortunately, this only works for requests
from a timesharing (or server host) to a workstation, and not between
workstations. It is also fairly complex. I have a few other ideas on
this topic, but they, too, are overly complex, and I won't go into
them here.
Most of the relavant issue have been mentioned with respect to an
access control list server. The main tradeoff is between conceptual
simplicity in the approach where the end service calles the ACLS, and
taking the load off the end service when the ACLS is called by the
client.
-------
