diff --git a/doc/standardisation/draft-ietf-kitten-extended-mech-inquiry-01.txt b/doc/standardisation/draft-ietf-kitten-extended-mech-inquiry-01.txt new file mode 100644 index 000000000..9aee4d125 --- /dev/null +++ b/doc/standardisation/draft-ietf-kitten-extended-mech-inquiry-01.txt @@ -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: + + [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 | + | | (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] + + diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-01.txt new file mode 100644 index 000000000..f148c6502 --- /dev/null +++ b/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-01.txt @@ -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] + + diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-domain-based-names-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-domain-based-names-01.txt new file mode 100644 index 000000000..50cd5b9d9 --- /dev/null +++ b/doc/standardisation/draft-ietf-kitten-gssapi-domain-based-names-01.txt @@ -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 := + + | '@' '@' + + 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] + + diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-01.txt new file mode 100644 index 000000000..2d1e888c8 --- /dev/null +++ b/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-01.txt @@ -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 + + + + +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: + + + + 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. + + + + + + +Williams Expires April 19, 2006 [Page 4] + +Internet-Draft GSS IANA Instructions October 2005 + + +8. Initial Namespace Registrations + + + + + + +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] + + diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-01.txt new file mode 100644 index 000000000..0327d8709 --- /dev/null +++ b/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-01.txt @@ -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: + + + /* + * + * + * <"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] + + diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-01.txt new file mode 100644 index 000000000..b3b94a1d9 --- /dev/null +++ b/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-01.txt @@ -0,0 +1,1233 @@ + + + +NETWORK WORKING GROUP N. Williams +Internet-Draft Sun +Expires: April 19, 2006 October 16, 2005 + + + Guide to the GSS-APIv3 + draft-ietf-kitten-gssapi-v3-guide-to-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 + + Extensions to the GSS-APIv2 are needed for a number of reasons. This + documents describes the extensions being proposed, the resons, + possible future directions, and portability, IANA and security + considerations. This document does not define any protocol or + interface and is purely informational. + + + + + + + +Williams Expires April 19, 2006 [Page 1] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +Table of Contents + + 1. Conventions used in this document . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. A Pseudo-Mechanism OID for the GSS-API Itself . . . . . . . . 6 + 4. Mechanism Attribute Inquiry Facilities . . . . . . . . . . . . 7 + 5. Security Context Extensibility Extensions . . . . . . . . . . 8 + 6. Credential Extensibility Extensions . . . . . . . . . . . . . 9 + 7. Credential Export/Import . . . . . . . . . . . . . . . . . . . 10 + 8. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 11 + 9. Pseudo-Mechanism Stacking . . . . . . . . . . . . . . . . . . 12 + 10. Naming Extensions . . . . . . . . . . . . . . . . . . . . . . 13 + 11. Additional Name Types . . . . . . . . . . . . . . . . . . . . 14 + 12. GSS_Pseudo_random() . . . . . . . . . . . . . . . . . . . . . 15 + 13. Channel Bindings Specifications . . . . . . . . . . . . . . . 16 + 14. Semantic and Miscallaneous Extensions . . . . . . . . . . . . 17 + 15. Portability Considerations . . . . . . . . . . . . . . . . . . 18 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 17. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 18. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . . . 22 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 2] + +Internet-Draft Guide to the GSS-APIv3 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 Guide to the GSS-APIv3 October 2005 + + +2. Introduction + + [NOTE: the references section is current fairly empty; the various + KITTEN WG work items will be added to this I-D in a subsequent + revision.] + + Since the advent of the GSS-APIv2 it has come to be used in a number + of Internet (and other) protocols and a number of implementations + exist. In that time implementors and protocol designers have come to + understand both, the GSS-API's strengths, and its shortcommings; we + believe now that a number of extensions to the GSS-API are needed. + Here these proposed extensions, forming what we may call the GSS-API + version 3, are described at a high-level.; + + Some of these extensions are intended to facilitate further + extensions, so that further major revisions to the GSS-API may not be + necessary. Others are intended to fill voids in the the GSS-APIv2. + + The extensions being proposed are: + + A pseudo-mechanism OID for the GSS-API itself + + Mechanism attribute inquiry facilities + + Security context extensibility extensions + + Credential extensibility extensions + + Credential export/import + + GSS_Store_cred(), for making delegated credentials available for + acquisition + + Pseudo-mechanism stacking + + Naming extensions, to facilitate authorization by identifiers + other than names + + Additional name types, specifically domain-based naming + + A pseudo-random function interface + + Channel bindings specifications + + Semantic extensions relating to thread- and/or fork-safety + + [Have I missed anything? I have a feeling I have. Re-keying?] + + + + +Williams Expires April 19, 2006 [Page 4] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + + ... + + Additionally, because we foresee future minor extensions, including, + specifically, extensions which may impact the various namespaces + associated with APIs (symbol names, constant values, class names, + etc...) we also propose the establishment of IANA registries for + these namespaces. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 5] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +3. A Pseudo-Mechanism OID for the GSS-API Itself + + A mechanism OID is assigned to identify and refer to the GSS-API + iself. This is necessary to enable the use of extended inquiry + interfaces to inquire about features of a GSS-API implementation + specifically, apart from actual mechanisms. + + But also, this OID is needed for better error handling, so that minor + status codes produced in generic contexts that lack a mechanism OID + can be distinguished from minor status codes for a "default" + mechanism and properly displayed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 6] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +4. Mechanism Attribute Inquiry Facilities + + In the course of designing a pseudo-mechanism stacking facility, as + well as while considering the impact of all of these extensions on + portability, a need for interfaces through which to discover or + inquire by features provided by GSS-API mechanisms was discovered. + + The proposed mechanism attribute inquiry interfaces consist of: + + GSS_Inquire_mech_attrs_for_mech() + + GSS_Indicate_mechs_by_mech_attrs() + + GSS_Display_mech_attr() + + These extensions facilitate portability by allowing GSS-APIv3 + applications to discover the features provided by a given + implementation of the GSS-API or any mechanisms. These extensions + are also useful in facilitating stackable pseudo-mechanisms. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 7] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +5. Security Context Extensibility Extensions + + In order to facilitate future security context options we introduce a + GSS_Create_sec_context() interface that creates a security context + object, for use with extensions and with GSS_Init_sec_context(), + GSS_Accept_sec_context(), and GSS_Inquire_sec_context(). Such + security contexts are in a non-established state until they are + established through the use of GSS_Init_sec_context() or + GSS_Accept_sec_context(). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 8] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +6. Credential Extensibility Extensions + + In order to facilitate future extensions to GSS credentials we + introduce a GSS_Create_credential(), similar to + GSS_Create_sec_context(), interface that creates an "empty" + credential. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 9] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +7. Credential Export/Import + + To allow for passing of credentials between different "session + contexts," between different hosts, or for storage of post-dated + credentials, we introduce a credential export/import facility, much + like the security context export/import facility of the GSS-APIv2. + + Together with credential extensibility and other extensions this + facility may allow for: + + Credential delegation at any time + + Post-dated credentials, and storage of the such for subsequent + use. + + ...? + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 10] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +8. GSS_Store_cred() + + This extension fills a void in the GSS-APIv2 where delegated + credentials could not be used except in the context of the same + process that received them. With this extension acceptor + applications can now make delegated credentials available for use, + with GSS_Acquire_cred() et. al., in other process contexts. + + [Manipulation of "credential stores" is (may be?) out of scope for + this document.] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 11] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +9. Pseudo-Mechanism Stacking + + A number of pseudo-mechanisms are being proposed which are designed + to "stack" atop other mechanisms. The possiblities are many, + including: a compression mechanism, a perfect forward security + mechanism, an many others. + + The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism + (SPNEGO) available. With this proposal the mechanism taxonomy is + quite expanded: + + Concrete mechanisms (e.g., the Kerberos V mechanism) + + Composite mechanisms (a concrete mechanism composed with one or + more stackable pseudo-mechanisms) + + Stackable pseudo-mechanisms + + Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself) + + Although composed mechanisms may be made available for use by GSS- + APIv2 applications without any further extensions, use of stackable + pseudo-mechanisms can complicate mechanism negotiation; additionally, + discovery of mechanisms appropriate for use in one or another context + would require hard-coding information about them in GSS-APIv2 + applications. Extensions to the GSS-APIv2 could facilitate use of + composite. + + The mechanism attribute inquiry facilities, together with the + forllowing additional interfaces, provide for a complete interface to + mechanism composition and for managing the complexity of mechanism + negotiation: + + GSS_Compose_oid() + + GSS_Decompose_oid() + + GSS_Release_oid() + + GSS_Indicate_negotiable_mechs() + + GSS_Negotiate_mechs() + + + + + + + + + +Williams Expires April 19, 2006 [Page 12] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +10. Naming Extensions + + Some applications make use of exported names, as produced by + GSS_Export_name(), to create/manage/evaluate access control lists; we + call this name-based authorization. + + Exported names typically encode names that are meant for display to + humans, not internal identifiers. + + In practice this creates a number of problems. E.g., the referential + integrity of such access control lists is hard to maintain as + principals are added, removed, renamed or old principal names reused. + + Additionally, some mechanisms may lack a notion of a "canonical" name + for some or all of their principals. Such mechanisms cannot be used + by applications that rely on name-based authorization. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 13] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +11. Additional Name Types + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 14] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +12. GSS_Pseudo_random() + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 15] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +13. Channel Bindings Specifications + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 16] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +14. Semantic and Miscallaneous Extensions + + The GSS-APIv2 specifications say nothing about the thread-safety, + much less the fork-safety, of the GSS-API. Thread-safety and fork- + safety are, after all, platform- and/or language-specific matters. + But as support for multi-threading spreads the matter of thread- + safety cannot be avoided. The matter of fork-safety is specific to + platforms that provide a "fork()" function, or similar. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 17] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +15. Portability Considerations + + The potential for additional generic, mechanism-specific, language + binding-specific and, most importantly, semantic extensions to the + GSS-APIv3 may create application portability problems. The mechanism + attribute inquiry facilities of the GSS-APIv3 and the pseudo- + mechanism OID for the GSS-API itself double as a run-time facility + for discovery of feature availability. Run-time feature discovery + facilities, in turn, can be used at application build-time as well by + building small applications to display the available features. + + <...> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 18] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +16. IANA Considerations + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 19, 2006 [Page 19] + +Internet-Draft Guide to the GSS-APIv3 October 2005 + + +17. Security Considerations + + <...> + +18. 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 20] + +Internet-Draft Guide to the GSS-APIv3 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 21] + +Internet-Draft Guide to the GSS-APIv3 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 22] + + diff --git a/doc/standardisation/draft-ietf-kitten-stackable-pseudo-mechs-01.txt b/doc/standardisation/draft-ietf-kitten-stackable-pseudo-mechs-01.txt new file mode 100644 index 000000000..c3c49e6d6 --- /dev/null +++ b/doc/standardisation/draft-ietf-kitten-stackable-pseudo-mechs-01.txt @@ -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: + + [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] + +