Skip to main content

2.5. Proxiable and Proxy Tickets

Overview​

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.

PROXIABLE Flag​

The PROXIABLE flag in a ticket:

  • Is normally only interpreted by the ticket-granting service
  • Can be ignored by application servers
  • When set, tells the TGS it is OK to issue a new ticket (but not a TGT) with a different network address
  • Is set if requested by the client on initial authentication
  • By default, client will request it be set when requesting a TGT, and reset when requesting any other ticket

Use Case Example​

A print service client can give the print server a proxy to access the client's files on a particular file server to satisfy a print request.

Network Address Considerations​

  • Kerberos tickets are often valid only from network addresses specifically included in the ticket
  • Policy option allows tickets with no network addresses specified
  • When granting a proxy, client MUST specify the new network address or indicate proxy is to be issued for use from any address

PROXY Flag​

The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. Application servers:

  • MAY check this flag
  • MAY require additional authentication from the agent presenting the proxy to provide an audit trail

Reference​

For complete technical details, refer to RFC 4120 Section 2.5.

Last updated on