[4223] in Kerberos
Proxy tickets...
daemon@ATHENA.MIT.EDU (Ted Lemon)
Fri Nov 18 18:45:37 1994
To: kerberos@MIT.EDU
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.
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.
Thus, each service has no way of knowing that it should request
additional authentication, check additional access control lists, or
put information in the audit trail about the service making the proxy
request in addition to the user on whose behalf the request is being
made. The protocol between each server could pass information to
this effect out of band, but there's no way that Principal X can force
this to happen.
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.
Would anybody care to flame me on this topic? :')
_MelloN_
--
Ted Lemon Wells Fargo Bank, Information Protection Division
mellon@ipd.wellsfargo.com +1 415 477 5045
