draft-ietf-kitten-gssapi-extensions-iana-01.txt   draft-ietf-kitten-gssapi-extensions-iana-02.txt 
NETWORK WORKING GROUP N. Williams NETWORK WORKING GROUP N. Williams
Internet-Draft Sun Internet-Draft Sun
Expires: April 19, 2006 October 16, 2005 Expires: August 28, 2008 February 25, 2008
Namespace Considerations and Registries for GSS-API Extensions Namespace Considerations and Registries for GSS-API Extensions
draft-ietf-kitten-gssapi-extensions-iana-01.txt draft-ietf-kitten-gssapi-extensions-iana-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 19, 2006. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes the ways in which the GSS-API may be extended This document describes the ways in which the GSS-API may be extended
and directs the creation of IANA registries for various GSS-API and directs the creation of IANA registries for various GSS-API
namespaces. namespaces.
Table of Contents Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . . 3 1. Conventions used in this document . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extensions to the GSS-API . . . . . . . . . . . . . . . . . . . 3 3. Extensions to the GSS-API . . . . . . . . . . . . . . . . . . . 3
4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . . 3 4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . . 3
5. Language Binding-Specific GSS-API Namespaces . . . . . . . . . 4 5. Language Binding-Specific GSS-API Namespaces . . . . . . . . . 4
6. Extension-Specific GSS-API Namespaces . . . . . . . . . . . . . 4 6. Extension-Specific GSS-API Namespaces . . . . . . . . . . . . . 4
7. Registration Form(s) . . . . . . . . . . . . . . . . . . . . . 4 7. Registration Form(s) . . . . . . . . . . . . . . . . . . . . . 4
8. Initial Namespace Registrations . . . . . . . . . . . . . . . . 5 8. Initial Namespace Registrations . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
10. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 11. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
There is a need for generic and mechanism-specific extensions to the There is a need for generic and mechanism-specific extensions to the
Generic Security Services Application Programming Interface (GSS- Generic Security Services Application Programming Interface (GSS-
API). As such extensions are designed and standardized, both at the API). As such extensions are designed and standardized, both at the
IETF and elsewhere, there is a non-trivial risk of namespace IETF and elsewhere, there is a non-trivial risk of namespace
pollution and conflicts. To avoid this we set out guidelines for pollution and conflicts. To avoid this we set out guidelines for
extending the GSS-API and create IANA registries of GSS-API extending the GSS-API and create IANA registries of GSS-API
namespaces. namespaces.
The registration of name prefixes and constant value ranges is Registrations of individual items and sub-namespaces are allowed.
allowed so as to save the IANA the trouble of registering every GSS- Each sub-namespace may provide different rules for registration,
API name and constant, and to allow for reservation of portions of e.g., for mechanism-specific and private-use extensions. All
some GSS namespaces for private extensions or extensions which lack Standards-Track uses of the GSS-API namespaces will be registered
IETF Standards-Track extensions. directly with the IANA subsequent to the create of the registries or
when the document is published.
3. Extensions to the GSS-API 3. Extensions to the GSS-API
Extensions to the GSS-API can be categorized as follows: Extensions to the GSS-API can be categorized as follows:
o Generic o Abstract API extensions
o Implementation-specific o Implementation-specific
o Mechanism-specific o Mechanism-specific
o Language binding-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 Extensions to the GSS-API may be purely semantic, without effect on
the GSS-API's namespaces. Or they may introduce new functions, the GSS-API's namespaces. Or they may introduce new functions,
constants, types, etc...; these clearly affect the GSS-API constants, types, etc...; these clearly affect the GSS-API
namespaces. namespaces.
Extensions that affect the GSS-API namespaces should be registered Extensions that affect the GSS-API namespaces should be registered
with the IANA. with the IANA as described herein.
4. Generic GSS-API Namespaces 4. Generic GSS-API Namespaces
All the function, constant and type names, as well as all the The abstract API namespaces for the GSS-API are:
constant values specified in the base GSS-API specification for the
basic generic GSS-API namespace.
The generic GSS-API namespaces are:
o Type names o Type names
o Function names o Function names
o Constant names for each type o Constant names for each type
o Constant values for each type o Constant values for each type
o Name types (OID, type name and syntaxes)
Additionally we have namespaces associates with the OBJECT IDENTIFIER
(OID) type:
o Mechanism OIDs o Mechanism OIDs
o Name Type OIDs o Name Type OIDs
o Mechanism Attribute OIDs (see [EXTENDED-INQUIRY])
5. Language Binding-Specific GSS-API Namespaces 5. Language Binding-Specific GSS-API Namespaces
<Add text; discuss header, module, library, class, method namespaces Language binding specific namespaces include:
and whatever else comes up that is language-specific and appropriate o Header/interface module names
for registration with the IANA.> o Object classes and/or types
o Methods and/or functions
o Constant names
o Constant values
6. Extension-Specific GSS-API Namespaces 6. Extension-Specific GSS-API Namespaces
Extensions to the GSS-API may create additional namespaces. Extensions to the GSS-API may create additional namespaces.
Instructions to the IANA should included for the handling of such Instructions to the IANA should included for the handling of such
namespaces. namespaces.
7. Registration Form(s) 7. Registration Form(s)
Registrations for GSS-API namespaces SHALL take the following form: Registrations for GSS-API namespaces SHALL take the following form:
<TBD> +----------------+----------------------------+---------------------+
| Registration | Possible Values | Description |
| Field | | |
+----------------+----------------------------+---------------------+
| Registration | 'Instance', | Indicates whether |
| type | 'Sub-Namespace' | this entry reserves |
| | | a given symbol name |
| | | or constant value |
| | | or whether it |
| | | reserves an entire |
| | | sub-namespace (the |
| | | name is a "prefix") |
| | | or constant value |
| | | range. |
+----------------+----------------------------+---------------------+
| Bindings | 'Generic', 'C-bindings', | Indicates the |
| | 'Java', 'C#', <programming | language bindings |
| | language name> | that this |
| | | registration is |
| | | for, or, if |
| | | 'Generic', that |
| | | this is an entry |
| | | for the generic |
| | | GSS-API, not |
| | | specific to any |
| | | programming |
| | | language. |
+----------------+----------------------------+---------------------+
| Object Type | 'Data-Type', 'Function', | Indicates the type |
| | 'Method', 'Integer', | of the object(s) |
| | 'String', 'OID', 'Context | whose symbolic name |
| | Flag', 'Name Type' | or constant value |
| | | this entry |
| | | registers. |
+----------------+----------------------------+---------------------+
| Symbol | <Symbol name or name | The name(s) of |
| Name/Prefix | prefix> | symbols or values |
| | | being registered. |
+----------------+----------------------------+---------------------+
| Binding of | <Name of abstract API | If the registration |
| | element of which this | is for a specific |
| | object is a binding> | language binding of |
| | | the GSS-API, then |
| | | this names the |
| | | abstract API |
| | | element of which it |
| | | is a binding |
| | | (OPTIONAL). |
+----------------+----------------------------+---------------------+
| Constant | <Constant value> or | The value(s) |
| Value/Range(s) | <constant value range> | registered |
| | | (OPTIONAL). |
+----------------+----------------------------+---------------------+
| Description | <Text> | Description of |
| | | object(s) being |
| | | registered. |
+----------------+----------------------------+---------------------+
| Registration | 'Protocol Action', 'Expert | Describes the rules |
| Rules | Review', | for allocation of |
| | 'First-Come-First-Served', | items that fall in |
| | 'Closed-For-Registrations' | this sub-namespace, |
| | | if this entry is |
| | | for a sub-namespace |
| | | (OPTIONAL). |
+----------------+----------------------------+---------------------+
| Reference | <Reference> | Reference to |
| | | document that |
| | | describes the |
| | | object(s) being |
| | | registered. |
+----------------+----------------------------+---------------------+
| Expert | <Name of expert reviewers, | |
| Reviewer(s) | possibly WG names> | |
+----------------+----------------------------+---------------------+
| Status | 'Standards-Track', | Status of the |
| | 'Informational', | registration. |
| | 'Experimental', | |
| | 'Obsolete', 'Other' | |
+----------------+----------------------------+---------------------+
The IANA should create a single GSS-API namespace registry, or The IANA should create a single GSS-API namespace registry, or
multiple registries, one for symbolic names and one for constant multiple registries, one for symbolic names and one for constant
values, or it may create a registry per-programming language, at its values, or it may create a registry per-programming language, at its
convenience. convenience.
Entries in these registries should consist of all the fields from Entries in these registries should consist of all the fields from
their corresponding registration entries. their corresponding registration entries.
Entries SHOULD be sorted by object type, proggamming language, symbol Entries should be sorted by object type, progamming language, symbol
name. name.
<Add text on guidelines for IANA consideration of registration <Add text on guidelines for IANA consideration of registration
applications, particularly with respect to entries lacking normative applications, particularly with respect to entries lacking normative
references, "magic" entries (e.g., special values of 'time' types references, "magic" entries (e.g., special values of 'time' types
which indicate something other than absolute or relative time, such which indicate something other than absolute or relative time, such
as GSS_C_INDEFINITE), expert review requirements (if any) for as GSS_C_INDEFINITE), expert review requirements (if any) for
registrations lacking normative references, etc....> registrations lacking normative references, etc....>
8. Initial Namespace Registrations 8. Initial Namespace Registrations
<Add registration entries for namespaces (name prefixes) for RFC2743/ <Add registration entries for namespaces (name prefixes) for RFC2743/
RFC2744/RFC2853.> RFC2744/RFC2853.>
<Add registration entries for private namespaces (name prefixes) for <Add registration entries for private namespaces (name prefixes) for
implementation- and/or platform-specific extensions.> implementation- and/or platform-specific extensions.>
9. Security Considerations 9. IANA Considerations
This document has no security considerations. This document deals with IANA considerations throughout.
Specifically it creates a single registry of various kinds of things,
thought the IANA may instead create multiple registries each for one
of those kinds of things. Of particular interest may be that IANA
will now be the registration authority for the GSS-API name type OID
space.
10. Normative 10. Security Considerations
[EXTENDED-INQUIRY] This document has no security considerations.
Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", 11. Normative References
draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 : [RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000. C-bindings", RFC 2744, January 2000.
Author's Address Author's Address
Nicolas Williams Nicolas Williams
Sun Microsystems Sun Microsystems
5300 Riata Trace Ct 5300 Riata Trace Ct
Austin, TX 78727 Austin, TX 78727
US US
Email: Nicolas.Williams@sun.com Email: Nicolas.Williams@sun.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 7, line 29 skipping to change at page 8, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 22 change blocks. 
53 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/