1
2
3
4NETWORK WORKING GROUP                                        N. Williams
5Internet-Draft                                                       Sun
6Expires: April 19, 2006                                 October 16, 2005
7
8
9     Namespace Considerations and Registries for GSS-API Extensions
10            draft-ietf-kitten-gssapi-extensions-iana-01.txt
11
12Status of this Memo
13
14   By submitting this Internet-Draft, each author represents that any
15   applicable patent or other IPR claims of which he or she is aware
16   have been or will be disclosed, and any of which he or she becomes
17   aware will be disclosed, in accordance with Section 6 of BCP 79.
18
19   Internet-Drafts are working documents of the Internet Engineering
20   Task Force (IETF), its areas, and its working groups.  Note that
21   other groups may also distribute working documents as Internet-
22   Drafts.
23
24   Internet-Drafts are draft documents valid for a maximum of six months
25   and may be updated, replaced, or obsoleted by other documents at any
26   time.  It is inappropriate to use Internet-Drafts as reference
27   material or to cite them other than as "work in progress."
28
29   The list of current Internet-Drafts can be accessed at
30   http://www.ietf.org/ietf/1id-abstracts.txt.
31
32   The list of Internet-Draft Shadow Directories can be accessed at
33   http://www.ietf.org/shadow.html.
34
35   This Internet-Draft will expire on April 19, 2006.
36
37Copyright Notice
38
39   Copyright (C) The Internet Society (2005).
40
41Abstract
42
43   This document describes the ways in which the GSS-API may be extended
44   and directs the creation of IANA registries for various GSS-API
45   namespaces.
46
47
48
49
50
51
52
53
54
55Williams                 Expires April 19, 2006                 [Page 1]
56
57Internet-Draft            GSS IANA Instructions             October 2005
58
59
60Table of Contents
61
62   1.  Conventions used in this document . . . . . . . . . . . . . . . 3
63   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
64   3.  Extensions to the GSS-API . . . . . . . . . . . . . . . . . . . 3
65   4.  Generic GSS-API Namespaces  . . . . . . . . . . . . . . . . . . 3
66   5.  Language Binding-Specific GSS-API Namespaces  . . . . . . . . . 4
67   6.  Extension-Specific GSS-API Namespaces . . . . . . . . . . . . . 4
68   7.  Registration Form(s)  . . . . . . . . . . . . . . . . . . . . . 4
69   8.  Initial Namespace Registrations . . . . . . . . . . . . . . . . 5
70   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
71   10. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
72       Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 6
73       Intellectual Property and Copyright Statements  . . . . . . . . 7
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Williams                 Expires April 19, 2006                 [Page 2]
112
113Internet-Draft            GSS IANA Instructions             October 2005
114
115
1161.  Conventions used in this document
117
118   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
119   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
120   document are to be interpreted as described in [RFC2119].
121
122
1232.  Introduction
124
125   There is a need for generic and mechanism-specific extensions to the
126   Generic Security Services Application Programming Interface (GSS-
127   API).  As such extensions are designed and standardized, both at the
128   IETF and elsewhere, there is a non-trivial risk of namespace
129   pollution and conflicts.  To avoid this we set out guidelines for
130   extending the GSS-API and create IANA registries of GSS-API
131   namespaces.
132
133   The registration of name prefixes and constant value ranges is
134   allowed so as to save the IANA the trouble of registering every GSS-
135   API name and constant, and to allow for reservation of portions of
136   some GSS namespaces for private extensions or extensions which lack
137   IETF Standards-Track extensions.
138
139
1403.  Extensions to the GSS-API
141
142   Extensions to the GSS-API can be categorized as follows:
143   o  Generic
144   o  Implementation-specific
145   o  Mechanism-specific
146   o  Language binding-specific
147   o  Any combination of two or all three of the last three
148
149   Extensions to the GSS-API may be purely semantic, without effect on
150   the GSS-API's namespaces.  Or they may introduce new functions,
151   constants, types, etc...; these clearly affect the GSS-API
152   namespaces.
153
154   Extensions that affect the GSS-API namespaces should be registered
155   with the IANA.
156
157
1584.  Generic GSS-API Namespaces
159
160   All the function, constant and type names, as well as all the
161   constant values specified in the base GSS-API specification for the
162   basic generic GSS-API namespace.
163
164
165
166
167Williams                 Expires April 19, 2006                 [Page 3]
168
169Internet-Draft            GSS IANA Instructions             October 2005
170
171
172   The generic GSS-API namespaces are:
173   o  Type names
174   o  Function names
175   o  Constant names for each type
176   o  Constant values for each type
177   o  Mechanism OIDs
178   o  Name Type OIDs
179   o  Mechanism Attribute OIDs (see [EXTENDED-INQUIRY])
180
181
1825.  Language Binding-Specific GSS-API Namespaces
183
184   <Add text; discuss header, module, library, class, method namespaces
185   and whatever else comes up that is language-specific and appropriate
186   for registration with the IANA.>
187
188
1896.  Extension-Specific GSS-API Namespaces
190
191   Extensions to the GSS-API may create additional namespaces.
192   Instructions to the IANA should included for the handling of such
193   namespaces.
194
195
1967.  Registration Form(s)
197
198   Registrations for GSS-API namespaces SHALL take the following form:
199
200   <TBD>
201
202   The IANA should create a single GSS-API namespace registry, or
203   multiple registries, one for symbolic names and one for constant
204   values, or it may create a registry per-programming language, at its
205   convenience.
206
207   Entries in these registries should consist of all the fields from
208   their corresponding registration entries.
209
210   Entries SHOULD be sorted by object type, proggamming language, symbol
211   name.
212
213   <Add text on guidelines for IANA consideration of registration
214   applications, particularly with respect to entries lacking normative
215   references, "magic" entries (e.g., special values of 'time' types
216   which indicate something other than absolute or relative time, such
217   as GSS_C_INDEFINITE), expert review requirements (if any) for
218   registrations lacking normative references, etc....>
219
220
221
222
223Williams                 Expires April 19, 2006                 [Page 4]
224
225Internet-Draft            GSS IANA Instructions             October 2005
226
227
2288.  Initial Namespace Registrations
229
230   <Add registration entries for namespaces (name prefixes) for RFC2743/
231   RFC2744/RFC2853.>
232
233   <Add registration entries for private namespaces (name prefixes) for
234   implementation- and/or platform-specific extensions.>
235
236
2379.  Security Considerations
238
239   This document has no security considerations.
240
24110.  Normative
242
243   [EXTENDED-INQUIRY]
244              Williams, N., "Extended Generic Security Service Mechanism
245              Inquiry APIs",
246              draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
247              progress).
248
249   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
250              Requirement Levels", BCP 14, RFC 2119, March 1997.
251
252   [RFC2743]  Linn, J., "Generic Security Service Application Program
253              Interface Version 2, Update 1", RFC 2743, January 2000.
254
255   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
256              C-bindings", RFC 2744, January 2000.
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279Williams                 Expires April 19, 2006                 [Page 5]
280
281Internet-Draft            GSS IANA Instructions             October 2005
282
283
284Author's Address
285
286   Nicolas Williams
287   Sun Microsystems
288   5300 Riata Trace Ct
289   Austin, TX  78727
290   US
291
292   Email: Nicolas.Williams@sun.com
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335Williams                 Expires April 19, 2006                 [Page 6]
336
337Internet-Draft            GSS IANA Instructions             October 2005
338
339
340Intellectual Property Statement
341
342   The IETF takes no position regarding the validity or scope of any
343   Intellectual Property Rights or other rights that might be claimed to
344   pertain to the implementation or use of the technology described in
345   this document or the extent to which any license under such rights
346   might or might not be available; nor does it represent that it has
347   made any independent effort to identify any such rights.  Information
348   on the procedures with respect to rights in RFC documents can be
349   found in BCP 78 and BCP 79.
350
351   Copies of IPR disclosures made to the IETF Secretariat and any
352   assurances of licenses to be made available, or the result of an
353   attempt made to obtain a general license or permission for the use of
354   such proprietary rights by implementers or users of this
355   specification can be obtained from the IETF on-line IPR repository at
356   http://www.ietf.org/ipr.
357
358   The IETF invites any interested party to bring to its attention any
359   copyrights, patents or patent applications, or other proprietary
360   rights that may cover technology that may be required to implement
361   this standard.  Please address the information to the IETF at
362   ietf-ipr@ietf.org.
363
364
365Disclaimer of Validity
366
367   This document and the information contained herein are provided on an
368   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
369   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
370   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
371   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
372   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
373   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
374
375
376Copyright Statement
377
378   Copyright (C) The Internet Society (2005).  This document is subject
379   to the rights, licenses and restrictions contained in BCP 78, and
380   except as set forth therein, the authors retain all their rights.
381
382
383Acknowledgment
384
385   Funding for the RFC Editor function is currently provided by the
386   Internet Society.
387
388
389
390
391Williams                 Expires April 19, 2006                 [Page 7]
392
393
394