2.5. Proxiable and proxy tickets
Connected: An Internet Encyclopedia
2.5. Proxiable and proxy tickets
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1510
Up:
2. Ticket flag uses and requests
Prev: 2.4. Postdated tickets
Next: 2.6. Forwardable tickets
2.5. Proxiable and proxy tickets
2.5. Proxiable and proxy tickets
At times it may be necessary for a principal to allow a service to
perform an operation on its behalf. The service must be able to take
on the identity of the client, but only for a particular purpose. A
principal can allow a service to take on the principal's identity for
a particular purpose by granting it a proxy.
The PROXIABLE flag in a ticket is normally only interpreted by the
ticket-granting service. It can be ignored by application servers.
When set, this flag tells the ticket-granting server that it is OK to
issue a new ticket (but not a ticket-granting ticket) with a
different network address based on this ticket. This flag is set by
default.
This flag allows a client to pass a proxy to a server to perform a
remote request on its behalf, e.g., a print service client can give
the print server a proxy to access the client's files on a particular
file server in order to satisfy a print request.
In order to complicate the use of stolen credentials, Kerberos
tickets are usually valid from only those network addresses
specifically included in the ticket (It is permissible to request or
issue tickets with no network addresses specified, but we do not
recommend it). For this reason, a client wishing to grant a proxy
must request a new ticket valid for the network address of the
service to be granted the proxy.
The PROXY flag is set in a ticket by the TGS when it issues a
proxy ticket. Application servers may check this flag and require
additional authentication from the agent presenting the proxy in
order to provide an audit trail.
Next: 2.6. Forwardable tickets
Connected: An Internet Encyclopedia
2.5. Proxiable and proxy tickets
|