IETF RFC 5896 PDF

Introduction

Several GSS-API applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers, including CIFS file servers. However, delegating user credentials to a party who is not sufficiently trusted is problematic from a security standpoint.

Today, GSS-API [RFC2743] leaves the determination of whether delegation is desired to the client application. An application requests delegation by setting the deleg_req_flag when calling init_sec_context. This requires client applications to know what services should be trusted for delegation.

However, blindly delegating to services for applications that do not need delegation is problematic. In some cases, a central authority is in a better position than the client application to know what services should receive delegation. Some GSS-API mechanisms have a facility to allow an administrator to communicate that a particular service is an appropriate target for delegation. For example, a Kerberos [RFC4121] KDC can set the OK-AS-DELEGATE flag in issued tickets as such an indication. It is desirable to expose this knowledge to the GSS-API client so the client can request delegation if and only if central policy recommends delegation to the given service.

This specification adds a new input flag to gss_init_sec_context() to request delegation when approved by central policy. In addition, a constant value to be used in the GSS-API C bindings [RFC2744] is defined. Finally, the behavior for the Kerberos mechanism [RFC4121] is specified.