|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
## KITTENwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: Mar 26, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
## KITTENwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
## KITTENwg
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the KITTEN working group
is reported below.
|
|
|
|
The Generic Security Services API [RFC 2743,
RFC 2744] provides an API
for applications to set up security contexts and to use these contexts
for per-message protection services. The Common Authentication
Technology Next Generation Working Group (Kitten) will work on
standardizing extensions and improvements to the core GSSAPI
specification and language bindings that the IETF believes are
necessary based on experience using GSSAPI over the last 10 years.
Extensions may be published as separate drafts or included in a GSSAPI
version 3. While version 2 of the GSSAPI may be clarified, no backward
incompatible changes will be made to this version of the API.
This working group is chartered to revise the GSSAPI v2 RFCs for the
purpose of clarifying areas of ambiguity:
|
|
| - |
Use of channel bindings
|
| - |
Thread safety restrictions
|
| - |
C language utilization clarifications and recommendations
(e.g., type utilization, name spaces)
|
| - |
Guidelines for GSS-API mechanism designers
|
| - |
Guidelines for GSS-API application protocol designers
|
| - |
Document internationalization issues
|
|
This working group is chartered to specify a non-backward compatible
GSSAPI v3 including support for the following extensions:
|
|
| - |
Clarify the portable use of channel bindings and better specify
channel bindings in a language-independent manner.
|
| - |
Specify thread safety extensions to allow multi-threaded applications
to use GSS-API
|
| - |
Define a GSS-API extension to allow applications to store
credentials.
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
## KITTENwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
RFC4178
10/2005
(22 p.)
[html]
[pdf(2)] |
L. Zhu
P. Leach
K. Jaganathan
W. Ingersoll |
|
The Simple and Protected
Generic Security Service Application Program Interface (GSS-API)
Negotiation Mechanism |
This document specifies a negotiation mechanism for the Generic
Security Service Application Program Interface (GSS-API), which is
described in RFC 2743. GSS-API peers can use this negotiation
mechanism to choose from a common set of security mechanisms. If
per-message integrity services are available on the established
mechanism context, then the negotiation is protected against an
attacker that forces the selection of a mechanism not desired by the
peers.
This mechanism replaces RFC 2478 in order to fix defects in that
specification and to describe how to inter-operate with
implementations of that specification that are commonly deployed on
the Internet.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4768
12/2006
(12 p.)
[html]
[pdf(2)] |
S. Hartman |
|
Desired Enhancements to
Generic Security Services Application Program Interface (GSS-API)
Version 3 Naming |
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
## KITTENwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
kitten-gssapi-
domain-based-
names-06
RFC Ed Queue (03/08)
Jan 24, 2008
(13 p.)
[pdf(2)]
[html]
|
N. Williams
A. Melnikov |
|
GSS-API Internationalization and Domain-Based Service Names and Name Type |
This document describes domainname-based service principal names and
the corresponding name type for the Generic Security Service
Application Programming Interface (GSS-API). Internationalization of
the GSS-API is also covered.
Domain-based service names are similar to host-based service names,
but using a domain name (not necessarily an Internet domain name) in
addition to a hostname. The primary purpose of domain-based names is
to provide a measure of protection to applications that utilize
insecure service discovery protocols. This is achieved by providing
a way to name clustered services after the "domain" which they
service, thereby allowing their clients to authorize the service's
servers based on authentication of their service names.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
## KITTENwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
## KITTENwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
kitten-extended-
mech-inquiry-04
ID Exists
Mar 21, 2008
(13 p.)
[pdf(2)]
[html]
|
N. Williams |
|
Extended Generic Security Service Mechanism Inquiry APIs |
This document introduces new application programming interfaces
(APIs) to the Generic Security Services API (GSS-API) for extended
mechanism attribute inquiry. These interfaces are primarily intended
to reduce instances of hardcoding of mechanism identifiers in GSS
applications.
These interfaces include: mechanism attributes and attribute sets, a
function for inquiring the attributes of a mechanism, a function for
indicating mechanisms that posses given attributes, and a function
for displaying mechanism attributes.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
kitten-
rfc2853bis-03
ID Exists (Recently Expired)
Aug 2, 2007
(96 p.)
[pdf(2)]
[html]
|
M. Upadhyay
S. Malkani |
|
Generic Security Service API Version 2 : Java Bindings Update |
The Generic Security Services Application Program Interface (GSS-API)
offers application programmers uniform access to security services
atop a variety of underlying cryptographic mechanisms. This document
updates the Java bindings for the GSS-API that are specified in
"Generic Security Service API version 2 : Java Bindings" (RFC 2853).
This document obsoletes RFC 2853 by making specific and incremental
clarifications and corrections to it in response to identification of
transcription errors and implementation experience.
The GSS-API is described at a language independent conceptual level
in "Generic Security Service Application Program Interface Version 2,
Update 1" (RFC 2743). The GSS-API allows a caller application to
authenticate a principal identity, to delegate rights to a peer, and
to apply security services such as confidentiality and integrity on a
per-message basis. Examples of security mechanisms defined for GSS-
API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The
Kerberos Version 5 GSS-API Mechanism (RFC 4121).
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
## KITTENwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
|
|
