1
2
3
4NETWORK WORKING GROUP                                        N. Williams
5Internet-Draft                                                       Sun
6Expires: April 19, 2006                                 October 16, 2005
7
8
9          Stackable Generic Security Service Pseudo-Mechanisms
10            draft-ietf-kitten-stackable-pseudo-mechs-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 defines and formalizes the concept of stackable pseudo-
44   mechanisms, and associated concept of composite mechanisms, for the
45   Generic Security Service Application Programming Interface (GSS-API),
46   as well as several utility functions.
47
48   Stackable GSS-API pseudo-mechanisms allow for the composition of new
49   mechanisms that combine features from multiple mechanisms.  Stackable
50   mechanisms that add support for Perfect Forward Security (PFS), data
51   compression, additional authentication factors, etc... are
52
53
54
55Williams                 Expires April 19, 2006                 [Page 1]
56
57Internet-Draft             Stackable GSS Mechs              October 2005
58
59
60   facilitated by this document.
61
62
63Table of Contents
64
65   1.      Conventions used in this document  . . . . . . . . . . . .  3
66   2.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
67   2.1.    Glossary . . . . . . . . . . . . . . . . . . . . . . . . .  3
68   3.      Mechanism Composition Issues . . . . . . . . . . . . . . .  4
69   4.      Mechanism Composition  . . . . . . . . . . . . . . . . . .  5
70   4.1.    Construction of Composed Mechanism OIDs  . . . . . . . . .  5
71   4.2.    Mechanism Composition Rules  . . . . . . . . . . . . . . .  6
72   4.3.    Interfacing with Composite Mechanisms  . . . . . . . . . .  7
73   4.4.    Compatibility with the Basic GSS-APIv2u1 Interfaces  . . .  7
74   4.5.    Processing of Tokens for Composite Mechanisms  . . . . . .  8
75   5.      New GSS-API Interfaces . . . . . . . . . . . . . . . . . .  8
76   5.1.    New GSS-API Function Interfaces  . . . . . . . . . . . . .  9
77   5.1.1.  GSS_Compose_oid()  . . . . . . . . . . . . . . . . . . . .  9
78   5.1.2.  GSS_Decompose_oid()  . . . . . . . . . . . . . . . . . . . 10
79   5.1.3.  GSS_Release_oid()  . . . . . . . . . . . . . . . . . . . . 10
80   5.1.4.  GSS_Indicate_negotiable_mechs()  . . . . . . . . . . . . . 11
81   5.1.5.  GSS_Negotiate_mechs()  . . . . . . . . . . . . . . . . . . 12
82   5.1.6.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12
83   6.      Negotiation of Composite Mechanisms  . . . . . . . . . . . 13
84   6.1.    Negotiation of Composite Mechanisms Through SPNEGO . . . . 14
85   7.      Requirements for Mechanism Designers . . . . . . . . . . . 14
86   8.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 14
87   9.      Security considerations  . . . . . . . . . . . . . . . . . 14
88   10.     Normative  . . . . . . . . . . . . . . . . . . . . . . . . 15
89           Author's Address . . . . . . . . . . . . . . . . . . . . . 16
90           Intellectual Property and Copyright Statements . . . . . . 17
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             Stackable GSS Mechs              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   Recent discussions within the IETF have shown the need for a
126   refactoring of the features that GSS-API mechanisms may provide and a
127   way to compose new mechanisms from smaller components.
128
129   One way to do this is to "stack" multiple mechanisms on top of each
130   other such that the features of all of them are summed into a new,
131   composite mechanism.
132
133   One existing GSS-API mechanism, LIPKEY [LIPKEY], is essentially
134   stacked over another, SPKM-3 [LIPKEY] (although LIPKEY does not
135   conform to the stackable pseduo-mechanism framework described
136   herein).
137
138   The first truly stackable pseudo-mechanism proposed, CCM [CCM], is
139   intended for signalling, during negotiation of mechanisms, the
140   willingness of an initiator and/or acceptor to utilize channel
141   bindings
142
143   Since then other similar mechanism compositing needs and ideas have
144   come up, along with problems such as "what combinations are possible,
145   useful, reasonable and secure?"  This document addresses those
146   problems.  It introduces the concepts of stackable pseudo-mechanisms,
147   composite mechanisms and mechanism features or attributes, as well as
148   new inquiry and related interfaces to help in the mechanism
149   compositing.
150
151   (Mechanism features are more formally referred to as "mechanism
152   attributes" below.  The terms "feature" and mechanism attribute" are
153   sometimes used interchangeably.)
154
1552.1.  Glossary
156
157   Concrete GSS-API mechanism
158      A mechanism which can be used standalone.  Examples include: the
159      Kerberos V mechanism [CFX], SPKM-1/2 [SPKM] and SPKM-3 [LIPKEY].
160
161   GSS-API Pseudo-mechanism
162      A mechanism which uses other mechanisms in the construction of its
163      context and/or per-message tokens and security contexts.  SPNEGO
164
165
166
167Williams                 Expires April 19, 2006                 [Page 3]
168
169Internet-Draft             Stackable GSS Mechs              October 2005
170
171
172      is an example of this.
173
174   Stackable GSS-API pseudo-mechanism
175      A mechanism which uses a single other mechanism in the
176      construction of its tokens such that the OID of the composite
177      result can be constructed by prepending the OID of the stackable
178      pseudo-mechanism to the OID of the mechanism to be used by it.
179
180   Mechanism-negotiation GSS-API pseudo-mechanism
181      A GSS-API mechanism that negotiates the use of GSS-API mechanisms.
182      SPNEGO [SPNEGO] is an example of this.
183
184
1853.  Mechanism Composition Issues
186
187   Interfacing with composite mechanisms through the existing GSS-API
188   interfaces and the handling of composite mechanism tokens is
189   straightforward enough and described in Section 4.
190
191   However, the concepts of stackable and composite mechanisms do give
192   rise to several minor problems:
193
194   o  How to determine allowable combinations of mechanisms;
195   o  How to encode composite mechanism OIDs;
196   o  How to decompose the OID of a composite mechanism and process its
197      tokens properly;
198   o  Application interfacing issues such as:
199
200      *  Whether and/or which composite mechanisms should be listed by
201         GSS_Indicate_mechs();
202      *  Whether and/or which composite mechanisms not listed by
203         GSS_Indicate_mechs() may nonetheless be available for use by
204         applications and how applications can detect their
205         availability;
206      *  What additional, if any, interfaces should be provided to help
207         applications select appropriate mechanisms;
208   o
209
210      Mechanism negotiation issues (related to the application interface
211      issues listed above), such as: vspace blankLines='1'/>
212      *  Should applications advertise composite mechanisms in SPNEGO or
213         other application-specific mechanism negotiation contexts?
214      *  Or should applications implicitly advertise composite
215         mechanisms by advertising concrete and stackable pseudo-
216         mechanisms in SPNEGO or other application-specific mechanism
217         negotiation contexts?
218
219   Section 4 addresses the OID composition, decomposition and encoding
220
221
222
223Williams                 Expires April 19, 2006                 [Page 4]
224
225Internet-Draft             Stackable GSS Mechs              October 2005
226
227
228   issues, as well as basic interfacing and token handling issues.
229
230   Section 5 addresses interfacing issues more generally through the
231   specification of additional, optional APIs.
232
233   Section 6 addresses mechanism negotiation issues.
234
235
2364.  Mechanism Composition
237
238   Mechanism composition by stacking pseudo-mechanisms on a concrete
239   mechanism is conceptually simple: join the OIDs of the several
240   mechanisms in question and process GSS-API tokens and routine calls
241   through the top-most pseudo-mechanism in a stack, which can then, if
242   necessary, recursively call the GSS-API to process any tokens for the
243   remainder of the stack.
244
245   Some stackable pseudo-mechanisms may do nothing more than perform
246   transformations on application data (e.g., compression); such pseudo-
247   mechanisms will generally chain the processing of tokens and routine
248   calls to the mechanisms below them in the stack.
249
250   Other stackable pseudo-mechanisms may utilize the mechanisms below
251   them only during security context setup.  For example, a stackable
252   pseudo-mechanism could perform a Diffie-Hellman key exchange and
253   authenticate it by binding a security context established with the
254   mechanism stacked below it; such a mechanism would provide its own
255   per-message tokens.
256
2574.1.  Construction of Composed Mechanism OIDs
258
259   Composition of mechanism OIDs is simple: prepend the OID of one
260   pseudo-mechanism to the OID of another mechanism (composite or
261   otherwise), but there MUST always be at least one final mechanism OID
262   and it MUST be useful standalone (i.e., it MUST NOT be a pseudo-
263   mechanism).  A composite mechanism OID forms, essentially, a stack.
264
265   The encoding of composed mechanism OIDs is not quite the
266   concatenation of the component OIDs' encodings, however.  This is
267   because the first two arcs of ASN.1 OIDs are encoded differently from
268   subsequent arcs (the first two arcs have a limited namespace and are
269   encoded as a single octet), so were composite mechanism OIDs to be
270   encoded as the concatenation of the component OIDs the result would
271   not decode as the concatenation of the component OIDs.  To avoid this
272   problem the first two arcs of each component of a composite mechanism
273   OID, other than the leading component, will be encoded as other arcs
274   would.
275
276
277
278
279Williams                 Expires April 19, 2006                 [Page 5]
280
281Internet-Draft             Stackable GSS Mechs              October 2005
282
283
284   Decomposition of composite mechanism OIDs is similar, with each
285   pseudo-mechanism in the stack being able to determine the OID suffix
286   from knowledge of its own OID(s).
287
288   New pseudo-mechanisms MAY be allocated OIDs from the prefix given
289   below as follows by assignment of a sub-string of OID arcs to be
290   appended to this prefix.  This prefix OID is:
291
292   <TBD> [1.3.6.1.5.5.11 appears to be available, registration w/ IANA
293   TBD]
294
295   All OID allocations below this OID MUST be for stackable pseudo-
296   mechanisms and MUST consist of a single arc.  This will make it
297   possible to decompose the OIDs of composite mechanisms without
298   necessarily knowing a priori the OIDs of the component stackable
299   pseudo-mechanisms.
300
3014.2.  Mechanism Composition Rules
302
303   All new stackable pseudo-mechanisms MUST specify the rules for
304   determining whether they can stack above a given mechanism, composite
305   or otherwise.  Such rules may be based on specific mechanism
306   attribute OID sets [EXTENDED-INQUIRY] and/or specific mechanism OIDs
307   (composite and otherwise).
308
309   All stackable pseudo-mechanisms MUST have the following mechanism
310   composition rule relating to unknown mechanism attributes:
311
312   o  composition with mechanisms supporting unknown mechanism
313      attributes MUST NOT be permitted.
314
315   This rule protects against compositions which cannot be considered
316   today but which might nonetheless arise due to the introduction of
317   new mechanisms and which might turn out to be insecure or otherwise
318   undesirable.
319
320   Mechanism composition rules for stackable pseudo-mechanisms MAY and
321   SHOULD be updated as new GSS-API mechanism attributes and mechanisms
322   sporting them are introduced.  The specifications of mechanisms that
323   introduce new mechanism attributes or which otherwise should not be
324   combined with others in ways which would be permitted under existing
325   rules SHOULD also update the mechanism composition rules of affected
326   pseudo-mechanisms.
327
328   A RECOMMENDED way to describe the stacking rules for stackable
329   mechanisms is as an ordered sequence of "MAY stack above X
330   mechanism," "REQUIRES Y mechanism feature(s)," "MUST NOT stack above
331   Z mechanism," and/or "MUST NOT stack above a mechanism with Z
332
333
334
335Williams                 Expires April 19, 2006                 [Page 6]
336
337Internet-Draft             Stackable GSS Mechs              October 2005
338
339
340   mechanism feature(s)."
341
342   For example a stackable mechanism that provides its own per-msg
343   tokens and does not use the underlying mechnism's per-msg token
344   facilities might require a rule such as "MUST NOT stack above a
345   mechanism with the GSS_C_MA_COMPRESS mechanism feature."
346
3474.3.  Interfacing with Composite Mechanisms
348
349   The basic GSS-API [RFC2743] interfaces MUST NOT accept as input or
350   provide as output the OID of any stackable pseudo-mechanism.
351   Composite mechanisms MUST be treated as concrete mechanisms by the
352   basic GSS-API interfaces [RFC2743].
353
354   Thus the way in which a composite mechanism is used by applications
355   with the basic GSS-API (version 2, update 1) is straightforward:
356   exactly as if composite mechanisms were normal GSS-API mechanisms.
357
358   This is facilitated by the fact that in all cases where the GSS-API
359   implementation might need to know how to process or create a token it
360   has the necessary contextual information, that is, the mechanism OID,
361   available and can decompose composite mechanism OIDs as necessary.
362
363   For example, for initial GSS_Init_sec_context() calls the
364   implementation knows the desired mechanism OID, and if it should be
365   left unspecified, it can pick a default mechanism given the initiator
366   credentials provided by the application (and if none are provided
367   other default mechanism and credential selections can still be made).
368   For subsequent calls to GSS_Init_sec_context() the implementation
369   knows which mechanism to use from the given [partially established]
370   security context.  Similarly for GSS_Accept_sec_context, where on
371   initial calls the mechanism OID can be determined from the given
372   initial context token's framing.
373
374   The manner in which GSS-API implementations and the various
375   mechanisms and pseudo-mechanisms interface with one another is left
376   as an excercise to implementors.
377
3784.4.  Compatibility with the Basic GSS-APIv2u1 Interfaces
379
380   In order to preserve backwards compatibility with applications that
381   use only the basic GSS-API interfaces (version 2, update 1), several
382   restrictions are imposed on the use of composite and stackable
383   pseduo-mechanisms with the basic GSS-API interfaces:
384
385   o  GSS_Indicate_mechs() MUST NOT indicate support for any stackable
386      pseduo-mechanisms under any circumstance.
387   o  GSS_Indicate_mechs() MAY indicate support for some, all or none of
388
389
390
391Williams                 Expires April 19, 2006                 [Page 7]
392
393Internet-Draft             Stackable GSS Mechs              October 2005
394
395
396      the available composite mechanisms.
397   o  Which composite mechanisms, if any, are indicated through
398      GSS_Indicate_mechs() SHOULD be configurable.
399   o  Composite mechanisms which are not indicated by
400      GSS_Indicate_mechs() MUST NOT be considered as the default
401      mechanism (GSS_C_NULL_OID) or as part of the default mechanism set
402      (GSS_C_NULL_OID_SET).
403   o  The OIDs of *stackable* (not composite) pseudo-mechanisms MUST NOT
404      be accepted as inputs or produced in the output of any of the
405      basic GSS-APIv2, update 1 API functions, except for any OID set
406      construction/iteration functions.  And, if present in any OID SET
407      input parameters of GSS-APIv2, update 1 functions, they MUST be
408      ignored.
409   o  The OIDs of *stackable* (not composite) pseudo-mechanisms MAY only
410      be used as inputs or produced as outputs of functions whose
411      specification explicitly allows for them or which are concerned
412      with the creation/iteration of OID containters, such as OID SETs.
413
4144.5.  Processing of Tokens for Composite Mechanisms
415
416   The initial context token for any standard mechanism, including
417   mechanisms composited from standard pseudo- and concrete mechanisms,
418   MUST be encapsulated as described in section 3.1 of rfc2743
419   [RFC2743], and the OID used in that framing MUST be that of the
420   mechanism, but in the case of composite mechanisms this OID MUST be
421   the OID of the leading component of the composite mechanism.
422
423   Note that this has implications for pluggable multi-mechanism
424   implementations of the GSS-API, namely that acceptors must route
425   initial context tokens to the appropriate mechanism and they must
426   allow that mechanism to determine the composite mechanism OID (such
427   as by allowing that mechanism's GSS_Accept_sec_context() to output
428   the actual mechanism to the application.
429
430   In all other cases the mechanism that produced or is to produce a
431   given token can be determined internally through the given security
432   context.
433
434
4355.  New GSS-API Interfaces
436
437   ...
438
439   Utility functions for mechanism OID composition and decomposition are
440   given in sections 5.1.1, 5.1.2 and 5.1.3.
441
442   Two utility functions, GSS_Indicate_negotiable_mechs() and
443   GSS_Negotiate_mechs(), to aid applications in mechanism negotiation
444
445
446
447Williams                 Expires April 19, 2006                 [Page 8]
448
449Internet-Draft             Stackable GSS Mechs              October 2005
450
451
452   are described in sections 5.1.4 and 5.1.5.  These two interfaces may
453   be implemented entirely in terms of the other interfaces described
454   herein.
455
4565.1.  New GSS-API Function Interfaces
457
458   Several new interfaces are given by which, for example, GSS-API
459   applications may determine what features are provided by a given
460   mechanism, what mechanisms provide what features and what
461   compositions are legal.
462
463   These new interfaces are all OPTIONAL.
464
465   In order to preserve backwards compatibility with applications that
466   do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate
467   support for any stackable pseduo-mechanisms.  GSS_Indicate_mechs()
468   MAY indicate support for some, all or none of the available composite
469   mechanisms; which composite mechanisms, if any, are indicated through
470   GSS_Indicate_mechs() SHOULD be configurable.  GSS_Acquire_cred() and
471   GSS_Add_cred() MUST NOT create credentials for composite mechanisms
472   not explicitly requested or, if no desired mechanism or mechanisms
473   are given, for composite mechanisms not indicated by
474   GSS_Indicate_mechs().
475
476   Applications SHOULD use GSS_Indicate_mechs_by_mech_attrs() instead of
477   GSS_Indicate_mechs() wherever possible.
478
479   Applications can use GSS_Indicate_mechs_by_mech_attrs() to determine
480   what, if any, mechanisms provide a given set of features.
481
482   GSS_Indicate_mechs_by_mech_attrs() can also be used to indicate (as
483   in GSS_Indicate_mechs()) the set of available mechanisms of each type
484   (concrete, mechanism negotiation pseudo-mechanism, stackable pseudo-
485   mechanism and composite mechanisms).
486
487   Applications may use GSS_Inquire_mech_attrs_for_mech() to test
488   whether a given composite mechanism is available and the set of
489   features that it offers.
490
491   GSS_Negotiate_mechs() may be used to negotiate the use of mechanisms
492   such that composite mechanisms need not be advertised but instead be
493   implied by offering stackable pseudo-mechanisms.
494
4955.1.1.  GSS_Compose_oid()
496
497   Inputs:
498   o  mech1 OBJECT IDENTIFIER, -- mechanism OID
499   o  mech2 OBJECT IDENTIFIER -- mechanism OID
500
501
502
503Williams                 Expires April 19, 2006                 [Page 9]
504
505Internet-Draft             Stackable GSS Mechs              October 2005
506
507
508   Outputs:
509   o  major_status INTEGER,
510   o  minor_status INTEGER,
511   o  composite OBJECT IDENTIFIER -- OID composition of mech1 with mech2
512      ({mech1 mech2})
513
514   Return major_status codes:
515   o  GSS_S_COMPLETE indicates success.
516   o  GSS_S_BAD_MECH indicates that mech1 is not supported.
517   o  GSS_S_FAILURE indicates that the request failed for some other
518      reason.  The minor status will be specific to mech1 and may
519      provide further information.
520
5215.1.2.  GSS_Decompose_oid()
522
523   Inputs:
524   o  input_mech OBJECT IDENTIFIER, -- mechanism OID.
525   o  mechs SET OF OBJECT IDENTIFIER -- mechanism OIDs (if
526      GSS_C_NULL_OID_SET defaults to the set of stackable pseudo-
527      mechanism OIDs indicated by GSS_Indicate_mechs_by_mech_attrs()).
528
529   Outputs:
530   o  major_status INTEGER,
531   o  minor_status INTEGER,
532   o  lead_mech OBJECT IDENTIFIER, -- leading stackable pseudo-
533      mechanism OID.
534   o  trail_mech OBJECT IDENTIFIER -- input_mech with lead_mech removed
535      from the front.
536
537   Return major_status codes:
538   o  GSS_S_COMPLETE indicates success.
539   o  GSS_S_BAD_MECH indicates that the input_mech could not be
540      decomposed as no stackable pseudo-mechanism is available whose OID
541      is a prefix of the input_mech.
542   o  GSS_S_FAILURE indicates that the request failed for some other
543      reason.
544
5455.1.3.  GSS_Release_oid()
546
547   The following text is adapted from the obsoleted rfc2078 [RFC2078].
548
549   Inputs:
550   o  oid OBJECT IDENTIFIER
551
552   Outputs:
553   o  major_status INTEGER,
554   o  minor_status INTEGER
555
556
557
558
559Williams                 Expires April 19, 2006                [Page 10]
560
561Internet-Draft             Stackable GSS Mechs              October 2005
562
563
564   Return major_status codes:
565   o  GSS_S_COMPLETE indicates successful completion
566   o  GSS_S_FAILURE indicates that the operation failed
567
568   Allows the caller to release the storage associated with an OBJECT
569   IDENTIFIER buffer allocated by another GSS-API call, specifically
570   GSS_Compose_oid() and GSS_Decompose_oid().  This call's specific
571   behavior depends on the language and programming environment within
572   which a GSS-API implementation operates, and is therefore detailed
573   within applicable bindings specifications; in particular, this call
574   may be superfluous within bindings where memory management is
575   automatic.
576
5775.1.4.  GSS_Indicate_negotiable_mechs()
578
579   Inputs:
580   o  input_cred_handle CREDENTIAL HANDLE, -- credential handle to be
581      used with GSS_Init_sec_context(); may be GSS_C_NO_CREDENTIAL.
582   o  peer_type_known BOOLEAN, -- indicates whether the peer is known to
583      support or not supprot the stackable pseudo-mechanism framework.
584   o  peer_has_mech_stacking BOOLEAN -- indicates whether the peer
585      supports the stackable pseudo-mechanism framework; ignore if
586      peer_type_known is FALSE.
587
588   Outputs:
589   o  major_status INTEGER,
590   o  minor_status INTEGER,
591   o  offer_mechs SET OF OBJECT IDENTIFIER, -- mechanisms to offer.
592
593   Return major_status codes:
594   o  GSS_S_COMPLETE indicates success.
595   o  GSS_S_NO_CREDENTIAL indicates that the caller's credentials are
596      expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no
597      credentials could be acquired for GSS_C_NO_NAME.
598   o  GSS_S_FAILURE indicates that the request failed for some other
599      reason.
600
601   This function produces a set of mechanism OIDs, optimized for space,
602   that its caller should advertise to peers during mechanism
603   negotiation.
604
605   The output offer_mechs parameter will include all of the mechanisms
606   for which the input_cred_handle has elements (as indicated by
607   GSS_Inquire_cred()), but composite mechanisms will be included either
608   implicitly or implicitly as per the following rules:
609   o  if peer_type_known is TRUE and peer_has_mech_stacking is FALSE
610      then no composite mechanisms not indicated by GSS_Indicate_mechs()
611      will be advertised, explictly or implicitly;
612
613
614
615Williams                 Expires April 19, 2006                [Page 11]
616
617Internet-Draft             Stackable GSS Mechs              October 2005
618
619
620   o  if peer_type_known is FALSE then all composite mechanisms
621      indicated by GSS_Indicate_mechs() for which input_cred_handle has
622      elements will be indicated in offer_mechs explicitly and all
623      others may be indicated in offer_mechs implicitly, by including
624      their component stackable pseduo-mechanism OIDs (see below);
625   o  if peer_type_known is TRUE and peer_has_mech_stacking is TRUE
626      composite mechanisms will generally not be advertised explicitly,
627      but will be advertised implicitly, by including their component
628      stackable pseduo-mechanism OIDs (see below); no composite
629      mechanisms will be advertised explicitly
630   o  if the input_cred_handle does not have elements for all of the
631      possible composite mechanisms that could be constructed from the
632      its elements' decomposed mechanisms, then all composite mechanisms
633      for which the input_cred_handle does have elements will be
634      advertised explicitly in offer_mechs.
635
6365.1.5.  GSS_Negotiate_mechs()
637
638   Inputs:
639   o  input_credential_handle CREDENTIAL HANDLE, -- mechanisms offered
640      by the caller.
641   o  peer_mechs SET OF OBJECT IDENTIFIER -- mechanisms offered by the
642      caller's peer.
643
644   Outputs:
645   o  major_status INTEGER,
646   o  minor_status INTEGER,
647   o  mechs SET OF OBJECT IDENTIFIER -- mechanisms common to the
648      caller's credentials and the caller's peer.
649
650   Return major_status codes:
651   o  GSS_S_COMPLETE indicates success; the output mechs parameter MAY
652      be the empty set (GSS_C_NO_OID_SET).
653   o  GSS_S_NO_CREDENTIAL indicates that the caller's credentials are
654      expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no
655      credentials could be acquired for GSS_C_NO_NAME.
656   o  GSS_S_FAILURE indicates that the request failed for some other
657      reason.
658
659   This function matches the mechanisms for which the caller has
660   credentials with the mechanisms offered by the caller's peer and
661   returns the set of mechanisms in common to both, accounting for any
662   composite mechanisms offered by the peer implicitly.
663
6645.1.6.  C-Bindings
665
666
667      OM_uint32 gss_compose_oid(
668
669
670
671Williams                 Expires April 19, 2006                [Page 12]
672
673Internet-Draft             Stackable GSS Mechs              October 2005
674
675
676         OM_uint32         *minor_status,
677         const gss_OID      mech1,
678         const gss_OID      mech2,
679         gss_OID           *composite);
680
681      OM_uint32 gss_decompose_oid(
682         OM_uint32         *minor_status,
683         const gss_OID      input_mech,
684         const gss_OID_set  mechs,
685         gss_OID           *lead_mech,
686         gss_OID           *trail_mech);
687
688      OM_uint32 gss_release_oid(
689         OM_uint32         *minor_status,
690         gss_OID           *oid);
691
692      OM_uint32 gss_indicate_negotiable_mechs(
693         OM_uint32                 *minor_status,
694         const gss_cred_id_t        input_cred_handle,
695         OM_uint32                  peer_type_known,
696         OM_uint32                  peer_has_mech_stacking,
697         gss_OID_set               *offer_mechs);
698
699      OM_uint32 gss_negotiate_mechs(
700         OM_uint32                 *minor_status,
701         const gss_cred_id_t        input_cred_handle,
702         const gss_OID_set          peer_mechs,
703         const gss_OID_set         *mechs);
704
705
706   Figure 1
707
708
7096.  Negotiation of Composite Mechanisms
710
711   Where GSS-API implementations do not support the stackable mechanism
712   framework interfaces applications may only negotiate explicitly from
713   a set of concrete and composite mechanism OIDs as indicated by
714   GSS_Indicate_mechs() and for which suitable credentials are
715   available.  GSS_Indicate_mechs(), as described in Section 4.4, MUST
716   NOT indicate support for individual stackable pseudo-mechanisms, so
717   there will not be any composite mechanisms implied but not explicitly
718   offered in the mechanism negotiation.
719
720   Applications that support the stackable mechanism framework SHOULD
721   use GSS_Indicate_negotiable_mechs() to construct the set of mechanism
722   OIDs to offer to their peers.  GSS_Indicate_negotiable_mechs()
723   optimizes for bandwidth consumption by using decomposed OIDs instead
724
725
726
727Williams                 Expires April 19, 2006                [Page 13]
728
729Internet-Draft             Stackable GSS Mechs              October 2005
730
731
732   of composed OIDs, where possible.  See Section 5.1.4.
733
734   Peers that support the stackable mechanism framework interfaces
735   SHOULD use GSS_Negotiate_mechs() to select a mechanism as that
736   routine accounts for composite mechanisms implicit in the mechanism
737   offers.
738
7396.1.  Negotiation of Composite Mechanisms Through SPNEGO
740
741   SPNEGO applications MUST advertise either the set of mechanism OIDs
742   for which they have suitable credentials or the set of mechanism OIDs
743   produced by calling GSS_Indicate_negotiable_mechs() with the
744   available credentials and the peer_type_known parameter as FALSE.
745
746
7477.  Requirements for Mechanism Designers
748
749   Stackable pseudo-mechanisms specifications MUST:
750   o  list the set of GSS-API mechanism attributes associated with them
751   o  list their initial mechanism composition rules
752   o  specify a mechanism for updating their mechanism composition rules
753
754   All other mechanism specifications MUST:
755   o  list the set of GSS-API mechanism attributes associated with them
756
757
7588.  IANA Considerations
759
760   Allocation of arcs in the namespace of OIDs relative to the base
761   stackable pseduo-mechanism OID specified in Section 4.1 is reserved
762   to the IANA.
763
764
7659.  Security considerations
766
767   Some composite mechanisms may well not be secure.  The mechanism
768   composition rules of pseudo-mechanisms (including the default
769   composition rule given in Section 4 for unknown mechanism attributes)
770   should be used to prevent the use of unsafe composite mechanisms.
771
772   Designers of pseudo-mechanisms should study the possible combinations
773   of their mechanisms with others and design mechanism composition
774   rules accordingly.
775
776   Similarly, pseudo-mechanism designers MUST specify, and implementors
777   MUST implement, composite mechanism attribute set determination rules
778   appropriate to the subject pseduo-mechanism, as described in section
779   4.2.  Failure to do so may lead to inappropriate composite mechanisms
780
781
782
783Williams                 Expires April 19, 2006                [Page 14]
784
785Internet-Draft             Stackable GSS Mechs              October 2005
786
787
788   being deemed permissible by programmatic application of flawed
789   mechanism composition rules or to by their application with incorrect
790   mechanism attribute sets.
791
79210.  Normative
793
794   [EXTENDED-INQUIRY]
795              Williams, N., "Extended Generic Security Service Mechanism
796              Inquiry APIs",
797              draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
798              progress).
799
800   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
801              Requirement Levels", BCP 14, RFC 2119, March 1997.
802
803   [RFC2743]  Linn, J., "Generic Security Service Application Program
804              Interface Version 2, Update 1", RFC 2743, January 2000.
805
806   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
807              C-bindings", RFC 2744, January 2000.
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839Williams                 Expires April 19, 2006                [Page 15]
840
841Internet-Draft             Stackable GSS Mechs              October 2005
842
843
844Author's Address
845
846   Nicolas Williams
847   Sun Microsystems
848   5300 Riata Trace Ct
849   Austin, TX  78727
850   US
851
852   Email: Nicolas.Williams@sun.com
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895Williams                 Expires April 19, 2006                [Page 16]
896
897Internet-Draft             Stackable GSS Mechs              October 2005
898
899
900Intellectual Property Statement
901
902   The IETF takes no position regarding the validity or scope of any
903   Intellectual Property Rights or other rights that might be claimed to
904   pertain to the implementation or use of the technology described in
905   this document or the extent to which any license under such rights
906   might or might not be available; nor does it represent that it has
907   made any independent effort to identify any such rights.  Information
908   on the procedures with respect to rights in RFC documents can be
909   found in BCP 78 and BCP 79.
910
911   Copies of IPR disclosures made to the IETF Secretariat and any
912   assurances of licenses to be made available, or the result of an
913   attempt made to obtain a general license or permission for the use of
914   such proprietary rights by implementers or users of this
915   specification can be obtained from the IETF on-line IPR repository at
916   http://www.ietf.org/ipr.
917
918   The IETF invites any interested party to bring to its attention any
919   copyrights, patents or patent applications, or other proprietary
920   rights that may cover technology that may be required to implement
921   this standard.  Please address the information to the IETF at
922   ietf-ipr@ietf.org.
923
924
925Disclaimer of Validity
926
927   This document and the information contained herein are provided on an
928   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
929   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
930   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
931   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
932   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
933   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
934
935
936Copyright Statement
937
938   Copyright (C) The Internet Society (2005).  This document is subject
939   to the rights, licenses and restrictions contained in BCP 78, and
940   except as set forth therein, the authors retain all their rights.
941
942
943Acknowledgment
944
945   Funding for the RFC Editor function is currently provided by the
946   Internet Society.
947
948
949
950
951Williams                 Expires April 19, 2006                [Page 17]
952
953
954