Network Working Group S. Hartman Request for Comments: 4768 MIT Category: Informational December 2006 Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2006).
AbstractThe Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion.
1. Introduction ....................................................2 2. Kerberos Naming .................................................3 3. X.509 Names .....................................................4 4. Composite Names .................................................5 4.1. Usage of Name Attributes ...................................6 4.2. Open Issues ................................................6 4.3. Handling gss_export_name ...................................7 5. Credential Extensions ...........................................7 6. Mechanisms for Export Name ......................................8 7. Selection of Source Identity ....................................8 8. Compatibility with GSS-API V2 ...................................9 9. Security Considerations .........................................9 10. Acknowledgements ..............................................10 11. Informative References ........................................10 2] authenticates two named parties to each other. GSS names can be imported in a variety of formats through the gss_import_name call. Several mechanism-independent name formats are provided, including GSS_C_NT_HOSTBASED_SERVICE for services running on an Internet host, and GSS_C_NT_USER_NAME for the names of users. Other mechanism-specific name types are also provided. By the time a name is used in acquiring a mechanism- specific credential or establishing a security context, it has been transformed into one of these mechanism-specific name types. In addition, the GSS-API provides a function called gss_export_name that will transform a GSS-API name into a binary blob suitable for comparisons. This binary blob can be stored on ACLs and then authorization decisions can be made simply by comparing the name exported from a newly accepted context to the name on the ACL. Storing names on ACLs can be problematic because names tend to change over time. If the name contains organizational information, such as a domain part or an indication of what department someone works for, this changes as the person moves around the organization. Even if no organizational information is included in the name, the name will change as people change their names. Updating ACLs to reflect name changes is difficult. Another significant problem is that names can be reused to apply to an entity other than the entity to which they originally applied. For example, if a Unix user ID is placed on an ACL, the account deleted and then a new user assigned the old ID, then that new user may gain privileges intended for the old user.
Inherent in the GSS naming model is the idea that mechanism names need to be able to be represented in a single canonical form. Anyone importing that name needs to be able to retrieve the canonical form of that name. Several security mechanisms have been proposed for which this naming architecture is too restrictive. In some cases, it is not always possible to canonicalize any name that is imported. In other cases, there is no single canonical name. Also, as GSS-API is used in more complex environments, there is a desire to use attribute certificates , Kerberos authorization data , or other non-name-based authorization models. GSS-API needs to be enhanced in order to support these uses in a mechanism-independent manner. This document discusses the particular naming problems with two important classes of GSS-API mechanisms. It also discusses the set of proposed solutions and their associated open issues. This document limits discussion to these solutions and provides a description of the problem against which the solutions can be judged. These solutions are targeted for incorporation into GSS-API Version 3. 4] proposes a new type of Kerberos name called an enterprise name. The intent is that the enterprise name is an alias that the user knows for themselves and can use to log in. The Kerberos Key Distribution Center (KDC) translates this name into a normal Kerberos principal and gives the user tickets for this principal. This normal principal is used for authorization. The intent is that the enterprise name tracks the user as they moves throughout the organization, even if they move to parts of the organization that have different naming policies. The name they type at login remains constant, but the Kerberos principal used to authenticate them to services changes. Unauthenticated services cannot generally perform a mapping from enterprise name to principal name. Even authenticated services may not be authorized to map names other than the name of the authenticated service. Also, Kerberos does not (and does not plan to) provide a mechanism for mapping enterprise names to principals besides authentication as the enterprise name. Thus, any such mapping would be vendor-specific. With this feature in Kerberos, it
is not possible to implement gss_canonicalize_name for enterprise name types. Of course, other name types such as traditional principal names could be used for GSS-API applications. Naturally, this loses the benefits of enterprise names. Another issue arises with enterprise names. In some cases, it would be desirable to put the enterprise name on the ACL instead of a principal name for greater ACL stability. At first glance, this could be accomplished by including the enterprise name in the name exported by gss_export_name. Unfortunately, if this were done, the exported name would change whenever the mapping changed, invalidating any ACL entries based off the old exported name and defeating the purpose of including the enterprise name in the exported name. In some cases, it would be desirable to have the exported name be based on the enterprise name and, in others, based on the principal name, but this is not permitted by the current GSS-API. Another development also complicates GSS-API naming for Kerberos. Several vendors have been looking at mechanisms to include group membership information in Kerberos authorization data. It is desirable to put these group names on ACLs. Again, GSS-API currently has no mechanism to use this information. RFC 3280  allows the subject name to be an empty sequence in end-entity certificates. Therefore, the subjectAltName extension might be the only portion of the certificate that identifies the subject. As in the case of Kerberos group memberships, there may be many subjectAltName extensions available in a certificate. Different applications will care about different name forms. One possible candidate for an exported name would be all the names from the subject field, and the subjectAltName extension from a certificate. However, as new names are added, existing ACL entries would be invalidated; this is undesirable. Thus, there is no single value that can be defined as the exported GSS-API name that will be useful in all environments. A profile of a particular X.509 GSS-API mechanism could require that a specific name be used. However, this would limit that mechanism to require a particular type of certificate. There is interest in being able to use arbitrary X.509 certificates with GSS-API for some applications.
Experience so far has not led to sufficient interoperability with GSS-API X.509 mechanisms. Even if the subject name is used, there is ambiguity in how to handle sorting of name components. Martin Rex said that he was aware of several SPKM  implementations, but that no two were fully interoperable on names. Also, as discussed in the introduction, it is desirable to support X.509 attribute certificates.
entire PAC. However, in many cases, the specific lists of security IDs contained in the PAC would be more directly useful to an application. So there may not be a good one-to-one mapping between the mechanism-specific elements and the representation desirable at the GSS-API layer. Specific name matching rules need to be developed. How do names with attributes compare? What is the effect of a name attribute on a target name in gss_accept_sec_context?
Another possibility is to provide a mechanism to acquire credentials and to provide information about the target when credentials are acquired. This would be much less of a change to GSS-API, but would not allow information received from the target to choose identity selection. With both approaches, information to communicate the needs of the application to the GSS-API mechanism will be required. For example, hinting about whether information can be cached and about the scope of cache entries is required. Another possibility can be implemented in GSS-API V2 today: Do not bind the credentials to a mechanism name until either the credentials are queried or they are used to set up a context. This is undesirable because if an application uses the credential inquiry interface, then it will get different behavior than cases where this interface is not used. For this reason, the working group favors an extension to GSS-API V3.
This proposal will significantly increase the complexity of the GSS naming architecture. As this proposal is fleshed out, we need to consider ways of managing security exposures created by this increased complexity. One area where the complexity may lead to security problems is composite names with attributes from different sources. This may be desirable so that name attributes can carry their own authentication. However, the design of any solutions needs to make sure that applications can assign appropriate trust to name components.  Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.  Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.  Zhu, L., "Generating KDC Referrals to Locate Kerberos Realms", Work in Progress, June 2006.  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.  Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.