GSSAPI Mechanisms without a Single Canonical Name
draft-hartman-gss-naming-01
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Author | Sam Hartman | ||
Last updated | 2004-10-25 | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)