| Network Working Group | N. Williams |
| Internet-Draft | Cryptonector |
| Updates: 1964, 2743, 2744 (if approved) | March 04, 2014 |
| Intended status: Standards Track | |
| Expires: September 05, 2014 |
Impersonation Naming Attribute for the Generic Security Services Application Programming Interface (GSS-API)
draft-williams-kitten-impersonation-naming-attr-00
This document describes a method for impersonation of one principal by another. Relying parties are expected to apply policy to decide which impersonation attempts they accept. Trusted third parties may provide assistance in evaluating policy. The proposed system fails safe: applications that do not support it see their peers as the impersonators, not the impersonated principals.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 05, 2014.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
A very common application design involves services that must impersonate their clients to other services. There are two common designs for enabling this:
There exist protocols where the explicit impersonation concept is difficult to retrofit. And there exist protocols where credential delegation is the commonly-deployed -and therefore expected- method for impersonation. Therefore explicit impersonation is not universally available.
On the other hand, unconstrained credential delegation is dangerous (for obvious reasons). What to do?
One answer has been constrained delegation. In this design the credential issuer creates a credential for impersonating the client, but in a constrained way (e.g., to only a small set of downstream services). But constrained credential delegation is difficult to manage: the constraints must be expressed by parties that aren't best-placed to know the desired policy.
We propose a simple solution for Generic Security Services Application Programming Interface (GSS-API) [RFC2743] applications: have the impersonator use their own credential (or one specifically for this purpose) and assert the name of the principal to be impersonated as a name attribute. This is very similar to the concept of “authz-id” in Simple Authentication and Security Layers (SASL) [RFC4422], but with some subtle differences as described below. We also propose the addition of a name attribute with the same semantics as the SASL authz-id.
There is an extension for Kerberos [RFC4120] known as Services for User (S4U) [S4U] which provides for impersonation. S4FU is available to GSS-API applications via the Kerberos GSS-API mechanism [RFC1964] [RFC4121], naturally.
A complete treatment of S4U is out of scope for this document, however, a brief summary is as follows. S4U consists of two sub-protocols for impersonation:
This document concerns itself only with functionality like that of S4U2Proxy.
There are several differences between this proposal and S4U2Proxy:
(1) is the initial motivation for this work: S4U does not permit services not in the impersonated principal's realm to impersonate it to services in that same realm. This is because any service ticket issued for such access would appear to transit a trust path back to the impersonated principal's realm, thus triggering loop detection. A better fix for this might be to permit exactly one full cycle precisely so as to permit this and other similar use cases. However, the other differences and advantages over S4U2Proxy are compelling.
This proposal does not intend to entirely replace S4U. In particular, in use cases where Kerberos tickets carry KDC-issued authorization-data, the services to which principals are successfully impersonated may need to use S4U2Self in order to obtain that authorization-data if they have no other method available by which to get it.
Our method of impersonation has a number of advantages to S4U:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
We provide three interfaces for impersonation:
We define two generic GSS-API naming attributes [RFC6680] for impersonation:
Mechanisms MAY support credential delegation for credentials with these attributes set, however, if they do they MUST constrain the delegated credentials such that they may only be used to impersonate the same principal or assert the same authz-id as in the security context token exchange where the credential was delegated. Impersonator applications are encouraged to not delegate impersonation credentials; instead their peers should should use impersonation if necessary.
Inputs:
Outputs:
This function is just like GSS_Acquire_cred(), from the base GSS-APIv2u1 RFC2743 specification, but with the addition of an input for the impersonator's credentials.
This function may be used with S4U2Self or it may be equivalent to acquiring credentials for the impersonator's NAME but with one or both of the name attributes described in Section 2.1.
OM_uint32 gss_acquire_cred_impersonate_name(
OM_uint32 *minor_status,
const gss_cred_id_t impersonator_cred_handle,
const gss_name_t desired_name,
OM_uint32 time_req,
const gss_OID_set desired_mechs,
gss_cred_usage_t cred_usage,
gss_cred_id_t *output_cred_handle,
gss_OID_set *actual_mechs,
OM_uint32 *time_rec);
Figure 1: gss_acquire_cred_impersonate_name()
When an initiator uses impersonation but does not request and perform credential delegation, and the acceptor is so configured, the acceptor mechanism SHOULD pretend that the initiator delegated a credential to impersonate the same principal/authz-id as impersonated to the acceptor if the acceptor has credentials for a principal suitable for use as an impersonator.
When an initiator uses impersonation and does request and successfully perform credential delegation, the issuer of the delegated credentials SHOULD constrain that credential to carry the same impersonation name attributes as the initiator's.
Impersonator applications are expected to create a NAME object for their impersonator principal name, set one, the other, or even both of the impersonation attributes described in Section 2.1, acquire a credential for this NAME as the desired_name, then use this credential handle with GSS_Init_sec_context() (or even GSS_Accept_sec_context()) to authenticate to other services (or initiators).
Impersonator applications SHOULD take care to use an impersonator name that does not denote any access or privilege beyond impersonation [to peers that will trust it so].
Applications that are not aware of impersonation MUST observe a security context's peer's name as the impersonator name: impersonation fails safe.
Applications that are impersonation-aware SHOULD obtain the name of the principal to be impersonated and if so, MUST apply local policy to determine if the impersonator principal is permitted to impersonate the requested principal to the application.
Trusted third parties (e.g., Kerberos KDCs) may reject impersonation using policy local to them. Trusted third parties may also bless impersonation attempts, but application local policy must still be applied (even if that policy is to accept a trusted third party's blessing).
Trusted third party policy is conveyed to application via their use (or non-use) of the GSS_C_ATTR_GENERIC_UNCONSTRAINED or GSS_C_ATTR_GENERIC_UNCONSTRAINED_OK name attribute prefixes together with the 'authenticated' output of GSS_Get_name_attributes() [I-D.williams-kitten-generic-naming-attributes].
See [I-D.williams-kitten-generic-naming-attributes] for more information on the semantics of the GSS_C_ATTR_GENERIC_UNCONSTRAINED and GSS_C_ATTR_GENERIC_UNCONSTRAINED_OK name attribute prefixes.
For Kerberos [RFC4120] we use authorization-data, which may be carried in either Tickets or Authenticators, and may or may not be embedded in AD-KDC-ISSUED or similar (when embedded in a Ticket). KDC policy approval is expressed via embedding these authorization-data in AD-KDC-ISSUED or similar (in a Ticket). KDC policy application is requested by placing the authorization-data in a TGS-REQ's enc-authorization-data.
KDC support for all these authorization-data elements is OPTIONAL.
Use of these authorization-data elements entirely in the Authenticator is sufficient for most uses. Use in Tickets is only required for a) application of more general KDC-side policy (otherwise the KDC doesn't see who is being impersonated), b) for requesting FORWARDED impersonation Tickets (which, as described Section 2.1, is OPTIONAL.
The authorization-data element is:
(Note that no ASN.1 syntax is needed to describe these authorization-data elements' values.)
Clients MAY embed AD-IMPERSONATE-GSS and/or AD-ASSERT-AUTHZID in an AD-IF-RELEVANT authorization-data element in TGS requests for new Tickets, except when requesting forwarded/forwardable Tickets, in which case the element MUST be made critical (by not including it in any authorization-data element that denotes non-criticality).
Clients that do not need or do not want KDC blessing SHOULD only include these authorization-data elements in Authenticators. The client MAY include these elements in AD-IF-RELEVANT (on the theory that it's safe for the target service to observe the impersonator's name instead of the impersonated name), but the client SHOULD make these authorization-data elements critical to ensure that the target service rejects the AP-REQ if it does not understand them.
TGSes need not have any further support for these authorization-data elements than is required by RFC4120. However, a TGS may contribute its own local policy by including any AD-IMPERSONATE-GSS or AD-ASSERT-AUTHZID elements from a TGS-REQ's enc-authorization-data (or from a TGT's authorization-data) in AD-KDC-ISSUED (or similar) elements. A TGS MUST NOT include these attributes in AD-KDC-ISSUED (or similar) without having applied local policy and determined that the client principal is permitted to make the requested assertions to the requested target service principal.
A TGS can only interpret AD-ASSERT-AUTHZID elements relative to the target service principal name. As there is no authzid concept for TGS principals, the TGS MUST NOT include AD-ASSERT-AUTHZID elements in any AD-KDC-ISSUED (or similar) elements when the sname of the Ticket to be issued is a TGS name. But a TGS may be able to interpret (and therefore apply local policy) authzids in other cases.
TGS policy MUST NOT bless (i.e., include these elements in AD-KDC-ISSUED or similar) requests with multiple instances of either AD-IMPERSONATE-GSS or AD-ASSERT-AUTHZID.
As usual, per-RFC4120, if these authorization-data elements appear in the enc-authorization-data field of the TGS-REQ and/or the TGT, then the TGS should copy them to the issued Ticket. But if the TGS has policy approving of the requested impersonation, then it SHOULD include the impersonation authorization-data elements in a critical AD-KDC-ISSUED (or similar) element.
Services must adhere to the authorization-data handling rules specified in RFC4120. Services that implement these authorization-data element MUST expose them to applications in some manner (e.g., as GSS-API naming attributes, as described in this document).
Service implementations MAY apply local policy as to AD-IMPERSONATE-GSS on behalf of specific applications and, when local policy approves, may report the client's principal name as the impersonated principal name. However, it is preferred that applications apply local policy, not the Kerberos implementation.
Services MUST reject AP-REQs with multiple distinct AD-IMPERSONATE-GSS or AD-ASSERT-AUTHZID elements.
<TBD> /* * Roughly this looks like: * - if the impseronator application is an acceptor * it calls gss_accept_sec_context() and gets a * delegated credential handle even when the initiator * didn't request delegation; * - else the impersonator calls * gss_acquire_cred_impersonate_name() * to acquire a credential for impersonating a given * principal; * * then the application calls gss_init_sec_context() with * the impersonation credential as the initiator credential * handle. */ <TBD>
Figure 2: Impersonator-side code
<TBD> /* * An impersonation-aware acceptor application * uses gss_get_name_attribute() to check whether * its peers' NAMEs (values of gss_name_t type output by * gss_accept_sec_context()) have either or both of the * GSS_C_ATTR_IMPERSONATED_PRINCIPAL and/or * GSS_C_ATTR_AUTHZ_ID name attributes -prefixed with * GSS_C_ATTR_GENERIC_UNCONSTRAINED_OK- set, and if so, * then they check local policy. * * Third-party policy can be checked by checking the * 'authenticated' boolean output of gss_get_name_attribute() * or by not prefixing with either these attributes with either * GSS_C_ATTR_GENERIC_UNCONSTRAINED_OK nor * GSS_C_ATTR_GENERIC_UNCONSTRAINED. */
Figure 3: Acceptor-side code
This entire document deals with security. Specifically this document provides a method for denoting impersonation while failing safe when peers do not support this method. Failing safe means: peers observe the impersonator's name, not the impersonated name, and impersonator applications fail when their GSS-API implementation is not impersonation-aware.
Local policy is to be used for deciding when impersonators may impersonate any one entity to another. Such policy must be local to the impersonators' peers. Third parties may apply policy as well in some cases, but local policy must always be able to reject impersonation. Policy MUST be applied by applications. Implementations MAY provide a method by which local policy may be indicated in an indirect manner (e.g., via “environment variables”) and evaluated by the GSS-API provider on behalf of the application; this is strictly to avoid having to modify existing GSS-API applications, but should not be encouraged beyond that purpose.
GSS_Set_name_attribute() is required to fail when used with attributes not understood by the mechanism. This ensures that impersonators applications that set these attributes do not accidentally fail to actually use them when impersonating principals. Some additional safe-guards MAY be applied:
In particular, for Kerberos, KDCs SHOULD NOT issue Ticket Granting Tickets (TGTs) with the FORWARDED or FORWARDABLE flags set if the Ticket's client principal is a known impersonator and the AD-IMPERSONATE-GSS authorization-data element is not present in the client's Ticket and/or TGS-REQ as a critical authorization-data element; if AD-IMPERSONATE-GSS is present in the Ticket as a critical and KDC-issued element but not in the TGS-REQ then the KDC SHOULD copy the AD-IMPERSONATE-GSS to the Ticket to be issued.
Kerberos initiators should (as opposed to SHOULD, but perhaps this should be a SHOULD) use impersonator names that begin with a zeroth component with this value: “IMPERSONATE”.
Our approach fails safe: service applications that are not aware of impersonation will not think that they are talking to the principal that an impersonator wishes to impersonate, and impersonator applications should fail when their GSS-API mechanism implementations do not support this feature.
| [RFC4422] | Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. |
| [S4U] | Unspecified, U., "[MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol", August 2013. |
This document resulted from Viktor Dukhovni's notes on S4U2Proxy's shortcomings and discussions between him and the author as to how best to address this.