Network Working Group N. Williams Internet-Draft Cryptonector Updates: 1964, 2743, 2744 March 4, 2014 (if approved) Intended status: Standards Track Expires: September 5, 2014 Impersonation Naming Attribute for the Generic Security Services Application Programming Interface (GSS-API) draft-williams-kitten-impersonation-naming-attr-00 Abstract 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. Status of this Memo 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 5, 2014. Copyright Notice 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 Williams Expires September 5, 2014 [Page 1] Internet-Draft GSS Impersonation March 2014 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. Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . 3 1.1. Comparison to S4U . . . . . . . . . . . . . . . . . . 3 1.1.1. Comparison to S4U2Proxy . . . . . . . . . . . . . . . 4 1.2. Conventions used in this document . . . . . . . . . . 5 2. Generic Interfaces for Impersonation . . . . . . . . . 6 2.1. Naming Attributes for Generic Impersonation . . . . . 6 2.1.1. C Bindings . . . . . . . . . . . . . . . . . . . . . . 7 2.2. GSS_Acquire_cred_impersonate_name() . . . . . . . . . 7 2.2.1. C Bindings of GSS_Acquire_cred_impersonate_name() . . 8 2.3. Apparent Credential Delegation . . . . . . . . . . . . 8 2.4. Intended Usage . . . . . . . . . . . . . . . . . . . . 8 2.5. Local Policy . . . . . . . . . . . . . . . . . . . . . 9 2.6. Third-Party Impersonation Policy Assistance . . . . . 9 3. Kerberos Bindings of Impersonation Attributes . . . . 10 3.1. Client Processing . . . . . . . . . . . . . . . . . . 10 3.2. TGS Processing (OPTIONAL) . . . . . . . . . . . . . . 11 3.3. Target Service Processing . . . . . . . . . . . . . . 11 4. Sample Code . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . 13 5.1. Security Requirements and Recommendations . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . 18 Williams Expires September 5, 2014 [Page 2] Internet-Draft GSS Impersonation March 2014 1. Introduction and Motivation A very common application design involves services that must impersonate their clients to other services. There are two common designs for enabling this: credential delegation where clients delegate credentials to the impersonators, explicit impersonation where impersonators explicitly state that they are impersonating others. 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. 1.1. Comparison to S4U 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: Williams Expires September 5, 2014 [Page 3] Internet-Draft GSS Impersonation March 2014 S4U2Self Allows services to use their own credentials to obtain KDC- issued authorization-data for principals to be impersonated. S4U2Proxy Allows services to use clients' service tickets as "evidence" tickets with which (and together with the impersonator's credentials) to obtain other tickets in the name of the client principals to be impersonated. This document concerns itself only with functionality like that of S4U2Proxy. There are several differences between this proposal and S4U2Proxy: 1. At no point does a KDC issue a ticket to an impersonator with the impersonated principal's name as the cname/crealm. This permits access to services in the impersonated principal's home realm. 2. No "evidence" tickets are required or used. 3. No KDC support is required, but may be provided. 4. No KDC-side policy is required, but may be provided. (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. 1.1.1. Comparison to S4U2Proxy Our method of impersonation has a number of advantages to S4U: o it is simpler (no need for evidence tickets and related cryptographic sub-protocols, no need for KDC-side policy, and even where KDCs apply additional policy, this method imposes no new requirements for additional cryptographic operations on either the impersonator's nor the KDC's part); Williams Expires September 5, 2014 [Page 4] Internet-Draft GSS Impersonation March 2014 o it adheres strictly to the Kerberos model whereby application- local policy has the last word and KDCs need not apply any policy; o it fails safe when used with peers that do not implement it (and therefore do not apply local policy to impersonation attempts); o it permits impersonation of principals whose names are not Kerberos principal names. 1.2. Conventions used in this document 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]. Williams Expires September 5, 2014 [Page 5] Internet-Draft GSS Impersonation March 2014 2. Generic Interfaces for Impersonation We provide three interfaces for impersonation: o naming attributes [RFC6680] (see Section 2.1); o a function, GSS_Acquire_cred_impersonate_name() and its C programming language bindings patterned after the GSS-APIv2u1 C bindings [RFC2744] (see Section 2.2); o apparent credential delegation, even when credential delegation has not taken place (see Section 2.3). 2.1. Naming Attributes for Generic Impersonation We define two generic GSS-API naming attributes [RFC6680] for impersonation: GSS_C_ATTR_IMPERSONATED_PRINCIPAL This attribute notionally carries an exported name token representation of the name of the principal to be impersonated by the principal whose CREDENTIAL HANDLE's desired NAME has this attribute. This is subtly different from SASL's authz-id concept in that the latter carries an application- specific name form while this one carries a mechanism-specific name form (though not necessarily the same mechanism as is used to authenticate the impersonator!). When obtained with GSS_Get_name_attribute() the display_value of this attribute SHOULD be a display form of the impersonated name else it MUST be empty, whereas the non-display form MUST be an octet string suitable for use as an input to GSS_Import_name() with GSS_C_NT_EXPORTED_NAME or GSS_C_NT_COMPOSITE_EXPORT. GSS_C_ATTR_AUTHZ_ID This attribute carries an application-specific name form corresponding to an identity that is to be impersonated (by the principal whose CREDENTIAL HANDLE's desired NAME has this attribute). This attribute's semantics are exactly like SASL's. Interpretation of this attribute's non-display value is application-specific; the display value of this attribute is empty. 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. Williams Expires September 5, 2014 [Page 6] Internet-Draft GSS Impersonation March 2014 [[anchor1: TBD: Should we specify a way to denote authz-id form, e.g., via a URN? Perhaps by convention the authz-id should generally be prefixed with a URN denoting its form, and perhaps there should be a URN for denoting "private to the application using it". Of course, that would be an optional convention, and anyways, it's not necessary (SASL doesn't have it).]] 2.1.1. C Bindings [[anchor2: TBD. Obviously the bindings consist of the same symbols as shown above; their values should be of type gss_buffer_desc, pointing to the URNs assigned herein (still TBD).]] 2.2. GSS_Acquire_cred_impersonate_name() Inputs: impersonator_cred_handle CREDENTIAL HANDLE A handle for the impersonator's credentials. desired_name NAME The name of the principal to be impersonated. time_req INTEGER Same as for GSS_Acquire_cred() [RFC2743]. desired_mechs SET OF OBJECT IDENTIFIER Same as for GSS_Acquire_cred() [RFC2743]. cred_usage INTEGER Same as for GSS_Acquire_cred() [RFC2743]. Outputs: major status INTEGER minor status INTEGER output_cred_handle CREDENTIAL HANDLE If returned, these are the credentials for impersonating the desired_name. actual_mechs SET OF OBJECT IDENTIFIER Same as for GSS_Acquire_cred() [RFC2743]. time_rec INTEGER Same as for GSS_Acquire_cred() [RFC2743]. 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 Williams Expires September 5, 2014 [Page 7] Internet-Draft GSS Impersonation March 2014 acquiring credentials for the impersonator's NAME but with one or both of the name attributes described in Section 2.1. [[anchor3: TBD: Describe any differences from GSS_Acquire_name() as to major status codes.]] 2.2.1. C Bindings of GSS_Acquire_cred_impersonate_name() 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() 2.3. Apparent Credential Delegation 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. 2.4. Intended Usage 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]. Williams Expires September 5, 2014 [Page 8] Internet-Draft GSS Impersonation March 2014 2.5. Local Policy 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. 2.6. Third-Party Impersonation Policy Assistance 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. Williams Expires September 5, 2014 [Page 9] Internet-Draft GSS Impersonation March 2014 3. Kerberos Bindings of Impersonation Attributes 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: AD-IMPERSONATE-GSS Indicates that the Ticket or Authenticator is intended to impersonate the given principal. The octet string value of this element is an exported GSS-API name token AD-ASSERT-AUTHZID Indicates that the Ticket or Authenticator is intended to impersonate the given authzid (SASL semantics). The octet string value of this element is application-specific, therefore clients SHOULD NOT request this element be added to TGTs. (Note that no ASN.1 syntax is needed to describe these authorization- data elements' values.) 3.1. Client Processing 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 Williams Expires September 5, 2014 [Page 10] Internet-Draft GSS Impersonation March 2014 service rejects the AP-REQ if it does not understand them. 3.2. TGS Processing (OPTIONAL) 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. 3.3. Target Service Processing 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. Williams Expires September 5, 2014 [Page 11] Internet-Draft GSS Impersonation March 2014 4. Sample Code /* * 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. */ Figure 2: Impersonator-side code /* * 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 [[anchor4: Also add sample code using the authz-id attribute.]] Williams Expires September 5, 2014 [Page 12] Internet-Draft GSS Impersonation March 2014 5. Security Considerations 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. [[anchor5: Should add text about when and why one might need or use impersonation.]] 5.1. Security Requirements and Recommendations 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: o impersonator applications SHOULD use a credential that denotes no other privileges; o credential issuers (e.g., Kerberos KDCs) MAY constrain the use of credentials for known impersonator principals to requesting credentials for impersonation. 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 Williams Expires September 5, 2014 [Page 13] Internet-Draft GSS Impersonation March 2014 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. Williams Expires September 5, 2014 [Page 14] Internet-Draft GSS Impersonation March 2014 6. IANA Considerations [[anchor6: Request addition of the new GSS name attributes and Kerberos authorization-data to the relevant registries.]] Williams Expires September 5, 2014 [Page 15] Internet-Draft GSS Impersonation March 2014 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005. [RFC6680] Williams, N., Johansson, L., Hartman, S., and S. Josefsson, "Generic Security Service Application Programming Interface (GSS-API) Naming Extensions", RFC 6680, August 2012. [I-D.williams-kitten-generic-naming-attributes] Williams, N., "Generic Naming Attributes for the Generic Security Services Application Programming Interface (GSS- API)", draft-williams-kitten-generic-naming-attributes-01 (work in progress), August 2013. 7.2. Informative References [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. Williams Expires September 5, 2014 [Page 16] Internet-Draft GSS Impersonation March 2014 Appendix A. Acknowledgements 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. Williams Expires September 5, 2014 [Page 17] Internet-Draft GSS Impersonation March 2014 Author's Address Nicolas Williams Cryptonector, LLC Email: nico@cryptonector.com Williams Expires September 5, 2014 [Page 18]