[4227] in Kerberos
Proxy tickets...
daemon@ATHENA.MIT.EDU (Clifford Neuman)
Sun Nov 20 15:28:04 1994
Date: Sun, 20 Nov 1994 12:14:53 -0800
From: Clifford Neuman <bcn@ISI.EDU>
To: mellon@ipd.wellsfargo.com
Cc: kerberos@MIT.EDU
In-Reply-To: Ted Lemon's message of Fri, 18 Nov 1994 15:15:20 -0800 <199411182315.PAA00416@rurapenthe.ipd.wellsfargo.com>
Date: Fri, 18 Nov 1994 15:15:20 -0800
From: Ted Lemon <mellon@ipd.wellsfargo.com>
We have an application here at Wells Fargo which doesn't appear to be
addressed by the current PROXIABLE/PROXY ticket flags, and I'm
wondering if anybody is thinking about solving this problem, or if
it's considered not to be worth solving.
First, let me describe how I think RFC 1510 currently describes
proxying. Let us say that Principal X wants to use Service A, which
will also need to access Service B on behalf of the user in order to
complete its request.
Principal X presents its TGT to the TGS and requests a normal ticket
for Service A, and authenticates itself with Service A using that
ticket. It also presents its TGT to the TGS a second time, requesting
a TGT with the PROXIABLE flag set. The address for which the new TGT
will be valid is set to that of Service A.
It then authenticates itself to Service A and hands Service A the
proxiable TGT, which is used to get a ticket for Service B, which
can't be the TGS. That ticket has the PROXY flag set. Service A then
uses that ticket to access Service B, which knows from the PROXY flag
in its ticket that it might be worthwhile to insist that Service A
provide its own ticket, possibly for access control and also to
maintain a more complete audit trail.
Actually, unless Principal X trusts the service A not to exceed
specific authority, the way things work is that X requests a proxied
ticket from the TGS for the service A needs to use on X's behalf, and
forwards that proxy to A following X's authentication to A. If X
doesn't know what services A will require, then X must forward
credentials (a TGT) to A that allow A to do anything that X could do.
A should not do this unless it trusts X, but if it does, and if the
forwarded credentials are themselves forwardable (A decides this when
it obtains the credentials for forwarding to X), then X can further
forward the credentials or grant proxies (actually the latter requires
the the forwarded credentials be proxiable too).
Unfortunately, this model only works if the services that Service A
needs to access don't themselves need to access other services in
Principal X's name. If Service A is a CORBA server which may access
another CORBA server (Service B) which finally accesses a database
engine (Service C), there's no way to use a proxy ticket, because
there's no way for Service B to get a ticket in Principal X's name for
Service C.
Principal X could pass a forwardable TGT to Service A, which could
then get its own forwardable TGT in Principal X's name and pass that
along to Service B, which would do the same for Service C. However,
in that case each service has a TGT which is not labeled as being in
any way different from the user's actual credentials.
This is exactly what would happen above. Note that the credentials
obtained will be labeled as "forwarded", which are different from the
user's actual credentials.
I think that what's needed is a ticket that has the same semantics as
the forwardable TGT, but which has a flag set indicating that the
ticket is being used as a proxy. As this ticket was passed down the
chain of servers, it would always have a flag on it indicating that it
should be treated as a proxy. It might be worthwhile to require that
in order to use the forwardable proxy TGT, a server would also have to
supply its own TGT.
It is the "forwarded" flag. Actually, the distinction between
forwardable and proxiable is minor, and if I had it to do again, I
would probably roll them into a single flag. More constrained limits
on the use of proxies or forwarded credentials may be placed in the
authorization data field. See:
ftp://prospero.isi.edu/pub/papers/security/pbaa.ps.Z
Clifford Neuman
