[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS gss/doc/specification
From: |
gss-commit |
Subject: |
CVS gss/doc/specification |
Date: |
Tue, 15 Feb 2005 19:58:38 +0100 |
Update of /home/cvs/gss/doc/specification
In directory dopio:/tmp/cvs-serv23220
Added Files:
draft-ietf-kitten-stackable-pseudo-mechs-00.txt
Log Message:
Add.
---
/home/cvs/gss/doc/specification/draft-ietf-kitten-stackable-pseudo-mechs-00.txt
2005/02/15 18:58:38 NONE
+++
/home/cvs/gss/doc/specification/draft-ietf-kitten-stackable-pseudo-mechs-00.txt
2005/02/15 18:58:38 1.1
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: August 12, 2005 February 11, 2005
Stackable Generic Security Service Pseudo-Mechanisms
draft-ietf-kitten-stackable-pseudo-mechs-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 12, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document defines and formalizes the concept of stackable
pseudo-mechanisms, and associated concept of composite mechanisms,
for the Generic Security Service Application Programming Interface
(GSS-API), as well as several utility functions.
Stackable GSS-API pseudo-mechanisms allow for the composition of new
mechanisms that combine features from multiple mechanisms. Stackable
mechanisms that add support for Perfect Forward Security (PFS), data
compression, additional authentication factors, etc... are
facilitated by this document.
Williams Expires August 12, 2005 [Page 1]
Internet-Draft Stackable GSS Mechs February 2005
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanism Composition Issues . . . . . . . . . . . . . . . . 4
4. Mechanism Composition . . . . . . . . . . . . . . . . . . . 5
4.1 Construction of Composed Mechanism OIDs . . . . . . . . . . 5
4.2 Mechanism Composition Rules . . . . . . . . . . . . . . . . 6
4.3 Interfacing with Composite Mechanisms . . . . . . . . . . . 7
4.4 Compatibility with the Basic GSS-APIv2u1 Interfaces . . . . 7
4.5 Processing of Tokens for Composite Mechanisms . . . . . . . 8
5. New GSS-API Interfaces . . . . . . . . . . . . . . . . . . . 8
5.1 New GSS-API Function Interfaces . . . . . . . . . . . . . . 9
5.1.1 GSS_Compose_oid() . . . . . . . . . . . . . . . . . . . . . 9
5.1.2 GSS_Decompose_oid() . . . . . . . . . . . . . . . . . . . . 10
5.1.3 GSS_Release_oid() . . . . . . . . . . . . . . . . . . . . . 10
5.1.4 GSS_Indicate_negotiable_mechs() . . . . . . . . . . . . . . 11
5.1.5 GSS_Negotiate_mechs() . . . . . . . . . . . . . . . . . . . 12
5.1.6 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Negotiation of Composite Mechanisms . . . . . . . . . . . . 13
6.1 Negotiation of Composite Mechanisms Through SPNEGO . . . . . 14
7. Requirements for Mechanism Designers . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
9. Security considerations . . . . . . . . . . . . . . . . . . 14
10. Normative . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 16
Williams Expires August 12, 2005 [Page 2]
Internet-Draft Stackable GSS Mechs February 2005
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
Recent discussions within the IETF have shown the need for a
refactoring of the features that GSS-API mechanisms may provide and a
way to compose new mechanisms from smaller components.
One way to do this is to "stack" multiple mechanisms on top of each
other such that the features of all of them are summed into a new,
composite mechanism.
One existing GSS-API mechanism, LIPKEY [LIPKEY], is essentially
stacked over another, SPKM-3 [LIPKEY] (although LIPKEY does not
conform to the stackable pseduo-mechanism framework described
herein).
The first truly stackable pseudo-mechanism proposed, CCM [CCM], is
intended for signalling, during negotiation of mechanisms, the
willingness of an initiator and/or acceptor to utilize channel
bindings
Since then other similar mechanism compositing needs and ideas have
come up, along with problems such as "what combinations are possible,
useful, reasonable and secure?" This document addresses those
problems. It introduces the concepts of stackable pseudo-mechanisms,
composite mechanisms and mechanism features or attributes, as well as
new inquiry and related interfaces to help in the mechanism
compositing.
(Mechanism features are more formally referred to as "mechanism
attributes" below. The terms "feature" and mechanism attribute" are
sometimes used interchangeably.)
2.1 Glossary
Concrete GSS-API mechanism
A mechanism which can be used standalone. Examples include: the
Kerberos V mechanism [CFX], SPKM-1/2 [SPKM] and SPKM-3 [LIPKEY].
GSS-API Pseudo-mechanism
A mechanism which uses other mechanisms in the construction of its
context and/or per-message tokens and security contexts. SPNEGO
is an example of this.
Williams Expires August 12, 2005 [Page 3]
Internet-Draft Stackable GSS Mechs February 2005
Stackable GSS-API pseudo-mechanism
A mechanism which uses a single other mechanism in the
construction of its tokens such that the OID of the composite
result can be constructed by prepending the OID of the stackable
pseudo-mechanism to the OID of the mechanism to be used by it.
Mechanism-negotiation GSS-API pseudo-mechanism
A GSS-API mechanism that negotiates the use of GSS-API mechanisms.
SPNEGO [SPNEGO] is an example of this.
3. Mechanism Composition Issues
Interfacing with composite mechanisms through the existing GSS-API
interfaces and the handling of composite mechanism tokens is
straightforward enough and described in Section 4.
However, the concepts of stackable and composite mechanisms do give
rise to several minor problems:
o How to determine allowable combinations of mechanisms;
o How to encode composite mechanism OIDs;
o How to decompose the OID of a composite mechanism and process its
tokens properly;
o Application interfacing issues such as:
* Whether and/or which composite mechanisms should be listed by
GSS_Indicate_mechs();
* Whether and/or which composite mechanisms not listed by
GSS_Indicate_mechs() may nonetheless be available for use by
applications and how applications can detect their
availability;
* What additional, if any, interfaces should be provided to help
applications select appropriate mechanisms;
o
Mechanism negotiation issues (related to the application interface
issues listed above), such as: vspace blankLines='1'/>
* Should applications advertise composite mechanisms in SPNEGO or
other application-specific mechanism negotiation contexts?
* Or should applications implicitly advertise composite
mechanisms by advertising concrete and stackable
pseudo-mechanisms in SPNEGO or other application-specific
mechanism negotiation contexts?
Section 4 addresses the OID composition, decomposition and encoding
issues, as well as basic interfacing and token handling issues.
Section 5 addresses interfacing issues more generally through the
Williams Expires August 12, 2005 [Page 4]
Internet-Draft Stackable GSS Mechs February 2005
specification of additional, optional APIs.
Section 6 addresses mechanism negotiation issues.
4. Mechanism Composition
Mechanism composition by stacking pseudo-mechanisms on a concrete
mechanism is conceptually simple: join the OIDs of the several
mechanisms in question and process GSS-API tokens and routine calls
through the top-most pseudo-mechanism in a stack, which can then, if
necessary, recursively call the GSS-API to process any tokens for the
remainder of the stack.
Some stackable pseudo-mechanisms may do nothing more than perform
transformations on application data (e.g., compression); such
pseudo-mechanisms will generally chain the processing of tokens and
routine calls to the mechanisms below them in the stack.
Other stackable pseudo-mechanisms may utilize the mechanisms below
them only during security context setup. For example, a stackable
pseudo-mechanism could perform a Diffie-Hellman key exchange and
authenticate it by binding a security context established with the
mechanism stacked below it; such a mechanism would provide its own
per-message tokens.
4.1 Construction of Composed Mechanism OIDs
Composition of mechanism OIDs is simple: prepend the OID of one
pseudo-mechanism to the OID of another mechanism (composite or
otherwise), but there MUST always be at least one final mechanism OID
and it MUST be useful standalone (i.e., it MUST NOT be a
pseudo-mechanism). A composite mechanism OID forms, essentially, a
stack.
The encoding of composed mechanism OIDs is not quite the
concatenation of the component OIDs' encodings, however. This is
because the first two arcs of ASN.1 OIDs are encoded differently from
subsequent arcs (the first two arcs have a limited namespace and are
encoded as a single octet), so were composite mechanism OIDs to be
encoded as the concatenation of the component OIDs the result would
not decode as the concatenation of the component OIDs. To avoid this
problem the first two arcs of each component of a composite mechanism
OID, other than the leading component, will be encoded as other arcs
would.
Decomposition of composite mechanism OIDs is similar, with each
pseudo-mechanism in the stack being able to determine the OID suffix
from knowledge of its own OID(s).
Williams Expires August 12, 2005 [Page 5]
Internet-Draft Stackable GSS Mechs February 2005
New pseudo-mechanisms MAY be allocated OIDs from the prefix given
below as follows by assignment of a sub-string of OID arcs to be
appended to this prefix. This prefix OID is:
<TBD> [1.3.6.1.5.5.11 appears to be available, registration w/ IANA
TBD]
All OID allocations below this OID MUST be for stackable pseudo-
mechanisms and MUST consist of a single arc. This will make it
possible to decompose the OIDs of composite mechanisms without
necessarily knowing a priori the OIDs of the component stackable
pseudo-mechanisms.
4.2 Mechanism Composition Rules
All new stackable pseudo-mechanisms MUST specify the rules for
determining whether they can stack above a given mechanism, composite
or otherwise. Such rules may be based on specific mechanism
attribute OID sets [EXTENDED-INQUIRY] and/or specific mechanism OIDs
(composite and otherwise).
All stackable pseudo-mechanisms MUST have the following mechanism
composition rule relating to unknown mechanism attributes:
o composition with mechanisms supporting unknown mechanism
attributes MUST NOT be permitted.
This rule protects against compositions which cannot be considered
today but which might nonetheless arise due to the introduction of
new mechanisms and which might turn out to be insecure or otherwise
undesirable.
Mechanism composition rules for stackable pseudo-mechanisms MAY and
SHOULD be updated as new GSS-API mechanism attributes and mechanisms
sporting them are introduced. The specifications of mechanisms that
introduce new mechanism attributes or which otherwise should not be
combined with others in ways which would be permitted under existing
rules SHOULD also update the mechanism composition rules of affected
pseudo-mechanisms.
A RECOMMENDED way to describe the stacking rules for stackable
mechanisms is as an ordered sequence of "MAY stack above X
mechanism," "REQUIRES Y mechanism feature(s)," "MUST NOT stack above
Z mechanism," and/or "MUST NOT stack above a mechanism with Z
mechanism feature(s)."
For example a stackable mechanism that provides its own per-msg
tokens and does not use the underlying mechnism's per-msg token
Williams Expires August 12, 2005 [Page 6]
Internet-Draft Stackable GSS Mechs February 2005
facilities might require a rule such as "MUST NOT stack above a
mechanism with the GSS_C_MA_COMPRESS mechanism feature."
4.3 Interfacing with Composite Mechanisms
The basic GSS-API [RFC2743] interfaces MUST NOT accept as input or
provide as output the OID of any stackable pseudo-mechanism.
Composite mechanisms MUST be treated as concrete mechanisms by the
basic GSS-API interfaces [RFC2743].
Thus the way in which a composite mechanism is used by applications
with the basic GSS-API (version 2, update 1) is straightforward:
exactly as if composite mechanisms were normal GSS-API mechanisms.
This is facilitated by the fact that in all cases where the GSS-API
implementation might need to know how to process or create a token it
has the necessary contextual information, that is, the mechanism OID,
available and can decompose composite mechanism OIDs as necessary.
For example, for initial GSS_Init_sec_context() calls the
implementation knows the desired mechanism OID, and if it should be
left unspecified, it can pick a default mechanism given the initiator
credentials provided by the application (and if none are provided
other default mechanism and credential selections can still be made).
For subsequent calls to GSS_Init_sec_context() the implementation
knows which mechanism to use from the given [partially established]
security context. Similarly for GSS_Accept_sec_context, where on
initial calls the mechanism OID can be determined from the given
initial context token's framing.
The manner in which GSS-API implementations and the various
mechanisms and pseudo-mechanisms interface with one another is left
as an excercise to implementors.
4.4 Compatibility with the Basic GSS-APIv2u1 Interfaces
In order to preserve backwards compatibility with applications that
use only the basic GSS-API interfaces (version 2, update 1), several
restrictions are imposed on the use of composite and stackable
pseduo-mechanisms with the basic GSS-API interfaces:
o GSS_Indicate_mechs() MUST NOT indicate support for any stackable
pseduo-mechanisms under any circumstance.
o GSS_Indicate_mechs() MAY indicate support for some, all or none of
the available composite mechanisms.
o Which composite mechanisms, if any, are indicated through
GSS_Indicate_mechs() SHOULD be configurable.
o Composite mechanisms which are not indicated by
Williams Expires August 12, 2005 [Page 7]
Internet-Draft Stackable GSS Mechs February 2005
GSS_Indicate_mechs() MUST NOT be considered as the default
mechanism (GSS_C_NULL_OID) or as part of the default mechanism set
(GSS_C_NULL_OID_SET).
o The OIDs of 'stackable' (not composite) pseudo-mechanisms MUST NOT
be accepted as inputs or produced in the output of any of the
[497 lines skipped]
- CVS gss/doc/specification, gss-commit, 2005/02/02
- CVS gss/doc/specification, gss-commit, 2005/02/15
- CVS gss/doc/specification,
gss-commit <=
- CVS gss/doc/specification, gss-commit, 2005/02/15
- CVS gss/doc/specification, gss-commit, 2005/02/16
- CVS gss/doc/specification, gss-commit, 2005/02/16
- CVS gss/doc/specification, gss-commit, 2005/02/23