RFC 4768: Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming
In plain English — editorial summary, not part of the RFC
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. This memo provides information for the Internet community.
Document record
- Document ID
- RFC4768
- Published
- December 2006
- Authors
- S. Hartman
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- sec
- Pages
- 12
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 5661Network File System (NFS) Version 4 Minor Version 1 ProtocolObsoleted
January 2010
- RFC 5397WebDAV Current Principal ExtensionCurrent
December 2008
- RFC 5575Dissemination of Flow Specification RulesObsoleted
August 2009
- RFC 6192Protecting the Router Control PlaneCurrent
March 2011
- RFC 8519YANG Data Model for Network Access Control Lists (ACLs)Current
March 2019
- RFC 9288Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit RoutersCurrent
August 2022
- RFC 4767The Intrusion Detection Exchange Protocol (IDXP)Current
March 2007
- RFC 4766Intrusion Detection Message Exchange RequirementsCurrent
March 2007
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?