draft-ietf-kitten-stackable-pseudo-mechs-00.txt   draft-ietf-kitten-stackable-pseudo-mechs-01.txt 
NETWORK WORKING GROUP N. Williams NETWORK WORKING GROUP N. Williams
Internet-Draft Sun Internet-Draft Sun
Expires: August 12, 2005 February 11, 2005 Expires: April 19, 2006 October 16, 2005
Stackable Generic Security Service Pseudo-Mechanisms Stackable Generic Security Service Pseudo-Mechanisms
draft-ietf-kitten-stackable-pseudo-mechs-00.txt draft-ietf-kitten-stackable-pseudo-mechs-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 12, 2005. This Internet-Draft will expire on April 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines and formalizes the concept of stackable This document defines and formalizes the concept of stackable pseudo-
pseudo-mechanisms, and associated concept of composite mechanisms, mechanisms, and associated concept of composite mechanisms, for the
for the Generic Security Service Application Programming Interface Generic Security Service Application Programming Interface (GSS-API),
(GSS-API), as well as several utility functions. as well as several utility functions.
Stackable GSS-API pseudo-mechanisms allow for the composition of new Stackable GSS-API pseudo-mechanisms allow for the composition of new
mechanisms that combine features from multiple mechanisms. Stackable mechanisms that combine features from multiple mechanisms. Stackable
mechanisms that add support for Perfect Forward Security (PFS), data mechanisms that add support for Perfect Forward Security (PFS), data
compression, additional authentication factors, etc... are compression, additional authentication factors, etc... are
facilitated by this document. facilitated by this document.
Table of Contents Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . 3 1. Conventions used in this document . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanism Composition Issues . . . . . . . . . . . . . . . . 4 3. Mechanism Composition Issues . . . . . . . . . . . . . . . 4
4. Mechanism Composition . . . . . . . . . . . . . . . . . . . 5 4. Mechanism Composition . . . . . . . . . . . . . . . . . . 5
4.1 Construction of Composed Mechanism OIDs . . . . . . . . . . 5 4.1. Construction of Composed Mechanism OIDs . . . . . . . . . 5
4.2 Mechanism Composition Rules . . . . . . . . . . . . . . . . 6 4.2. Mechanism Composition Rules . . . . . . . . . . . . . . . 6
4.3 Interfacing with Composite Mechanisms . . . . . . . . . . . 7 4.3. Interfacing with Composite Mechanisms . . . . . . . . . . 7
4.4 Compatibility with the Basic GSS-APIv2u1 Interfaces . . . . 7 4.4. Compatibility with the Basic GSS-APIv2u1 Interfaces . . . 7
4.5 Processing of Tokens for Composite Mechanisms . . . . . . . 8 4.5. Processing of Tokens for Composite Mechanisms . . . . . . 8
5. New GSS-API Interfaces . . . . . . . . . . . . . . . . . . . 8 5. New GSS-API Interfaces . . . . . . . . . . . . . . . . . . 8
5.1 New GSS-API Function Interfaces . . . . . . . . . . . . . . 9 5.1. New GSS-API Function Interfaces . . . . . . . . . . . . . 9
5.1.1 GSS_Compose_oid() . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. GSS_Compose_oid() . . . . . . . . . . . . . . . . . . . . 9
5.1.2 GSS_Decompose_oid() . . . . . . . . . . . . . . . . . . . . 10 5.1.2. GSS_Decompose_oid() . . . . . . . . . . . . . . . . . . . 10
5.1.3 GSS_Release_oid() . . . . . . . . . . . . . . . . . . . . . 10 5.1.3. GSS_Release_oid() . . . . . . . . . . . . . . . . . . . . 10
5.1.4 GSS_Indicate_negotiable_mechs() . . . . . . . . . . . . . . 11 5.1.4. GSS_Indicate_negotiable_mechs() . . . . . . . . . . . . . 11
5.1.5 GSS_Negotiate_mechs() . . . . . . . . . . . . . . . . . . . 12 5.1.5. GSS_Negotiate_mechs() . . . . . . . . . . . . . . . . . . 12
5.1.6 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.6. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Negotiation of Composite Mechanisms . . . . . . . . . . . . 13 6. Negotiation of Composite Mechanisms . . . . . . . . . . . 13
6.1 Negotiation of Composite Mechanisms Through SPNEGO . . . . . 14 6.1. Negotiation of Composite Mechanisms Through SPNEGO . . . . 14
7. Requirements for Mechanism Designers . . . . . . . . . . . . 14 7. Requirements for Mechanism Designers . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 14
9. Security considerations . . . . . . . . . . . . . . . . . . 14 9. Security considerations . . . . . . . . . . . . . . . . . 14
10. Normative . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Normative . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . 17
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Recent discussions within the IETF have shown the need for a Recent discussions within the IETF have shown the need for a
skipping to change at page 3, line 43 skipping to change at page 3, line 43
useful, reasonable and secure?" This document addresses those useful, reasonable and secure?" This document addresses those
problems. It introduces the concepts of stackable pseudo-mechanisms, problems. It introduces the concepts of stackable pseudo-mechanisms,
composite mechanisms and mechanism features or attributes, as well as composite mechanisms and mechanism features or attributes, as well as
new inquiry and related interfaces to help in the mechanism new inquiry and related interfaces to help in the mechanism
compositing. compositing.
(Mechanism features are more formally referred to as "mechanism (Mechanism features are more formally referred to as "mechanism
attributes" below. The terms "feature" and mechanism attribute" are attributes" below. The terms "feature" and mechanism attribute" are
sometimes used interchangeably.) sometimes used interchangeably.)
2.1 Glossary 2.1. Glossary
Concrete GSS-API mechanism Concrete GSS-API mechanism
A mechanism which can be used standalone. Examples include: the A mechanism which can be used standalone. Examples include: the
Kerberos V mechanism [CFX], SPKM-1/2 [SPKM] and SPKM-3 [LIPKEY]. Kerberos V mechanism [CFX], SPKM-1/2 [SPKM] and SPKM-3 [LIPKEY].
GSS-API Pseudo-mechanism GSS-API Pseudo-mechanism
A mechanism which uses other mechanisms in the construction of its A mechanism which uses other mechanisms in the construction of its
context and/or per-message tokens and security contexts. SPNEGO context and/or per-message tokens and security contexts. SPNEGO
is an example of this. is an example of this.
skipping to change at page 4, line 45 skipping to change at page 4, line 46
availability; availability;
* What additional, if any, interfaces should be provided to help * What additional, if any, interfaces should be provided to help
applications select appropriate mechanisms; applications select appropriate mechanisms;
o o
Mechanism negotiation issues (related to the application interface Mechanism negotiation issues (related to the application interface
issues listed above), such as: vspace blankLines='1'/> issues listed above), such as: vspace blankLines='1'/>
* Should applications advertise composite mechanisms in SPNEGO or * Should applications advertise composite mechanisms in SPNEGO or
other application-specific mechanism negotiation contexts? other application-specific mechanism negotiation contexts?
* Or should applications implicitly advertise composite * Or should applications implicitly advertise composite
mechanisms by advertising concrete and stackable mechanisms by advertising concrete and stackable pseudo-
pseudo-mechanisms in SPNEGO or other application-specific mechanisms in SPNEGO or other application-specific mechanism
mechanism negotiation contexts? negotiation contexts?
Section 4 addresses the OID composition, decomposition and encoding Section 4 addresses the OID composition, decomposition and encoding
issues, as well as basic interfacing and token handling issues. issues, as well as basic interfacing and token handling issues.
Section 5 addresses interfacing issues more generally through the Section 5 addresses interfacing issues more generally through the
specification of additional, optional APIs. specification of additional, optional APIs.
Section 6 addresses mechanism negotiation issues. Section 6 addresses mechanism negotiation issues.
4. Mechanism Composition 4. Mechanism Composition
Mechanism composition by stacking pseudo-mechanisms on a concrete Mechanism composition by stacking pseudo-mechanisms on a concrete
mechanism is conceptually simple: join the OIDs of the several mechanism is conceptually simple: join the OIDs of the several
mechanisms in question and process GSS-API tokens and routine calls mechanisms in question and process GSS-API tokens and routine calls
through the top-most pseudo-mechanism in a stack, which can then, if 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 necessary, recursively call the GSS-API to process any tokens for the
remainder of the stack. remainder of the stack.
Some stackable pseudo-mechanisms may do nothing more than perform Some stackable pseudo-mechanisms may do nothing more than perform
transformations on application data (e.g., compression); such transformations on application data (e.g., compression); such pseudo-
pseudo-mechanisms will generally chain the processing of tokens and mechanisms will generally chain the processing of tokens and routine
routine calls to the mechanisms below them in the stack. calls to the mechanisms below them in the stack.
Other stackable pseudo-mechanisms may utilize the mechanisms below Other stackable pseudo-mechanisms may utilize the mechanisms below
them only during security context setup. For example, a stackable them only during security context setup. For example, a stackable
pseudo-mechanism could perform a Diffie-Hellman key exchange and pseudo-mechanism could perform a Diffie-Hellman key exchange and
authenticate it by binding a security context established with the authenticate it by binding a security context established with the
mechanism stacked below it; such a mechanism would provide its own mechanism stacked below it; such a mechanism would provide its own
per-message tokens. per-message tokens.
4.1 Construction of Composed Mechanism OIDs 4.1. Construction of Composed Mechanism OIDs
Composition of mechanism OIDs is simple: prepend the OID of one Composition of mechanism OIDs is simple: prepend the OID of one
pseudo-mechanism to the OID of another mechanism (composite or pseudo-mechanism to the OID of another mechanism (composite or
otherwise), but there MUST always be at least one final mechanism OID 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 and it MUST be useful standalone (i.e., it MUST NOT be a pseudo-
pseudo-mechanism). A composite mechanism OID forms, essentially, a mechanism). A composite mechanism OID forms, essentially, a stack.
stack.
The encoding of composed mechanism OIDs is not quite the The encoding of composed mechanism OIDs is not quite the
concatenation of the component OIDs' encodings, however. This is concatenation of the component OIDs' encodings, however. This is
because the first two arcs of ASN.1 OIDs are encoded differently from 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 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 a single octet), so were composite mechanism OIDs to be
encoded as the concatenation of the component OIDs the result would encoded as the concatenation of the component OIDs the result would
not decode as the concatenation of the component OIDs. To avoid this not decode as the concatenation of the component OIDs. To avoid this
problem the first two arcs of each component of a composite mechanism problem the first two arcs of each component of a composite mechanism
OID, other than the leading component, will be encoded as other arcs OID, other than the leading component, will be encoded as other arcs
skipping to change at page 6, line 18 skipping to change at page 6, line 22
<TBD> [1.3.6.1.5.5.11 appears to be available, registration w/ IANA <TBD> [1.3.6.1.5.5.11 appears to be available, registration w/ IANA
TBD] TBD]
All OID allocations below this OID MUST be for stackable pseudo- All OID allocations below this OID MUST be for stackable pseudo-
mechanisms and MUST consist of a single arc. This will make it mechanisms and MUST consist of a single arc. This will make it
possible to decompose the OIDs of composite mechanisms without possible to decompose the OIDs of composite mechanisms without
necessarily knowing a priori the OIDs of the component stackable necessarily knowing a priori the OIDs of the component stackable
pseudo-mechanisms. pseudo-mechanisms.
4.2 Mechanism Composition Rules 4.2. Mechanism Composition Rules
All new stackable pseudo-mechanisms MUST specify the rules for All new stackable pseudo-mechanisms MUST specify the rules for
determining whether they can stack above a given mechanism, composite determining whether they can stack above a given mechanism, composite
or otherwise. Such rules may be based on specific mechanism or otherwise. Such rules may be based on specific mechanism
attribute OID sets [EXTENDED-INQUIRY] and/or specific mechanism OIDs attribute OID sets [EXTENDED-INQUIRY] and/or specific mechanism OIDs
(composite and otherwise). (composite and otherwise).
All stackable pseudo-mechanisms MUST have the following mechanism All stackable pseudo-mechanisms MUST have the following mechanism
composition rule relating to unknown mechanism attributes: composition rule relating to unknown mechanism attributes:
skipping to change at page 7, line 7 skipping to change at page 7, line 11
mechanisms is as an ordered sequence of "MAY stack above X mechanisms is as an ordered sequence of "MAY stack above X
mechanism," "REQUIRES Y mechanism feature(s)," "MUST NOT stack above mechanism," "REQUIRES Y mechanism feature(s)," "MUST NOT stack above
Z mechanism," and/or "MUST NOT stack above a mechanism with Z Z mechanism," and/or "MUST NOT stack above a mechanism with Z
mechanism feature(s)." mechanism feature(s)."
For example a stackable mechanism that provides its own per-msg For example a stackable mechanism that provides its own per-msg
tokens and does not use the underlying mechnism's per-msg token tokens and does not use the underlying mechnism's per-msg token
facilities might require a rule such as "MUST NOT stack above a facilities might require a rule such as "MUST NOT stack above a
mechanism with the GSS_C_MA_COMPRESS mechanism feature." mechanism with the GSS_C_MA_COMPRESS mechanism feature."
4.3 Interfacing with Composite Mechanisms 4.3. Interfacing with Composite Mechanisms
The basic GSS-API [RFC2743] interfaces MUST NOT accept as input or The basic GSS-API [RFC2743] interfaces MUST NOT accept as input or
provide as output the OID of any stackable pseudo-mechanism. provide as output the OID of any stackable pseudo-mechanism.
Composite mechanisms MUST be treated as concrete mechanisms by the Composite mechanisms MUST be treated as concrete mechanisms by the
basic GSS-API interfaces [RFC2743]. basic GSS-API interfaces [RFC2743].
Thus the way in which a composite mechanism is used by applications Thus the way in which a composite mechanism is used by applications
with the basic GSS-API (version 2, update 1) is straightforward: with the basic GSS-API (version 2, update 1) is straightforward:
exactly as if composite mechanisms were normal GSS-API mechanisms. exactly as if composite mechanisms were normal GSS-API mechanisms.
skipping to change at page 7, line 38 skipping to change at page 7, line 42
For subsequent calls to GSS_Init_sec_context() the implementation For subsequent calls to GSS_Init_sec_context() the implementation
knows which mechanism to use from the given [partially established] knows which mechanism to use from the given [partially established]
security context. Similarly for GSS_Accept_sec_context, where on security context. Similarly for GSS_Accept_sec_context, where on
initial calls the mechanism OID can be determined from the given initial calls the mechanism OID can be determined from the given
initial context token's framing. initial context token's framing.
The manner in which GSS-API implementations and the various The manner in which GSS-API implementations and the various
mechanisms and pseudo-mechanisms interface with one another is left mechanisms and pseudo-mechanisms interface with one another is left
as an excercise to implementors. as an excercise to implementors.
4.4 Compatibility with the Basic GSS-APIv2u1 Interfaces 4.4. Compatibility with the Basic GSS-APIv2u1 Interfaces
In order to preserve backwards compatibility with applications that In order to preserve backwards compatibility with applications that
use only the basic GSS-API interfaces (version 2, update 1), several use only the basic GSS-API interfaces (version 2, update 1), several
restrictions are imposed on the use of composite and stackable restrictions are imposed on the use of composite and stackable
pseduo-mechanisms with the basic GSS-API interfaces: pseduo-mechanisms with the basic GSS-API interfaces:
o GSS_Indicate_mechs() MUST NOT indicate support for any stackable o GSS_Indicate_mechs() MUST NOT indicate support for any stackable
pseduo-mechanisms under any circumstance. pseduo-mechanisms under any circumstance.
o GSS_Indicate_mechs() MAY indicate support for some, all or none of o GSS_Indicate_mechs() MAY indicate support for some, all or none of
the available composite mechanisms. the available composite mechanisms.
o Which composite mechanisms, if any, are indicated through o Which composite mechanisms, if any, are indicated through
GSS_Indicate_mechs() SHOULD be configurable. GSS_Indicate_mechs() SHOULD be configurable.
o Composite mechanisms which are not indicated by o Composite mechanisms which are not indicated by
GSS_Indicate_mechs() MUST NOT be considered as the default GSS_Indicate_mechs() MUST NOT be considered as the default
mechanism (GSS_C_NULL_OID) or as part of the default mechanism set mechanism (GSS_C_NULL_OID) or as part of the default mechanism set
(GSS_C_NULL_OID_SET). (GSS_C_NULL_OID_SET).
o The OIDs of 'stackable' (not composite) pseudo-mechanisms MUST NOT o The OIDs of *stackable* (not composite) pseudo-mechanisms MUST NOT
be accepted as inputs or produced in the output of any of the be accepted as inputs or produced in the output of any of the
basic GSS-APIv2, update 1 API functions, except for any OID set basic GSS-APIv2, update 1 API functions, except for any OID set
construction/iteration functions. And, if present in any OID SET construction/iteration functions. And, if present in any OID SET
input parameters of GSS-APIv2, update 1 functions, they MUST be input parameters of GSS-APIv2, update 1 functions, they MUST be
ignored. ignored.
o The OIDs of 'stackable' (not composite) pseudo-mechanisms MAY only o The OIDs of *stackable* (not composite) pseudo-mechanisms MAY only
be used as inputs or produced as outputs of functions whose be used as inputs or produced as outputs of functions whose
specification explicitly allows for them or which are concerned specification explicitly allows for them or which are concerned
with the creation/iteration of OID containters, such as OID SETs. with the creation/iteration of OID containters, such as OID SETs.
4.5 Processing of Tokens for Composite Mechanisms 4.5. Processing of Tokens for Composite Mechanisms
The initial context token for any standard mechanism, including The initial context token for any standard mechanism, including
mechanisms composited from standard pseudo- and concrete mechanisms, mechanisms composited from standard pseudo- and concrete mechanisms,
MUST be encapsulated as described in section 3.1 of rfc2743 MUST be encapsulated as described in section 3.1 of rfc2743
[RFC2743], and the OID used in that framing MUST be that of the [RFC2743], and the OID used in that framing MUST be that of the
mechanism, but in the case of composite mechanisms this OID MUST be mechanism, but in the case of composite mechanisms this OID MUST be
the OID of the leading component of the composite mechanism. the OID of the leading component of the composite mechanism.
Note that this has implications for pluggable multi-mechanism Note that this has implications for pluggable multi-mechanism
implementations of the GSS-API, namely that acceptors must route implementations of the GSS-API, namely that acceptors must route
skipping to change at page 8, line 51 skipping to change at page 9, line 8
Utility functions for mechanism OID composition and decomposition are Utility functions for mechanism OID composition and decomposition are
given in sections 5.1.1, 5.1.2 and 5.1.3. given in sections 5.1.1, 5.1.2 and 5.1.3.
Two utility functions, GSS_Indicate_negotiable_mechs() and Two utility functions, GSS_Indicate_negotiable_mechs() and
GSS_Negotiate_mechs(), to aid applications in mechanism negotiation GSS_Negotiate_mechs(), to aid applications in mechanism negotiation
are described in sections 5.1.4 and 5.1.5. These two interfaces may are described in sections 5.1.4 and 5.1.5. These two interfaces may
be implemented entirely in terms of the other interfaces described be implemented entirely in terms of the other interfaces described
herein. herein.
5.1 New GSS-API Function Interfaces 5.1. New GSS-API Function Interfaces
Several new interfaces are given by which, for example, GSS-API Several new interfaces are given by which, for example, GSS-API
applications may determine what features are provided by a given applications may determine what features are provided by a given
mechanism, what mechanisms provide what features and what mechanism, what mechanisms provide what features and what
compositions are legal. compositions are legal.
These new interfaces are all OPTIONAL. These new interfaces are all OPTIONAL.
In order to preserve backwards compatibility with applications that In order to preserve backwards compatibility with applications that
do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate
support for any stackable pseduo-mechanisms. GSS_Indicate_mechs() support for any stackable pseduo-mechanisms. GSS_Indicate_mechs()
skipping to change at page 9, line 30 skipping to change at page 9, line 36
GSS_Indicate_mechs(). GSS_Indicate_mechs().
Applications SHOULD use GSS_Indicate_mechs_by_mech_attrs() instead of Applications SHOULD use GSS_Indicate_mechs_by_mech_attrs() instead of
GSS_Indicate_mechs() wherever possible. GSS_Indicate_mechs() wherever possible.
Applications can use GSS_Indicate_mechs_by_mech_attrs() to determine Applications can use GSS_Indicate_mechs_by_mech_attrs() to determine
what, if any, mechanisms provide a given set of features. what, if any, mechanisms provide a given set of features.
GSS_Indicate_mechs_by_mech_attrs() can also be used to indicate (as GSS_Indicate_mechs_by_mech_attrs() can also be used to indicate (as
in GSS_Indicate_mechs()) the set of available mechanisms of each type in GSS_Indicate_mechs()) the set of available mechanisms of each type
(concrete, mechanism negotiation pseudo-mechanism, stackable (concrete, mechanism negotiation pseudo-mechanism, stackable pseudo-
pseudo-mechanism and composite mechanisms). mechanism and composite mechanisms).
Applications may use GSS_Inquire_mech_attrs_for_mech() to test Applications may use GSS_Inquire_mech_attrs_for_mech() to test
whether a given composite mechanism is available and the set of whether a given composite mechanism is available and the set of
features that it offers. features that it offers.
GSS_Negotiate_mechs() may be used to negotiate the use of mechanisms GSS_Negotiate_mechs() may be used to negotiate the use of mechanisms
such that composite mechanisms need not be advertised but instead be such that composite mechanisms need not be advertised but instead be
implied by offering stackable pseudo-mechanisms. implied by offering stackable pseudo-mechanisms.
5.1.1 GSS_Compose_oid() 5.1.1. GSS_Compose_oid()
Inputs: Inputs:
o mech1 OBJECT IDENTIFIER, -- mechanism OID o mech1 OBJECT IDENTIFIER, -- mechanism OID
o mech2 OBJECT IDENTIFIER -- mechanism OID o mech2 OBJECT IDENTIFIER -- mechanism OID
Outputs: Outputs:
o major_status INTEGER, o major_status INTEGER,
o minor_status INTEGER, o minor_status INTEGER,
o composite OBJECT IDENTIFIER -- OID composition of mech1 with o composite OBJECT IDENTIFIER -- OID composition of mech1 with mech2
mech2 ({mech1 mech2}) ({mech1 mech2})
Return major_status codes: Return major_status codes:
o GSS_S_COMPLETE indicates success. o GSS_S_COMPLETE indicates success.
o GSS_S_BAD_MECH indicates that mech1 is not supported. o GSS_S_BAD_MECH indicates that mech1 is not supported.
o GSS_S_FAILURE indicates that the request failed for some other o GSS_S_FAILURE indicates that the request failed for some other
reason. The minor status will be specific to mech1 and may reason. The minor status will be specific to mech1 and may
provide further information. provide further information.
5.1.2 GSS_Decompose_oid() 5.1.2. GSS_Decompose_oid()
Inputs: Inputs:
o input_mech OBJECT IDENTIFIER, -- mechanism OID. o input_mech OBJECT IDENTIFIER, -- mechanism OID.
o mechs SET OF OBJECT IDENTIFIER -- mechanism OIDs (if o mechs SET OF OBJECT IDENTIFIER -- mechanism OIDs (if
GSS_C_NULL_OID_SET defaults to the set of stackable GSS_C_NULL_OID_SET defaults to the set of stackable pseudo-
pseudo-mechanism OIDs indicated by mechanism OIDs indicated by GSS_Indicate_mechs_by_mech_attrs()).
GSS_Indicate_mechs_by_mech_attrs()).
Outputs: Outputs:
o major_status INTEGER, o major_status INTEGER,
o minor_status INTEGER, o minor_status INTEGER,
o lead_mech OBJECT IDENTIFIER, -- leading stackable pseudo- o lead_mech OBJECT IDENTIFIER, -- leading stackable pseudo-
mechanism OID. mechanism OID.
o trail_mech OBJECT IDENTIFIER -- input_mech with lead_mech removed o trail_mech OBJECT IDENTIFIER -- input_mech with lead_mech removed
from the front. from the front.
Return major_status codes: Return major_status codes:
o GSS_S_COMPLETE indicates success. o GSS_S_COMPLETE indicates success.
o GSS_S_BAD_MECH indicates that the input_mech could not be o GSS_S_BAD_MECH indicates that the input_mech could not be
decomposed as no stackable pseudo-mechanism is available whose OID decomposed as no stackable pseudo-mechanism is available whose OID
is a prefix of the input_mech. is a prefix of the input_mech.
o GSS_S_FAILURE indicates that the request failed for some other o GSS_S_FAILURE indicates that the request failed for some other
reason. reason.
5.1.3 GSS_Release_oid() 5.1.3. GSS_Release_oid()
The following text is adapted from the obsoleted rfc2078 [RFC2078]. The following text is adapted from the obsoleted rfc2078 [RFC2078].
Inputs: Inputs:
o oid OBJECT IDENTIFIER o oid OBJECT IDENTIFIER
Outputs: Outputs:
o major_status INTEGER, o major_status INTEGER,
o minor_status INTEGER o minor_status INTEGER
Return major_status codes: Return major_status codes:
o GSS_S_COMPLETE indicates successful completion o GSS_S_COMPLETE indicates successful completion
o GSS_S_FAILURE indicates that the operation failed o GSS_S_FAILURE indicates that the operation failed
Allows the caller to release the storage associated with an OBJECT Allows the caller to release the storage associated with an OBJECT
IDENTIFIER buffer allocated by another GSS-API call, specifically IDENTIFIER buffer allocated by another GSS-API call, specifically
GSS_Compose_oid() and GSS_Decompose_oid(). This call's specific GSS_Compose_oid() and GSS_Decompose_oid(). This call's specific
behavior depends on the language and programming environment within behavior depends on the language and programming environment within
which a GSS-API implementation operates, and is therefore detailed which a GSS-API implementation operates, and is therefore detailed
within applicable bindings specifications; in particular, this call within applicable bindings specifications; in particular, this call
skipping to change at page 11, line 12 skipping to change at page 11, line 17
Allows the caller to release the storage associated with an OBJECT Allows the caller to release the storage associated with an OBJECT
IDENTIFIER buffer allocated by another GSS-API call, specifically IDENTIFIER buffer allocated by another GSS-API call, specifically
GSS_Compose_oid() and GSS_Decompose_oid(). This call's specific GSS_Compose_oid() and GSS_Decompose_oid(). This call's specific
behavior depends on the language and programming environment within behavior depends on the language and programming environment within
which a GSS-API implementation operates, and is therefore detailed which a GSS-API implementation operates, and is therefore detailed
within applicable bindings specifications; in particular, this call within applicable bindings specifications; in particular, this call
may be superfluous within bindings where memory management is may be superfluous within bindings where memory management is
automatic. automatic.
5.1.4 GSS_Indicate_negotiable_mechs() 5.1.4. GSS_Indicate_negotiable_mechs()
Inputs: Inputs:
o input_cred_handle CREDENTIAL HANDLE, -- credential handle to be o input_cred_handle CREDENTIAL HANDLE, -- credential handle to be
used with GSS_Init_sec_context(); may be GSS_C_NO_CREDENTIAL. used with GSS_Init_sec_context(); may be GSS_C_NO_CREDENTIAL.
o peer_type_known BOOLEAN, -- indicates whether the peer is known o peer_type_known BOOLEAN, -- indicates whether the peer is known to
to support or not supprot the stackable pseudo-mechanism support or not supprot the stackable pseudo-mechanism framework.
framework.
o peer_has_mech_stacking BOOLEAN -- indicates whether the peer o peer_has_mech_stacking BOOLEAN -- indicates whether the peer
supports the stackable pseudo-mechanism framework; ignore if supports the stackable pseudo-mechanism framework; ignore if
peer_type_known is FALSE. peer_type_known is FALSE.
Outputs: Outputs:
o major_status INTEGER, o major_status INTEGER,
o minor_status INTEGER, o minor_status INTEGER,
o offer_mechs SET OF OBJECT IDENTIFIER, -- mechanisms to offer. o offer_mechs SET OF OBJECT IDENTIFIER, -- mechanisms to offer.
Return major_status codes: Return major_status codes:
skipping to change at page 12, line 16 skipping to change at page 12, line 20
composite mechanisms will generally not be advertised explicitly, composite mechanisms will generally not be advertised explicitly,
but will be advertised implicitly, by including their component but will be advertised implicitly, by including their component
stackable pseduo-mechanism OIDs (see below); no composite stackable pseduo-mechanism OIDs (see below); no composite
mechanisms will be advertised explicitly mechanisms will be advertised explicitly
o if the input_cred_handle does not have elements for all of the o if the input_cred_handle does not have elements for all of the
possible composite mechanisms that could be constructed from the possible composite mechanisms that could be constructed from the
its elements' decomposed mechanisms, then all composite mechanisms its elements' decomposed mechanisms, then all composite mechanisms
for which the input_cred_handle does have elements will be for which the input_cred_handle does have elements will be
advertised explicitly in offer_mechs. advertised explicitly in offer_mechs.
5.1.5 GSS_Negotiate_mechs() 5.1.5. GSS_Negotiate_mechs()
Inputs: Inputs:
o input_credential_handle CREDENTIAL HANDLE, -- mechanisms offered o input_credential_handle CREDENTIAL HANDLE, -- mechanisms offered
by the caller. by the caller.
o peer_mechs SET OF OBJECT IDENTIFIER -- mechanisms offered by the o peer_mechs SET OF OBJECT IDENTIFIER -- mechanisms offered by the
caller's peer. caller's peer.
Outputs: Outputs:
o major_status INTEGER, o major_status INTEGER,
o minor_status INTEGER, o minor_status INTEGER,
skipping to change at page 12, line 44 skipping to change at page 12, line 48
expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no
credentials could be acquired for GSS_C_NO_NAME. credentials could be acquired for GSS_C_NO_NAME.
o GSS_S_FAILURE indicates that the request failed for some other o GSS_S_FAILURE indicates that the request failed for some other
reason. reason.
This function matches the mechanisms for which the caller has This function matches the mechanisms for which the caller has
credentials with the mechanisms offered by the caller's peer and credentials with the mechanisms offered by the caller's peer and
returns the set of mechanisms in common to both, accounting for any returns the set of mechanisms in common to both, accounting for any
composite mechanisms offered by the peer implicitly. composite mechanisms offered by the peer implicitly.
5.1.6 C-Bindings 5.1.6. C-Bindings
OM_uint32 gss_compose_oid( OM_uint32 gss_compose_oid(
OM_uint32 *minor_status, OM_uint32 *minor_status,
const gss_OID mech1, const gss_OID mech1,
const gss_OID mech2, const gss_OID mech2,
gss_OID *composite); gss_OID *composite);
OM_uint32 gss_decompose_oid( OM_uint32 gss_decompose_oid(
OM_uint32 *minor_status, OM_uint32 *minor_status,
const gss_OID input_mech, const gss_OID input_mech,
const gss_OID_set mechs, const gss_OID_set mechs,
gss_OID *lead_mech, gss_OID *lead_mech,
gss_OID *trail_mech); gss_OID *trail_mech);
OM_uint32 gss_release_oid( OM_uint32 gss_release_oid(
OM_uint32 *minor_status, OM_uint32 *minor_status,
gss_OID *oid); gss_OID *oid);
skipping to change at page 14, line 6 skipping to change at page 14, line 11
use GSS_Indicate_negotiable_mechs() to construct the set of mechanism use GSS_Indicate_negotiable_mechs() to construct the set of mechanism
OIDs to offer to their peers. GSS_Indicate_negotiable_mechs() OIDs to offer to their peers. GSS_Indicate_negotiable_mechs()
optimizes for bandwidth consumption by using decomposed OIDs instead optimizes for bandwidth consumption by using decomposed OIDs instead
of composed OIDs, where possible. See Section 5.1.4. of composed OIDs, where possible. See Section 5.1.4.
Peers that support the stackable mechanism framework interfaces Peers that support the stackable mechanism framework interfaces
SHOULD use GSS_Negotiate_mechs() to select a mechanism as that SHOULD use GSS_Negotiate_mechs() to select a mechanism as that
routine accounts for composite mechanisms implicit in the mechanism routine accounts for composite mechanisms implicit in the mechanism
offers. offers.
6.1 Negotiation of Composite Mechanisms Through SPNEGO 6.1. Negotiation of Composite Mechanisms Through SPNEGO
SPNEGO applications MUST advertise either the set of mechanism OIDs SPNEGO applications MUST advertise either the set of mechanism OIDs
for which they have suitable credentials or the set of mechanism OIDs for which they have suitable credentials or the set of mechanism OIDs
produced by calling GSS_Indicate_negotiable_mechs() with the produced by calling GSS_Indicate_negotiable_mechs() with the
available credentials and the peer_type_known parameter as FALSE. available credentials and the peer_type_known parameter as FALSE.
7. Requirements for Mechanism Designers 7. Requirements for Mechanism Designers
Stackable pseudo-mechanisms specifications MUST: Stackable pseudo-mechanisms specifications MUST:
o list the set of GSS-API mechanism attributes associated with them o list the set of GSS-API mechanism attributes associated with them
skipping to change at page 14, line 48 skipping to change at page 15, line 8
rules accordingly. rules accordingly.
Similarly, pseudo-mechanism designers MUST specify, and implementors Similarly, pseudo-mechanism designers MUST specify, and implementors
MUST implement, composite mechanism attribute set determination rules MUST implement, composite mechanism attribute set determination rules
appropriate to the subject pseduo-mechanism, as described in section appropriate to the subject pseduo-mechanism, as described in section
4.2. Failure to do so may lead to inappropriate composite mechanisms 4.2. Failure to do so may lead to inappropriate composite mechanisms
being deemed permissible by programmatic application of flawed being deemed permissible by programmatic application of flawed
mechanism composition rules or to by their application with incorrect mechanism composition rules or to by their application with incorrect
mechanism attribute sets. mechanism attribute sets.
10 Normative 10. Normative
[EXTENDED-INQUIRY] [EXTENDED-INQUIRY]
Williams, N., "Extended Generic Security Service Mechanism Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", Inquiry APIs",
draft-ietf-kitten-extended-mech-inquiry-00.txt (work in draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
progress). progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 15, line 25 skipping to change at page 16, line 13
C-bindings", RFC 2744, January 2000. C-bindings", RFC 2744, January 2000.
Author's Address Author's Address
Nicolas Williams Nicolas Williams
Sun Microsystems Sun Microsystems
5300 Riata Trace Ct 5300 Riata Trace Ct
Austin, TX 78727 Austin, TX 78727
US US
EMail: Nicolas.Williams@sun.com Email: Nicolas.Williams@sun.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 36 change blocks. 
79 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/