Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming
RFC 4768
Document | Type | RFC - Informational (December 2006; No errata) | |
---|---|---|---|
Author | Sam Hartman | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4768 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | (None) |
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). Abstract The 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. Hartman Informational [Page 1] RFC 4768 GSS Names December 2006 Table of Contents 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 1. Introduction The Generic Security Services API [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. Hartman Informational [Page 2] RFC 4768 GSS Names December 2006 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 namingShow full document text