oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

x

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@16198 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Love Hörnquist Åstrand
2005-10-20 13:38:32 +00:00
parent 92c8cf86bc
commit ffd449e518
7 changed files with 5495 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

785
doc/standardisation/draft-ietf-kitten-extended-mech-inquiry-01.txt Normal file
View File

@@ -0,0 +1,785 @@
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: April 19, 2006 October 16, 2005
Extended Generic Security Service Mechanism Inquiry APIs
draft-ietf-kitten-extended-mech-inquiry-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
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
for use in mechanism composition, but also 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
Williams Expires April 19, 2006 [Page 1]
Internet-Draft Extended GSS Mech Inquiry October 2005
for displaying mechanism attributes.
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
3. New GSS-API Interfaces . . . . . . . . . . . . . . . . . . 3
3.1. Mechanism Attributes and Attribute Sets . . . . . . . . . 3
3.2. Determination of Attribute Sets of Composite Mechs . . . . 4
3.3. List of Known Mechanism Attributes . . . . . . . . . . . . 4
3.4. Mechanism Attribute Sets of Existing Mechs . . . . . . . . 6
3.5. New GSS-API Function Interfaces . . . . . . . . . . . . . 8
3.5.1. GSS_Indicate_mechs_by_attr() . . . . . . . . . . . . . . . 8
3.5.2. GSS_Inquire_attrs_for_mech() . . . . . . . . . . . . . . . 9
3.5.3. GSS_Display_mech_attr() . . . . . . . . . . . . . . . . . 10
3.5.4. New Major Status Values . . . . . . . . . . . . . . . . . 10
3.5.5. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Requirements for Mechanism Designers . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . 11
6. Security considerations . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Normative . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . 14
Williams Expires April 19, 2006 [Page 2]
Internet-Draft Extended GSS Mech Inquiry October 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
3. New GSS-API Interfaces
GSS-API applications face, today, the problem of how to select from
multiple GSS-API mechanisms that may be available. For example,
applications that support mechanism negotiation directly often have
to be careful not to use SPNEGO to avoid two-layer mechanism
negotiation, but since SPNEGO may be indicated by
GSS_Indicate_mechs() and since there's no way to know that a
mechanism negotiates mechanisms other than to hardcode the OIDs of
such mechanisms, such applications must hardcode the SPNEGO OID.
This problem is likely to be exacerbated by the introduction of
composite mechanisms.
To address this problem we introduce a new concept: that of mechanism
attributes. By allowing applications to query the set of attributes
associated with individual mechanisms and to find out which
mechanisms support a given set of attributes we allow applications to
select mechanisms based on their attributes yet without having to
hardcode mechanism OIDs.
Section 3.1 describes the mechanism attributes concept. Sections
3.5.1, 3.5.2 and 3.5.3 describe three new interfaces that deal in
mechanisms and attribute sets:
o GSS_Indicate_mechs_by_attrs()
o GSS_Inquire_attrs_for_mech()
o GSS_Display_mech_attr()
3.1. Mechanism Attributes and Attribute Sets
An abstraction for the features provided by pseudo-mechanisms is
needed in order to facilitate the programmatic selection of
mechanisms as well as for the programmatic composition of mechanisms.
Two data types are needed: one for individual mechanism attributes
and one for mechanism attribute sets. To simplify the mechanism
attributes interfaces we reuse the 'OID' and 'OID set' data types and
model individual mechanism attribute types as OIDs.
Williams Expires April 19, 2006 [Page 3]
Internet-Draft Extended GSS Mech Inquiry October 2005
To this end we define an open namespace of mechanism attributes and
assign them arcs off of this OID:
<TBD> [1.3.6.1.5.5.12 appears to be available, registration w/ IANA
TBD]
3.2. Determination of Attribute Sets of Composite Mechs
Each mechanism, composite or otherwise, has a set of mechanism
attributes that it supports as specified.
The mechanism attribute set of a composite mechanism is to be
determined by the top-most stackable pseudo-mechanism of the
composite according to its own attribute set and that of the
remainder of the composite mechanism stack below it.
It may well be that some composite mechanisms' attribute sets consist
of the union of those of their every component, however this need not
be the case and MUST NOT be assumed.
Every stackable pseudo-mechanism's specification MUST specify the
rules for determining the mechanism attribute set of mechanisms
composed by it.
3.3. List of Known Mechanism Attributes
+-------------------------+--------+--------------------------------+
| Mech Attr Name | OID | Arc Name |
| | Arc | |
+-------------------------+--------+--------------------------------+
| GSS_C_MA_MECH_CONCRETE | (1) | concrete-mech |
| GSS_C_MA_MECH_STACKABLE | (2) | pseudo-mech |
| GSS_C_MA_MECH_COMPOSITE | (3) | composite-mech |
| GSS_C_MA_MECH_NEGO | (4) | mech-negotiation-mech |
| GSS_C_MA_MECH_GLUE | (5) | mech-glue |
| GSS_C_MA_NOT_MECH | (6) | not-mech |
| GSS_C_MA_DEPRECATED | (7) | mech-deprecated |
| GSS_C_MA_NOT_DFLT_MECH | (8) | mech-not-default |
| GSS_C_MA_ITOK_FRAMED | (9) | initial-is-framed |
| GSS_C_MA_AUTH_INIT | (10) | auth-init-princ |
| GSS_C_MA_AUTH_TARG | (11) | auth-targ-princ |
| GSS_C_MA_AUTH_INIT_INIT | (12) | auth-init-princ-initial |
| GSS_C_MA_AUTH_TARG_INIT | (13) | auth-targ-princ-initial |
| GSS_C_MA_AUTH_INIT_ANON | (14) | auth-init-princ-anon |
| GSS_C_MA_AUTH_TARG_ANON | (15) | auth-targ-princ-anon |
| GSS_C_MA_DELEG_CRED | (16) | deleg-cred |
| GSS_C_MA_INTEG_PROT | (17) | integ-prot |
| GSS_C_MA_CONF_PROT | (18) | conf-prot |
Williams Expires April 19, 2006 [Page 4]
Internet-Draft Extended GSS Mech Inquiry October 2005
| GSS_C_MA_MIC | (19) | mic |
| GSS_C_MA_WRAP | (20) | wap |
| GSS_C_MA_PROT_READY | (21) | prot-ready |
| GSS_C_MA_REPLAY_DET | (22) | replay-detection |
| GSS_C_MA_OOS_DET | (23) | oos-detection |
| GSS_C_MA_CBINDINGS | (24) | channel-bindings |
| GSS_C_MA_CBINDINGS_BIDI | (25) | channel-bindings-bidirectional |
| GSS_C_MA_CBINDINGS_NEGO | (26) | channel-bindings-negotiate |
| GSS_C_MA_PFS | (27) | pfs |
| GSS_C_MA_COMPRESS | (28) | compress |
| GSS_C_MA_CTX_TRANS | (29) | context-transfer |
| <reserved> | (30..) | |
+-------------------------+--------+--------------------------------+
Table 1
+-------------------------+-----------------------------------------+
| Mech Attr Name | Purpose |
+-------------------------+-----------------------------------------+
| GSS_C_MA_MECH_CONCRETE | Indicates that a mech is neither a |
| | pseudo- mechanism nor a composite |
| | mechanism. |
| GSS_C_MA_MECH_STACKABLE | Indicates that a mech is a |
| | pseudo-mechanism. |
| GSS_C_MA_MECH_COMPOSITE | Indicates that a mech is a composite |
| | mechanism. |
| GSS_C_MA_MECH_NEGO | Indicates that a mech negotiates other |
| | mechs (e.g., SPNEGO has this |
| | attribute). |
| GSS_C_MA_MECH_GLUE | Indicates that the OID is not for a |
| | mechanism but for the GSS-API itself. |
| GSS_C_MA_NOT_MECH | Indicates that the OID is known, yet |
| | also known not to be the OID of any |
| | GSS-API mechanism (or the GSS-API |
| | itself). |
| GSS_C_MA_DEPRECATED | Indicates that a mech (or its OID) is |
| | deprecated and MUST NOT be used as a |
| | default mechanism. |
| GSS_C_MA_NOT_DFLT_MECH | Indicates that a mech (or its OID) MUST |
| | NOT be used as a default mechanism. |
| GSS_C_MA_ITOK_FRAMED | Indicates that the given mechanism's |
| | initial context tokens are properly |
| | framed as per-section 3.1 of rfc2743. |
| GSS_C_MA_AUTH_INIT | Indicates support for authentication of |
| | initiator to acceptor. |
| GSS_C_MA_AUTH_TARG | Indicates support for authentication of |
| | acceptor to initiator. |
| GSS_C_MA_AUTH_INIT_INIT | Indicates support for initial |
Williams Expires April 19, 2006 [Page 5]
Internet-Draft Extended GSS Mech Inquiry October 2005
| | authentication of initiator to |
| | acceptor. |
| GSS_C_MA_AUTH_TARG_INIT | Indicates support for initial |
| | authentication of acceptor to |
| | initiator. |
| GSS_C_MA_AUTH_INIT_ANON | Indicates support for initiator |
| | anonymity. |
| GSS_C_MA_AUTH_TARG_ANON | Indicates support for acceptor |
| | anonymity. |
| GSS_C_MA_DELEG_CRED | Indicates support for credential |
| | delegation. |
| GSS_C_MA_INTEG_PROT | Indicates support for per-message |
| | integrity protection. |
| GSS_C_MA_CONF_PROT | Indicates support for per-message |
| | confidentiality protection. |
| GSS_C_MA_MIC | Indicates support for MIC tokens. |
| GSS_C_MA_WRAP | Indicates support for WRAP tokens. |
| GSS_C_MA_PROT_READY | Indicates support for per-message |
| | protection prior to full context |
| | establishment. |
| GSS_C_MA_REPLAY_DET | Indicates support for replay detection. |
| GSS_C_MA_OOS_DET | Indicates support for out-of-sequence |
| | detection. |
| GSS_C_MA_CBINDINGS | Indicates support for channel bindings. |
| GSS_C_MA_CBINDINGS_BIDI | Indicates that acceptors |
| | unconditionally indicate to initiators |
| | whether their channel bindings were |
| | matched the acceptors', even when the |
| | acceptor applications use |
| | GSS_C_NO_CHANNEL_BINDINGS.. |
| GSS_C_MA_CBINDINGS_NEGO | Indicates that the mech acts as a |
| | signal for application support for and |
| | willingness to use channel bindings. |
| GSS_C_MA_PFS | Indicates support for Perfect Forward |
| | Security. |
| GSS_C_MA_COMPRESS | Indicates support for compression of |
| | data inputs to GSS_Wrap(). |
| GSS_C_MA_CTX_TRANS | Indicates support for security context |
| | export/import. |
+-------------------------+-----------------------------------------+
Table 2
3.4. Mechanism Attribute Sets of Existing Mechs
The Kerberos V mechanism [RFC1964] [CFX] provides the following
mechanism attributes:
Williams Expires April 19, 2006 [Page 6]
Internet-Draft Extended GSS Mech Inquiry October 2005
o GSS_C_MA_MECH_CONCRETE
o GSS_C_MA_ITOK_FRAMED
o GSS_C_MA_AUTH_INIT
o GSS_C_MA_AUTH_TARG
o GSS_C_MA_DELEG_CRED
o GSS_C_MA_INTEG_PROT
o GSS_C_MA_CONF_PROT
o GSS_C_MA_MIC
o GSS_C_MA_WRAP
o GSS_C_MA_PROT_READY
o GSS_C_MA_REPLAY_DET
o GSS_C_MA_OOS_DET
o GSS_C_MA_CBINDINGS
o GSS_C_MA_CTX_TRANS (some implementations, using implementation-
specific exported context token formats)
The Kerberos V mechanism also has a deprecated OID which has the same
mechanism attributes as above, and GSS_C_MA_DEPRECATED.
[The mechanism attributes of the SPKM family of mechanisms will be
provided in a separate document as SPKM is current being reviewed for
possibly significant changes due to problems in its specifications.]
The LIPKEY mechanism offers the following attributes:
o GSS_C_MA_MECH_CONCRETE (should be stackable, but does not compose)
o GSS_C_MA_ITOK_FRAMED
o GSS_C_MA_AUTH_INIT_INIT
o GSS_C_MA_AUTH_TARG (from SPKM-3)
o GSS_C_MA_AUTH_TARG_ANON (from SPKM-3)
o GSS_C_MA_INTEG_PROT
o GSS_C_MA_CONF_PROT
o GSS_C_MA_REPLAY_DET
o GSS_C_MA_OOS_DET
o GSS_C_MA_CTX_TRANS (some implementations, using implementation-
specific exported context token formats)
(LIPKEY should also provide GSS_C_MA_CBINDINGS, but SPKM-3
requires clarifications on this point.)
The SPNEGO mechanism [SPNEGO] provides the following attributes:
o GSS_C_MA_MECH_NEGO
o GSS_C_MA_ITOK_FRAMED
The attributes of mechanisms negotiated by SPNEGO are not modified by
the use of SPNEGO.
All other mechanisms' attributes will be described elsewhere.
Williams Expires April 19, 2006 [Page 7]
Internet-Draft Extended GSS Mech Inquiry October 2005
3.5. New GSS-API Function Interfaces
Several new interfaces are given by which, for example, GSS-API
applications may determine what features are provided by a given
mechanism, what mechanisms provide what features and what
compositions are legal.
These new interfaces are all OPTIONAL.
In order to preserve backwards compatibility with applications that
do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate
support for any stackable pseduo-mechanisms. GSS_Indicate_mechs()
MAY indicate support for some, all or none of the available composite
mechanisms; which composite mechanisms, if any, are indicated through
GSS_Indicate_mechs() SHOULD be configurable. GSS_Acquire_cred() and
GSS_Add_cred() MUST NOT create credentials for composite mechanisms
not explicitly requested or, if no desired mechanism or mechanisms
are given, for composite mechanisms not indicated by
GSS_Indicate_mechs().
Applications SHOULD use GSS_Indicate_mechs_by_attr() instead of
GSS_Indicate_mechs() wherever possible.
Applications can use GSS_Indicate_mechs_by_attr() to determine what,
if any, mechanisms provide a given set of features.
GSS_Indicate_mechs_by_attr() can also be used to indicate (as in
GSS_Indicate_mechs()) the set of available mechanisms of each type
(concrete, mechanism negotiation pseudo-mechanism, stackable pseudo-
mechanism and composite mechanisms).
Applications may use GSS_Inquire_attrs_for_mech() to test whether a
given composite mechanism is available and the set of features that
it offers.
3.5.1. GSS_Indicate_mechs_by_attr()
Inputs:
o desired_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
OIDs that the mechanisms indicated in the mechs output parameter
MUST offer.
o except_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
OIDs that the mechanisms indicated in the mechs output parameter
MUST NOT offer.
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
Williams Expires April 19, 2006 [Page 8]
Internet-Draft Extended GSS Mech Inquiry October 2005
o mechs SET OF OBJECT IDENTIFIER -- set of mechanisms that support
-- the desired_mech_attrs but not the except_mech_attrs.
Return major_status codes:
o GSS_S_COMPLETE indicates success; the output mechs parameter MAY
be the empty set (GSS_C_NO_OID_SET).
o GSS_BAD_MECH_ATTR indicates that at least one mechanism attribute
OID in desired_mech_attrs or except_mech_attrs is unknown to the
implementation.
o GSS_S_FAILURE indicates that the request failed for some other
reason.
GSS_Indicate_mechs_by_mech_attrs() returns the set of mechanism OIDs
that offer at least the desired_mech_attrs but none of the
except_mech_attrs.
When desired_mech_attrs and except_mech_attrs are the empty set this
function acts as a version of GSS_indicate_mechs() that outputs the
set of all supported mechanisms of all types. By setting the
desired_mechs input parameter to a set of a single GSS_C_MA_MECH*
feature applications can obtain the list of all supported mechanisms
of a given type (concrete, stackable, etc...).
3.5.2. GSS_Inquire_attrs_for_mech()
Inputs:
o mech OBJECT IDENTIFIER -- mechanism OID
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o mech_attrs SET OF OBJECT IDENTIFIER -- set of mech_attrs OIDs
(GSS_C_MA_*)
Return major_status codes:
o GSS_S_COMPLETE indicates success; the output mech_attrs parameter
MAY be the empty set (GSS_C_NO_OID_SET).
o GSS_S_BAD_MECH indicates that the mechanism named by the mech
parameter does not exist or that mech is GSS_C_NO_OID and no
default mechanism could be determined.
o GSS_S_FAILURE indicates that the request failed for some other
reason.
GSS_Inquire_mech_attrs_for_mech() indicates the set of mechanism
attributes supported by a given mechanism.
Because the mechanism attribute sets of composite mechanisms need not
be the union of their components', when called to obtain the feature
Williams Expires April 19, 2006 [Page 9]
Internet-Draft Extended GSS Mech Inquiry October 2005
set of a composite mechanism GSS_Inquire_mech_attrs_for_mech()
obtains it by querying the mechanism at the top of the stack. See
Section 3.1.
3.5.3. GSS_Display_mech_attr()
Inputs:
o mech_attr OBJECT IDENTIFIER -- mechanism attribute OID
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o name OCTET STRING, -- name of mechanism attribute (e.g.,
GSS_C_MA_*)
o short_desc OCTET STRING, -- a short description of the mechanism
attribute
o long_desc OCTET STRING -- a longer description of the mechanism
attribute
Return major_status codes:
o GSS_S_COMPLETE indicates success.
o GSS_S_BAD_MECH_ATTR indicates that the mechanism attribute
referenced by the mech_attr parameter is unknown to the
implementation.
o GSS_S_FAILURE indicates that the request failed for some other
reason.
This function can be used to obtain human-readable descriptions of
GSS-API mechanism attributes.
3.5.4. New Major Status Values
A single new major status code is added for GSS_Display_mech_attr():
o GSS_S_BAD_MECH_ATTR
roughly corresponding to GSS_S_BAD_MECH, but applicable to mechanism
attribute OIDs, rather than to mechanism OIDs.
For the C-bindings GSS_S_BAD_MECH_ATTR shall have a routine error
number of 19 (this is shifted to the left by
GSS_C_ROUTINE_ERROR_OFFSET).
3.5.5. C-Bindings
#define GSS_S_BAD_MECH_ATTR (19ul << GSS_C_ROUTINE_ERROR_OFFSET)
OM_uint32 gss_inquire_mechs_for_mech_attrs(
OM_uint32 *minor_status,
Williams Expires April 19, 2006 [Page 10]
Internet-Draft Extended GSS Mech Inquiry October 2005
const gss_OID_set desired_mech_attrs,
gss_OID_set *mechs);
OM_uint32 gss_inquire_mech_attrs_for_mech(
OM_uint32 *minor_status,
const gss_OID mech,
gss_OID_set *mech_attrs);
OM_uint32 gss_display_mech_attr(
OM_uint32 *minor_status,
const gss_OID mech_attr,
gss_buffer_t name,
gss_buffer_t short_desc,
gss_buffer_t long_desc);
Figure 1
4. Requirements for Mechanism Designers
Stackable pseudo-mechanisms specifications MUST:
o list the set of GSS-API mechanism attributes associated with them
o list their initial mechanism composition rules
o specify a mechanism for updating their mechanism composition rules
All other mechanism specifications MUST:
o list the set of GSS-API mechanism attributes associated with them
5. IANA Considerations
The namsepace of programming language symbols with names beginning
with GSS_C_MA_* is reserved for allocation by the IANA.
Allocation of arcs in the namespace of OIDs relative to the base
mechanism attribute OID specified in Section 3.1 is reserved to the
IANA.
6. Security considerations
...
7. References
7.1. Normative
Williams Expires April 19, 2006 [Page 11]
Internet-Draft Extended GSS Mech Inquiry October 2005
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
7.2. Normative
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
Williams Expires April 19, 2006 [Page 12]
Internet-Draft Extended GSS Mech Inquiry October 2005
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Williams Expires April 19, 2006 [Page 13]
Internet-Draft Extended GSS Mech Inquiry October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires April 19, 2006 [Page 14]

897
doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-01.txt Normal file
View File

@@ -0,0 +1,897 @@
KITTEN WG N. Williams
Internet-Draft Sun
Expires: April 19, 2006 October 16, 2005
Clarifications and Extensions to the GSS-API for the Use of Channel
Bindings
draft-ietf-kitten-gssapi-channel-bindings-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document clarifies and generalizes the GSS-API "channel
bindings" facility. This document also specifies the format of the
various types of channel bindings.
Williams Expires April 19, 2006 [Page 1]
Internet-Draft GSS-API Channel Bindings October 2005
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Generic Structure for GSS-API Channel Bindings . . . . . . . . 5
3.1. Proper Mechanism Use of Channel Bindings . . . . . . . . . 5
4. Channel Bindings for SSHv2 . . . . . . . . . . . . . . . . . . 6
4.1. GSS_Make_sshv2_channel_bindings() . . . . . . . . . . . . 6
4.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . 7
5. Channel Bindings for TLS . . . . . . . . . . . . . . . . . . . 8
5.1. GSS_Make_tls_channel_bindings() . . . . . . . . . . . . . 8
5.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . 9
6. Channel Bindings for IPsec . . . . . . . . . . . . . . . . . . 10
6.1. GSS_Make_ipsec_channel_bindings() . . . . . . . . . . . . 10
6.1.1. C-Bindings . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Williams Expires April 19, 2006 [Page 2]
Internet-Draft GSS-API Channel Bindings October 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].
Williams Expires April 19, 2006 [Page 3]
Internet-Draft GSS-API Channel Bindings October 2005
2. Introduction
The concept of "channel bindings" and the abstract construction of
channel bindings for several types of channels are described in
[CHANNEL-BINDINGS]
To actually use channel bindings in GSS-API aplications additional
details are required that are given below.
First the structure given to channel bindings data in [RFC2744] is
generalized to all of the GSS-API, not just its C-Bindings.
Then the actual construction of channel bindings to SSHv2, TLS and
IPsec channels is given.
Williams Expires April 19, 2006 [Page 4]
Internet-Draft GSS-API Channel Bindings October 2005
3. Generic Structure for GSS-API Channel Bindings
The base GSS-API v2, update 1 specification [RFC2743]describes
channel bindings as an OCTET STRING and leaves it to the GSS-API v2,
update 1 C-Bindings specification to specify the structure of the
contents of the channel bindings OCTET STRINGs. The C-Bindings
specification [RFC2744]then defines, in terms of C, what should be
generic structure for channel bindings. The Kerberos V GSS mechanism
[RFC1964]then defines a method for encoding GSS channel bindings in a
way that is independent of the C-Bindings!
In other words, the structure of GSS channel bindings given in
[RFC2744] is actually generic, rather than specific to the C
programming language.
Here, then, is a generic re-statement of this structure, in pseudo-
ASN.1:
GSS-CHANNEL-BINDINGS := SEQUENCE {
initiator-address-type INTEGER,
initiator-address OCTET STRING,
acceptor-address-type INTEGER,
acceptor-address OCTET STRING,
application-data OCTET STRING,
}
The values for the address fields are described in [RFC2744].
Language-specific bindings of the GSS-API should specify a language-
specific formulation of this structure.
3.1. Proper Mechanism Use of Channel Bindings
As described in [CHANNEL-BINDINGS], GSS mechanisms should exchange
integrity protected proofs of channel bindings, where the proof is
obtained by running a strong hash of the channel bindings data
(encoded as per some mechanism-specific, such as in [RFC1964]) and a
binary value to represent the initiator->acceptor, and opposite,
direction.
The encoding of channel bindings used in [RFC1964], with the addition
of a binary value as described above, and the substitution of SHA-1
for MD5 is a reasonable, generic encoding of GSS-CHANNEL-BINDINGS
that any future GSS mechanisms can use.
Williams Expires April 19, 2006 [Page 5]
Internet-Draft GSS-API Channel Bindings October 2005
4. Channel Bindings for SSHv2
The SSHv2 channel bindings are constructed as an octet string for the
'application-data' field of the channel bindings by concatenating the
following values and in this order:
1. The ASCII string "GSS SSHv2 CB:"
2. The SSHv2 session ID
3. Any additional application-provided data, encoded as the DER
encoding of an ASN.1 OCTET STRING
4.1. GSS_Make_sshv2_channel_bindings()
Inputs:
o session_id OCTET STRING,
o additional_app_data OCTET STRING
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o channel_bindings_app_data OCTET STRING
Return major_status codes:
o GSS_S_COMPLETE indicates no error.
o GSS_S_FAILURE indicates failure to construct the channel bindings
as a result, perhaps, of a memory management, or similar failure.
This function constructs an OCTET STRING for use as the value of the
application-data field of the GSS-CHANNEL-BINDINGS structure
described above.
Williams Expires April 19, 2006 [Page 6]
Internet-Draft GSS-API Channel Bindings October 2005
4.1.1. C-Bindings
OM_uint32 gss_make_sshv2_channel_bindings(
OM_uint32 *minor_status,
const gss_buffer_t session_id,
const gss_buffer_t additional_app_data,
gss_buffer_t channel_bindings_app_data
);
Williams Expires April 19, 2006 [Page 7]
Internet-Draft GSS-API Channel Bindings October 2005
5. Channel Bindings for TLS
The TLS channel bindings are constructed as an octet string for the
'application-data' field of the channel bindings by concatenating the
following values and in this order:
1. The ASCII string "GSS TLSv1.0 CB:"
2. The TLS finished message sent by the client
3. The TLS finished message sent by the server
4. Any additional application-provided data, encoded as the DER
encoding of an ASN.1 OCTET STRING
5.1. GSS_Make_tls_channel_bindings()
Inputs:
o client_finished_msg OCTET STRING,
o server_finished_msg OCTET STRING,
o additional_app_data OCTET STRING
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o channel_bindings_app_data OCTET STRING
Return major_status codes:
o GSS_S_COMPLETE indicates no error.
o GSS_S_FAILURE indicates failure to construct the channel bindings
as a result, perhaps, of a memory management, or similar failure.
This function constructs an OCTET STRING for use as the value of the
application-data field of the GSS-CHANNEL-BINDINGS structure
described above.
Williams Expires April 19, 2006 [Page 8]
Internet-Draft GSS-API Channel Bindings October 2005
5.1.1. C-Bindings
OM_uint32 gss_make_tls_channel_bindings(
OM_uint32 *minor_status,
const gss_buffer_t client_finished_msg,
const gss_buffer_t server_finished_msg,
const gss_buffer_t additional_app_data,
gss_buffer_t channel_bindings_app_data
);
Williams Expires April 19, 2006 [Page 9]
Internet-Draft GSS-API Channel Bindings October 2005
6. Channel Bindings for IPsec
The IPsec channel bindings are constructed as an octet string for the
'application-data' field of the channel bindings by concatenating the
following values and in this order:
1. The ASCII string "GSS IPsec CB:"
2. The transform ID for encryption, as a 16-bit big-endian word
3. The transform ID for integrity protection, as 16-bit in big-
endian word
4. NOTE: The following needs to be updated to take into account
progress of BTNS.
5. The initiator ID payload as used in the key exchange protocol
used for setting up the channel's SAs
6. The responder ID payload as used in the key exchange protocol
used for setting up the channel's SAs
7. Any additional application-provided data, encoded as the DER
encoding of an ASN.1 OCTET STRING
Note that traffic selectors are not included. Inclusion of
confidentiality/integrity algorithms protects against MITMs that can
compromise weaker algorithms that policy might permit, for the same
peers, for other traffic.
6.1. GSS_Make_ipsec_channel_bindings()
Inputs:
o encr_alg INTEGER,
o integ_alg INTEGER,
o initiator_id OCTET_STRING,
o acceptor_id OCTET_STRING,
o additional_app_data OCTET STRING
Outputs:
Williams Expires April 19, 2006 [Page 10]
Internet-Draft GSS-API Channel Bindings October 2005
o major_status INTEGER,
o minor_status INTEGER,
o channel_bindings_app_data OCTET STRING
Return major_status codes:
o GSS_S_COMPLETE indicates no error.
o GSS_S_FAILURE indicates failure to construct the channel bindings
as a result, perhaps, of a memory management, or similar failure.
This function constructs an OCTET STRING for use as the value of the
application-data field of the GSS-CHANNEL-BINDINGS structure
described above.
6.1.1. C-Bindings
OM_uint32 gss_make_ipsec_channel_bindings(
OM_uint32 *minor_status,
OM_uint32 encr_alg,
OM_uint32 integ_alg,
const gss_buffer_t initiator_id,
const gss_buffer_t acceptor_id,
const gss_buffer_t additional_app_data,
gss_buffer_t channel_bindings_app_data
);
Williams Expires April 19, 2006 [Page 11]
Internet-Draft GSS-API Channel Bindings October 2005
7. Security Considerations
For general security considerations relating to channel bindings see
[CHANNEL-BINDINGS]
Williams Expires April 19, 2006 [Page 12]
Internet-Draft GSS-API Channel Bindings October 2005
8. References
8.1. Normative
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
8.2. Informative
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
[RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues
and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
RFC 2623, June 1999.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003.
Williams Expires April 19, 2006 [Page 13]
Internet-Draft GSS-API Channel Bindings October 2005
Appendix A. Acknowledgments
The author would like to thank Mike Eisler for his work on the
Channel Conjunction Mechanism I-D and for bringing the problem to a
head, Sam Hartman for pointing out that channel bindings provide a
general solution to the channel binding problem, Jeff Altman for his
suggestion of using the TLS finished messages as the TLS channel
bindings, Bill Sommerfeld, for his help in developing channel
bindings for IPsec, and Radia Perlman for her most helpful comments.
Williams Expires April 19, 2006 [Page 14]
Internet-Draft GSS-API Channel Bindings October 2005
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Williams Expires April 19, 2006 [Page 15]
Internet-Draft GSS-API Channel Bindings October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires April 19, 2006 [Page 16]

617
doc/standardisation/draft-ietf-kitten-gssapi-domain-based-names-01.txt Normal file
View File

@@ -0,0 +1,617 @@
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: April 19, 2006 October 16, 2005
GSS-API Domain-Based Service Names and Name Type
draft-ietf-kitten-gssapi-domain-based-names-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes domainname-based service principal names and
the corresponding name type for the Generic Security Service
Application Programming Interface (GSS-API).
Domain-based service names are similar to host-based service names,
but using a domain name (not necessarily and Internat domain name)
instead of or in addition to a hostname. The primary purpose of
domain-based service names is to provide a way to name clustered
services after the domain which they service, thereby allowing their
Williams Expires April 19, 2006 [Page 1]
Internet-Draft GSS Domain Based Names October 2005
clients to authorize the service's servers based on authentication of
their names.
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Name Type OID and Symbolic Name . . . . . . . . . . . . . . 5
4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . 11
Williams Expires April 19, 2006 [Page 2]
Internet-Draft GSS Domain Based Names October 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].
Williams Expires April 19, 2006 [Page 3]
Internet-Draft GSS Domain Based Names October 2005
2. Introduction
The use of hostbased principal names for domain-wide services
presents the problem of how to distinguish between an instance of a
hostbased service that is authorized to respond for a domain and one
that isn't.
Consider LDAP. LDAP [RFC3377] with SASL [RFC2222] and the Kerberos V
mechanism [RFC1964] for the GSS-API [RFC2743] uses a hostbased
principal with a service name of "ldap", a reasonable approach,
provided there is only one logical LDAP directory in a Kerberos
realm's domain, and that all ldap servers in that realm serve that
one LDAP directory. If there were other LDAP directories, then
clients could not tell which service is authorized to serve which
directory, not without assuming a secure method for finding LDAP
servers (e.g., DNSSEC). This is a significant, and oft-unstated
restriction on users of LDAP.
Domain based names can eliminate this problem by allowing LDAP
service names to indicate which LDAP directory they are authorized to
serve.
A domain-based name consists of three required elements:
o a service name
o a domain name
o a hostname
Williams Expires April 19, 2006 [Page 4]
Internet-Draft GSS Domain Based Names October 2005
3. Name Type OID and Symbolic Name
The new name type has an OID of
[NOTE: OID assignment to be made with IANA.]
{iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-
domain-based(5)}
The recommended symbolic name for this GSS-API name type is
"GSS_C_NT_DOMAINBASED_SERVICE".
Williams Expires April 19, 2006 [Page 5]
Internet-Draft GSS Domain Based Names October 2005
4. Query and Display Syntaxes
There is a single name syntax for domain-based names.
The syntax is:
domain-based-name :=
| <service> '@' <domain> '@' <hostname>
Note that for Internet domain names the trailing '.' is not and MUST
NOT be included in the domain name (or hostname) parts of the display
form GSS-API domain-based MNs.
Williams Expires April 19, 2006 [Page 6]
Internet-Draft GSS Domain Based Names October 2005
5. Examples
o ldap@example.tld@ds1.example.tld
o kadmin@example.tld@kdc1.example.tld
Williams Expires April 19, 2006 [Page 7]
Internet-Draft GSS Domain Based Names October 2005
6. Security Considerations
Use of GSS-API domain-based names may not be negotiable by some GSS-
API mechanisms, and some acceptors may not support GSS-API domain-
based names. In such cases initiators are left to fallback on the
use of hostbased names, in which case the initiators MUST also verify
that the acceptor's hostbased name is authorized to provide the given
service for the domain that the initiator had wanted.
The above security consideration also applies to all GSS-API
initiators who lack support for domain-based service names.
Williams Expires April 19, 2006 [Page 8]
Internet-Draft GSS Domain Based Names October 2005
7. References
7.1. Normative
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
7.2. Informative
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
Williams Expires April 19, 2006 [Page 9]
Internet-Draft GSS Domain Based Names October 2005
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Williams Expires April 19, 2006 [Page 10]
Internet-Draft GSS Domain Based Names October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires April 19, 2006 [Page 11]

393
doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-01.txt Normal file
View File

@@ -0,0 +1,393 @@
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: April 19, 2006 October 16, 2005
Namespace Considerations and Registries for GSS-API Extensions
draft-ietf-kitten-gssapi-extensions-iana-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the ways in which the GSS-API may be extended
and directs the creation of IANA registries for various GSS-API
namespaces.
Williams Expires April 19, 2006 [Page 1]
Internet-Draft GSS IANA Instructions October 2005
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extensions to the GSS-API . . . . . . . . . . . . . . . . . . . 3
4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . . 3
5. Language Binding-Specific GSS-API Namespaces . . . . . . . . . 4
6. Extension-Specific GSS-API Namespaces . . . . . . . . . . . . . 4
7. Registration Form(s) . . . . . . . . . . . . . . . . . . . . . 4
8. Initial Namespace Registrations . . . . . . . . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
10. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 7
Williams Expires April 19, 2006 [Page 2]
Internet-Draft GSS IANA Instructions October 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
There is a need for generic and mechanism-specific extensions to the
Generic Security Services Application Programming Interface (GSS-
API). As such extensions are designed and standardized, both at the
IETF and elsewhere, there is a non-trivial risk of namespace
pollution and conflicts. To avoid this we set out guidelines for
extending the GSS-API and create IANA registries of GSS-API
namespaces.
The registration of name prefixes and constant value ranges is
allowed so as to save the IANA the trouble of registering every GSS-
API name and constant, and to allow for reservation of portions of
some GSS namespaces for private extensions or extensions which lack
IETF Standards-Track extensions.
3. Extensions to the GSS-API
Extensions to the GSS-API can be categorized as follows:
o Generic
o Implementation-specific
o Mechanism-specific
o Language binding-specific
o Any combination of two or all three of the last three
Extensions to the GSS-API may be purely semantic, without effect on
the GSS-API's namespaces. Or they may introduce new functions,
constants, types, etc...; these clearly affect the GSS-API
namespaces.
Extensions that affect the GSS-API namespaces should be registered
with the IANA.
4. Generic GSS-API Namespaces
All the function, constant and type names, as well as all the
constant values specified in the base GSS-API specification for the
basic generic GSS-API namespace.
Williams Expires April 19, 2006 [Page 3]
Internet-Draft GSS IANA Instructions October 2005
The generic GSS-API namespaces are:
o Type names
o Function names
o Constant names for each type
o Constant values for each type
o Mechanism OIDs
o Name Type OIDs
o Mechanism Attribute OIDs (see [EXTENDED-INQUIRY])
5. Language Binding-Specific GSS-API Namespaces
<Add text; discuss header, module, library, class, method namespaces
and whatever else comes up that is language-specific and appropriate
for registration with the IANA.>
6. Extension-Specific GSS-API Namespaces
Extensions to the GSS-API may create additional namespaces.
Instructions to the IANA should included for the handling of such
namespaces.
7. Registration Form(s)
Registrations for GSS-API namespaces SHALL take the following form:
<TBD>
The IANA should create a single GSS-API namespace registry, or
multiple registries, one for symbolic names and one for constant
values, or it may create a registry per-programming language, at its
convenience.
Entries in these registries should consist of all the fields from
their corresponding registration entries.
Entries SHOULD be sorted by object type, proggamming language, symbol
name.
<Add text on guidelines for IANA consideration of registration
applications, particularly with respect to entries lacking normative
references, "magic" entries (e.g., special values of 'time' types
which indicate something other than absolute or relative time, such
as GSS_C_INDEFINITE), expert review requirements (if any) for
registrations lacking normative references, etc....>
Williams Expires April 19, 2006 [Page 4]
Internet-Draft GSS IANA Instructions October 2005
8. Initial Namespace Registrations
<Add registration entries for namespaces (name prefixes) for RFC2743/
RFC2744/RFC2853.>
<Add registration entries for private namespaces (name prefixes) for
implementation- and/or platform-specific extensions.>
9. Security Considerations
This document has no security considerations.
10. Normative
[EXTENDED-INQUIRY]
Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs",
draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
Williams Expires April 19, 2006 [Page 5]
Internet-Draft GSS IANA Instructions October 2005
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Williams Expires April 19, 2006 [Page 6]
Internet-Draft GSS IANA Instructions October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires April 19, 2006 [Page 7]

617
doc/standardisation/draft-ietf-kitten-gssapi-store-cred-01.txt Normal file
View File

@@ -0,0 +1,617 @@
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: April 19, 2006 October 16, 2005
GSS-API Extension for Storing Delegated Credentials
draft-ietf-kitten-gssapi-store-cred-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a new function for the GSS-API which allows
applications to store delegated (and other) credentials in the
implicit GSS-API credential store. This is needed for GSS-API
applications to use delegated credentials as they would use other
credentials.
Williams Expires April 19, 2006 [Page 1]
Internet-Draft GSS_Store_cred() October 2005
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 5
4. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security considerations . . . . . . . . . . . . . . . . . . . 9
7. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
Williams Expires April 19, 2006 [Page 2]
Internet-Draft GSS_Store_cred() October 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].
Williams Expires April 19, 2006 [Page 3]
Internet-Draft GSS_Store_cred() October 2005
2. Introduction
The GSS-API [RFC2743] clearly assumes that credentials exist in an
implicit store whence they can be acquired using GSS_Acquire_cred()
and GSS_Add_cred() or through use of the default credential.
Multiple credential stores may exist on a given host, but only one
store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
given time.
This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of
[RFC2743] as well as in section 3.5 of [RFC2744].
Note to the RFC editor: please remove this note before publication.]
Applications may be able to change the credential store from which
credentials can be acquired, either by changing user contexts (where
the applications have the privilege to do so) or by other means
(where a user may have multiple credential stores).
Some GSS-API acceptor applications always change user contexts, after
accepting a GSS-API security context and making appropriate
authorization checks, to the user context corresponding to the
initiator principal name or to a context requested by the initiator.
The means by which credential stores are managed are generally beyond
the scope of the GSS-API.
In the case of delegated credential handles however, such credentials
do not exist in the acceptor's credential store or in the credential
stores of the user contexts to which the acceptor application might
change - which is precisely the raison d'etre of credential
delegation. But the GSS-API provides no mechanism by which delegated
credential handles can be made available for acquisition through
GSS_Acquire_cred()/GSS_Add_cred(). The GSS-API also does not provide
any credential import/export interfaces like the GSS-API context
import/export interfaces.
Thus acceptors are limited to making only direct use of delegated
credential handles and only with GSS_Init_sec_context(),
GSS_Inquire_cred*() and GSS_Release_cred(). This limitation is
particularly onerous on Unix systems where a call to exec() to
replace the process image obliterates the delegated credentials
handle.
In order to make delegated credentials generally as useful as
credentials that can be acquired with GSS_Acquire_cred() and
GSS_Add_cred() a primitive is needed which allows storing of
credentials in the implicit credential store. This primitive we call
"GSS_Store_cred()."
Williams Expires April 19, 2006 [Page 4]
Internet-Draft GSS_Store_cred() October 2005
3. GSS_Store_cred()
Inputs:
o input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
NOT be GSS_C_NO_CREDENTIAL
o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
2=ACCEPT-ONLY
o desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID then
store all the elements of the input_cred_handle, otherwise store
only the element of the corresponding mechanism
o overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
same principal in the credential store
o default_cred BOOLEAN -- if TRUE make the stored credential
available as the default credential (for acquisition with
GSS_C_NO_NAME as the desired name or for use as
GSS_C_NO_CREDENTIAL)
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
mechanism OIDs for which credential elements were successfully
stored
o cred_usage_stored INTEGER -- like cred_usage, but indicates what
kind of credential was stored (useful when the cred_usage input
parameter is set to INITIATE-AND-ACCEPT)
Return major_status codes:
o GSS_S_COMPLETE indicates that the credentials were successfully
stored.
o GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had
expired or expired before they could be stored.
o GSS_S_NO_CRED indicates that no input credentials were given.
o GSS_S_UNAVAILABLE indicates that the credential store is not
available.
Williams Expires April 19, 2006 [Page 5]
Internet-Draft GSS_Store_cred() October 2005
o GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
credential could not be stored because a credential for the same
principal exists in the current credential store and the
overwrite_cred input argument was FALSE.
o GSS_S_FAILURE indicates that the credential could not be stored
for some other reason. The minor status code may provide more
information if a non-GSS_C_NULL_OID desired_mech_element was
given.
GSS_Store_cred() is used to store, in the current credential store, a
given credential that has either been acquired from a different
credential store or been accepted as a delegated credential.
Specific mechanism elements of a credential can be stored one at a
time by specifying a non-GSS_C_NULL_OID mechanism OID as the
desired_mech_element input argument, in which case the minor status
output SHOULD have a mechanism-specific value when the major status
is not GSS_S_COMPLETE.
The initiator, acceptor or both usages of the input credential may be
stored as per the cred_usage input argument.
The credential elements that were actually stored, when the major
status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
and mech_elements_stored function outputs.
If credentials already exist in the current store for the principal
of the input_cred_handle, then those credentials are not replaced
with the input credentials unless the overwrite_cred input argument
is TRUE.
Finally, if the current credential store has no default credential
(that is, no credential that could be acquired for GSS_C_NO_NAME) or
if the default_cred input argument is TRUE, and the input credential
can be successfully stored, then the input credential will be
available for acquisition with GSS_C_NO_NAME as the desired name
input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
GSS_Accept_sec_context().
Williams Expires April 19, 2006 [Page 6]
Internet-Draft GSS_Store_cred() October 2005
4. C-Bindings
The C-bindings for GSS_Store_cred() make use of types from and are
designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
OM_uint32 gss_store_cred(
OM_uint32 *minor_status,
gss_cred_id_t input_cred,
gss_cred_usage_t cred_usage,
const gss_OID desired_mech,
OM_uint32 overwrite_cred,
OM_uint32 default_cred,
gss_OID_set *elements_stored,
gss_cred_usage_t *cred_usage_stored)
Figure 1
The two boolean arguments, 'overwrite_cred' and 'default_cred' are
typed as OM_uint32; 0 corresponds to FALSE, non-zero values
correspond to TRUE.
Williams Expires April 19, 2006 [Page 7]
Internet-Draft GSS_Store_cred() October 2005
5. Examples
The intended usage of GSS_Store_cred() is to make delegated
credentials available to child processes of GSS-API acceptor
applications. Example pseudo-code:
/*
* <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE,
* an initiator name (hereafter, "src_name") and a delegated
* credential handle (hereafter "deleg_cred").>
*
* <"requested_username" is a username derived from the
* initiator name or explicitly requested by the initiator
* application.>
*/
...
if (authorize_gss_client(src_name, requested_username)) {
/*
* For Unix-type platforms this may mean calling setuid() and
* it may or may not also mean setting/unsetting such
* environment variables as KRB5CCNAME and what not.
*/
if (change_user_context(requested_username))
(void) gss_store_creds(&minor_status, deleg_cred,
GSS_C_INITIATE, actual_mech,
0, 1, NULL, NULL);
}
else ...
}
else ...
Williams Expires April 19, 2006 [Page 8]
Internet-Draft GSS_Store_cred() October 2005
6. Security considerations
Acceptor applications MUST only store delegated credentials into
appropriate credential stores and only after proper authorization of
the authenticated initiator principal to the requested service(s).
Acceptor applications that have no use for delegated credentials MUST
release them (such acceptor applications that use the GSS-API
C-Bindings may simply provide a NULL value for the
delegated_cred_handle argument to gss_accept_sec_context()).
7. Normative
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
Williams Expires April 19, 2006 [Page 9]
Internet-Draft GSS_Store_cred() October 2005
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Williams Expires April 19, 2006 [Page 10]
Internet-Draft GSS_Store_cred() October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires April 19, 2006 [Page 11]

1233
doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-01.txt Normal file
View File

File diff suppressed because it is too large Load Diff

953
doc/standardisation/draft-ietf-kitten-stackable-pseudo-mechs-01.txt Normal file
View File

@@ -0,0 +1,953 @@
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: April 19, 2006 October 16, 2005
Stackable Generic Security Service Pseudo-Mechanisms
draft-ietf-kitten-stackable-pseudo-mechs-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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
Williams Expires April 19, 2006 [Page 1]
Internet-Draft Stackable GSS Mechs October 2005
facilitated by this document.
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 . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . 17
Williams Expires April 19, 2006 [Page 2]
Internet-Draft Stackable GSS Mechs October 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
Williams Expires April 19, 2006 [Page 3]
Internet-Draft Stackable GSS Mechs October 2005
is an example of this.
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
Williams Expires April 19, 2006 [Page 4]
Internet-Draft Stackable GSS Mechs October 2005
issues, as well as basic interfacing and token handling issues.
Section 5 addresses interfacing issues more generally through the
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.
Williams Expires April 19, 2006 [Page 5]
Internet-Draft Stackable GSS Mechs October 2005
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).
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
Williams Expires April 19, 2006 [Page 6]
Internet-Draft Stackable GSS Mechs October 2005
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
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
Williams Expires April 19, 2006 [Page 7]
Internet-Draft Stackable GSS Mechs October 2005
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
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
basic GSS-APIv2, update 1 API functions, except for any OID set
construction/iteration functions. And, if present in any OID SET
input parameters of GSS-APIv2, update 1 functions, they MUST be
ignored.
o The OIDs of *stackable* (not composite) pseudo-mechanisms MAY only
be used as inputs or produced as outputs of functions whose
specification explicitly allows for them or which are concerned
with the creation/iteration of OID containters, such as OID SETs.
4.5. Processing of Tokens for Composite Mechanisms
The initial context token for any standard mechanism, including
mechanisms composited from standard pseudo- and concrete mechanisms,
MUST be encapsulated as described in section 3.1 of rfc2743
[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
the OID of the leading component of the composite mechanism.
Note that this has implications for pluggable multi-mechanism
implementations of the GSS-API, namely that acceptors must route
initial context tokens to the appropriate mechanism and they must
allow that mechanism to determine the composite mechanism OID (such
as by allowing that mechanism's GSS_Accept_sec_context() to output
the actual mechanism to the application.
In all other cases the mechanism that produced or is to produce a
given token can be determined internally through the given security
context.
5. New GSS-API Interfaces
...
Utility functions for mechanism OID composition and decomposition are
given in sections 5.1.1, 5.1.2 and 5.1.3.
Two utility functions, GSS_Indicate_negotiable_mechs() and
GSS_Negotiate_mechs(), to aid applications in mechanism negotiation
Williams Expires April 19, 2006 [Page 8]
Internet-Draft Stackable GSS Mechs October 2005
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
herein.
5.1. New GSS-API Function Interfaces
Several new interfaces are given by which, for example, GSS-API
applications may determine what features are provided by a given
mechanism, what mechanisms provide what features and what
compositions are legal.
These new interfaces are all OPTIONAL.
In order to preserve backwards compatibility with applications that
do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate
support for any stackable pseduo-mechanisms. GSS_Indicate_mechs()
MAY indicate support for some, all or none of the available composite
mechanisms; which composite mechanisms, if any, are indicated through
GSS_Indicate_mechs() SHOULD be configurable. GSS_Acquire_cred() and
GSS_Add_cred() MUST NOT create credentials for composite mechanisms
not explicitly requested or, if no desired mechanism or mechanisms
are given, for composite mechanisms not indicated by
GSS_Indicate_mechs().
Applications SHOULD use GSS_Indicate_mechs_by_mech_attrs() instead of
GSS_Indicate_mechs() wherever possible.
Applications can use GSS_Indicate_mechs_by_mech_attrs() to determine
what, if any, mechanisms provide a given set of features.
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
(concrete, mechanism negotiation pseudo-mechanism, stackable pseudo-
mechanism and composite mechanisms).
Applications may use GSS_Inquire_mech_attrs_for_mech() to test
whether a given composite mechanism is available and the set of
features that it offers.
GSS_Negotiate_mechs() may be used to negotiate the use of mechanisms
such that composite mechanisms need not be advertised but instead be
implied by offering stackable pseudo-mechanisms.
5.1.1. GSS_Compose_oid()
Inputs:
o mech1 OBJECT IDENTIFIER, -- mechanism OID
o mech2 OBJECT IDENTIFIER -- mechanism OID
Williams Expires April 19, 2006 [Page 9]
Internet-Draft Stackable GSS Mechs October 2005
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o composite OBJECT IDENTIFIER -- OID composition of mech1 with mech2
({mech1 mech2})
Return major_status codes:
o GSS_S_COMPLETE indicates success.
o GSS_S_BAD_MECH indicates that mech1 is not supported.
o GSS_S_FAILURE indicates that the request failed for some other
reason. The minor status will be specific to mech1 and may
provide further information.
5.1.2. GSS_Decompose_oid()
Inputs:
o input_mech OBJECT IDENTIFIER, -- mechanism OID.
o mechs SET OF OBJECT IDENTIFIER -- mechanism OIDs (if
GSS_C_NULL_OID_SET defaults to the set of stackable pseudo-
mechanism OIDs indicated by GSS_Indicate_mechs_by_mech_attrs()).
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o lead_mech OBJECT IDENTIFIER, -- leading stackable pseudo-
mechanism OID.
o trail_mech OBJECT IDENTIFIER -- input_mech with lead_mech removed
from the front.
Return major_status codes:
o GSS_S_COMPLETE indicates success.
o GSS_S_BAD_MECH indicates that the input_mech could not be
decomposed as no stackable pseudo-mechanism is available whose OID
is a prefix of the input_mech.
o GSS_S_FAILURE indicates that the request failed for some other
reason.
5.1.3. GSS_Release_oid()
The following text is adapted from the obsoleted rfc2078 [RFC2078].
Inputs:
o oid OBJECT IDENTIFIER
Outputs:
o major_status INTEGER,
o minor_status INTEGER
Williams Expires April 19, 2006 [Page 10]
Internet-Draft Stackable GSS Mechs October 2005
Return major_status codes:
o GSS_S_COMPLETE indicates successful completion
o GSS_S_FAILURE indicates that the operation failed
Allows the caller to release the storage associated with an OBJECT
IDENTIFIER buffer allocated by another GSS-API call, specifically
GSS_Compose_oid() and GSS_Decompose_oid(). This call's specific
behavior depends on the language and programming environment within
which a GSS-API implementation operates, and is therefore detailed
within applicable bindings specifications; in particular, this call
may be superfluous within bindings where memory management is
automatic.
5.1.4. GSS_Indicate_negotiable_mechs()
Inputs:
o input_cred_handle CREDENTIAL HANDLE, -- credential handle to be
used with GSS_Init_sec_context(); may be GSS_C_NO_CREDENTIAL.
o peer_type_known BOOLEAN, -- indicates whether the peer is known to
support or not supprot the stackable pseudo-mechanism framework.
o peer_has_mech_stacking BOOLEAN -- indicates whether the peer
supports the stackable pseudo-mechanism framework; ignore if
peer_type_known is FALSE.
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o offer_mechs SET OF OBJECT IDENTIFIER, -- mechanisms to offer.
Return major_status codes:
o GSS_S_COMPLETE indicates success.
o GSS_S_NO_CREDENTIAL indicates that the caller's credentials are
expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no
credentials could be acquired for GSS_C_NO_NAME.
o GSS_S_FAILURE indicates that the request failed for some other
reason.
This function produces a set of mechanism OIDs, optimized for space,
that its caller should advertise to peers during mechanism
negotiation.
The output offer_mechs parameter will include all of the mechanisms
for which the input_cred_handle has elements (as indicated by
GSS_Inquire_cred()), but composite mechanisms will be included either
implicitly or implicitly as per the following rules:
o if peer_type_known is TRUE and peer_has_mech_stacking is FALSE
then no composite mechanisms not indicated by GSS_Indicate_mechs()
will be advertised, explictly or implicitly;
Williams Expires April 19, 2006 [Page 11]
Internet-Draft Stackable GSS Mechs October 2005
o if peer_type_known is FALSE then all composite mechanisms
indicated by GSS_Indicate_mechs() for which input_cred_handle has
elements will be indicated in offer_mechs explicitly and all
others may be indicated in offer_mechs implicitly, by including
their component stackable pseduo-mechanism OIDs (see below);
o if peer_type_known is TRUE and peer_has_mech_stacking is TRUE
composite mechanisms will generally not be advertised explicitly,
but will be advertised implicitly, by including their component
stackable pseduo-mechanism OIDs (see below); no composite
mechanisms will be advertised explicitly
o if the input_cred_handle does not have elements for all of the
possible composite mechanisms that could be constructed from the
its elements' decomposed mechanisms, then all composite mechanisms
for which the input_cred_handle does have elements will be
advertised explicitly in offer_mechs.
5.1.5. GSS_Negotiate_mechs()
Inputs:
o input_credential_handle CREDENTIAL HANDLE, -- mechanisms offered
by the caller.
o peer_mechs SET OF OBJECT IDENTIFIER -- mechanisms offered by the
caller's peer.
Outputs:
o major_status INTEGER,
o minor_status INTEGER,
o mechs SET OF OBJECT IDENTIFIER -- mechanisms common to the
caller's credentials and the caller's peer.
Return major_status codes:
o GSS_S_COMPLETE indicates success; the output mechs parameter MAY
be the empty set (GSS_C_NO_OID_SET).
o GSS_S_NO_CREDENTIAL indicates that the caller's credentials are
expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no
credentials could be acquired for GSS_C_NO_NAME.
o GSS_S_FAILURE indicates that the request failed for some other
reason.
This function matches the mechanisms for which the caller has
credentials with the mechanisms offered by the caller's peer and
returns the set of mechanisms in common to both, accounting for any
composite mechanisms offered by the peer implicitly.
5.1.6. C-Bindings
OM_uint32 gss_compose_oid(
Williams Expires April 19, 2006 [Page 12]
Internet-Draft Stackable GSS Mechs October 2005
OM_uint32 *minor_status,
const gss_OID mech1,
const gss_OID mech2,
gss_OID *composite);
OM_uint32 gss_decompose_oid(
OM_uint32 *minor_status,
const gss_OID input_mech,
const gss_OID_set mechs,
gss_OID *lead_mech,
gss_OID *trail_mech);
OM_uint32 gss_release_oid(
OM_uint32 *minor_status,
gss_OID *oid);
OM_uint32 gss_indicate_negotiable_mechs(
OM_uint32 *minor_status,
const gss_cred_id_t input_cred_handle,
OM_uint32 peer_type_known,
OM_uint32 peer_has_mech_stacking,
gss_OID_set *offer_mechs);
OM_uint32 gss_negotiate_mechs(
OM_uint32 *minor_status,
const gss_cred_id_t input_cred_handle,
const gss_OID_set peer_mechs,
const gss_OID_set *mechs);
Figure 1
6. Negotiation of Composite Mechanisms
Where GSS-API implementations do not support the stackable mechanism
framework interfaces applications may only negotiate explicitly from
a set of concrete and composite mechanism OIDs as indicated by
GSS_Indicate_mechs() and for which suitable credentials are
available. GSS_Indicate_mechs(), as described in Section 4.4, MUST
NOT indicate support for individual stackable pseudo-mechanisms, so
there will not be any composite mechanisms implied but not explicitly
offered in the mechanism negotiation.
Applications that support the stackable mechanism framework SHOULD
use GSS_Indicate_negotiable_mechs() to construct the set of mechanism
OIDs to offer to their peers. GSS_Indicate_negotiable_mechs()
optimizes for bandwidth consumption by using decomposed OIDs instead
Williams Expires April 19, 2006 [Page 13]
Internet-Draft Stackable GSS Mechs October 2005
of composed OIDs, where possible. See Section 5.1.4.
Peers that support the stackable mechanism framework interfaces
SHOULD use GSS_Negotiate_mechs() to select a mechanism as that
routine accounts for composite mechanisms implicit in the mechanism
offers.
6.1. Negotiation of Composite Mechanisms Through SPNEGO
SPNEGO applications MUST advertise either 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
available credentials and the peer_type_known parameter as FALSE.
7. Requirements for Mechanism Designers
Stackable pseudo-mechanisms specifications MUST:
o list the set of GSS-API mechanism attributes associated with them
o list their initial mechanism composition rules
o specify a mechanism for updating their mechanism composition rules
All other mechanism specifications MUST:
o list the set of GSS-API mechanism attributes associated with them
8. IANA Considerations
Allocation of arcs in the namespace of OIDs relative to the base
stackable pseduo-mechanism OID specified in Section 4.1 is reserved
to the IANA.
9. Security considerations
Some composite mechanisms may well not be secure. The mechanism
composition rules of pseudo-mechanisms (including the default
composition rule given in Section 4 for unknown mechanism attributes)
should be used to prevent the use of unsafe composite mechanisms.
Designers of pseudo-mechanisms should study the possible combinations
of their mechanisms with others and design mechanism composition
rules accordingly.
Similarly, pseudo-mechanism designers MUST specify, and implementors
MUST implement, composite mechanism attribute set determination rules
appropriate to the subject pseduo-mechanism, as described in section
4.2. Failure to do so may lead to inappropriate composite mechanisms
Williams Expires April 19, 2006 [Page 14]
Internet-Draft Stackable GSS Mechs October 2005
being deemed permissible by programmatic application of flawed
mechanism composition rules or to by their application with incorrect
mechanism attribute sets.
10. Normative
[EXTENDED-INQUIRY]
Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs",
draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
Williams Expires April 19, 2006 [Page 15]
Internet-Draft Stackable GSS Mechs October 2005
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Williams Expires April 19, 2006 [Page 16]
Internet-Draft Stackable GSS Mechs October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires April 19, 2006 [Page 17]