GSSAPI Mechanisms without a Single Canonical Name
draft-hartman-gss-naming-01

Document Type Expired Internet-Draft (individual)
Author Sam Hartman 
Last updated 2004-10-25
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-hartman-gss-naming-01.txt

Abstract

The Generic Security Services API (GSSAPI) uses name-based authorization. GSSAPI authenticates two named parties to each other. Names can be stored on access control lists to make authorization decisions. Advances in security mechanisms require this model to be extended. Some mechanisms such as public-key mechanisms do not have a single name to be used. Other mechanisms such as Kerberos allow names to change as people move around organizations. This document proposes expanding the definition of GSSAPI names to deal with these situations.

Authors

Sam Hartman (hartmans-ietf@mit.edu)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)