home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-cat-snego-03.txt < prev    next >
Text File  |  1997-03-24  |  26KB  |  697 lines
  1. Internet-Draft                                 Eric Baize, Denis Pinkas
  2. IETF Common Authentication Technology WG                           Bull
  3. <draft-ietf-cat-snego-03.txt>                             25 March 1997
  4.  
  5.  
  6.  
  7.                   Simple GSS-API Negotiation Mechanism 
  8.  
  9.  
  10.  
  11. STATUS OF THIS MEMO
  12.  
  13. This document is an Internet-Draft. Internet-Drafts are working
  14. documents of the Internet Engineering Task Force (IETF), its areas,
  15. and its working groups. Note that other groups may also distribute 
  16. working documents as Internet-Drafts.
  17.  
  18. Internet-Drafts are draft documents valid for a maximum of six months
  19. and may be updated, replaced, or obsoleted by other documents at any 
  20. time. It is inappropriate to use Internet-Drafts as reference 
  21. material or to cite them other than as ``work in progress.''
  22.  
  23. To learn the current status of any Internet-Draft, please check the 
  24. ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  25. Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  26. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 
  27. ftp.isi.edu (US West Coast).
  28.  
  29. Comments on this document should be sent to "cat-ietf@mit.edu", the
  30. IETF Common Authentication Technology WG discussion list. Distribution
  31. of this document is unlimited.
  32.  
  33.  
  34. 2.  ABSTRACT
  35.  
  36. This draft document specifies a Security Negotiation Mechanism for the
  37. Generic Security Service Application Program Interface (GSS-API) which
  38. is described in [1].
  39.  
  40. The GSS-API provides a generic interface which can be layered atop
  41. different security mechanisms such that if communicating peers acquire
  42. GSS-API credentials for the same security mechanism, then a security
  43. context may be established between them (subject to policy). However,
  44. GSS-API doesn't prescribe the method by which GSS-API peers can
  45. establish whether they have a common security mechanism. 
  46.  
  47. The Simple GSS-API Negotiation Mechanism defined here is a pseudo-
  48. security mechanism, represented by the object identifier 
  49. iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which 
  50. enables GSS-API peers to determine in-band whether their credential 
  51. share common GSS-API security mechanism(s), and if so, to invoke 
  52. normal security context establishment for a selected common security 
  53. mechanism. This is most useful for applications that are based on 
  54. GSS-API implementations which support multiple security mechanisms. 
  55.  
  56.  
  57.  
  58. Baize, Pinkas        Document Expiration:  25 September 1997     [Page 1]
  59.  Internet-Draft                                            March 25, 1997
  60.  
  61.  
  62. As most existing GSS-API security mechanisms can support different
  63. options (such as differing cryptographic algorithms due to policy or
  64. legislative constraints), the Simple GSS-API Negotiation Mechanism
  65. allows to negotiate security mechanisms including their options
  66. (i.e. variants). Mechanism options can be considered as providing a
  67. type of "quality of protection" for security contexts.
  68.  
  69. To facilitate mechanism negotiation, the OID which currently defines a
  70. security mechanism is "extended" to be able to specify options within a
  71. security mechanism rather than simply the basic mechanism. When the OID
  72. specifies the mechanism only and no explicit option, then this means
  73. that the default option is used. The default option and the specific
  74. options for a given mechanism are as defined in the IETF GSS-API 
  75. specification(s) for the mechanism. 
  76.  
  77. This allows to negotiate basic security mechanisms, different options
  78. within a given security mechanism or different options from several
  79. basic security mechanisms.
  80.  
  81. In addition, a given security mechanism may still negotiate mechanism-
  82. specific options during the context establishment for that mechanism,
  83. i.e. after the mechanism has been selected by the negotiation process.
  84.  
  85. The simple GSS-API mechanism negotiation is based on a two-ways
  86. negotiation model : The initiator proposes one or several security
  87. mechanisms, the target either accepts the proposed security mechanism,
  88. or chooses one from an offered set, or rejects the proposed value(s).
  89. The target informs the initiator of its choice and may also return
  90. mechanism specific information related to the chosen mechanism. 
  91.  
  92. In its basic form this protocol requires an extra-round trip. Network 
  93. connection setup is a critical performance characteristic of any network 
  94. infrastructure and extra round trips over WAN links, packet radio networks, 
  95. etc. really make a difference. In order to avoid such an extra round trip 
  96. the initial security token of the preferred mechanism for the initiator may 
  97. be embedded in the initial token. If the target preferred mechanism matches 
  98. the initiator's preferred mechanism, no additional round trips are incurred 
  99. by using the negotiation protocol.
  100.  
  101. The simple GSS-API mechanism negotiation does not provide any security
  102. feature to protect the initially exchanged values for security context
  103. parameters (i.e. during the negotiation process). This implies that all 
  104. negotiated mechanisms including their options should be of the same 
  105. strength.
  106.  
  107. The Simple GSS-API Negotiation Mechanism uses the concepts developed
  108. in GSS-API specification [1], and requires the use of a new GSS-API
  109. context-level token : the negotiation token. Callers of the GSS-API do
  110. not need to be aware of the negotiation token but only of the new
  111. pseudo-security mechanism. A failure in the negotiation phase causes a
  112. major status code to be returned: GSS_S_BAD_MECH.
  113.  
  114.  
  115.  
  116. Baize, Pinkas        Document Expiration:  25 September 1997    [Page 2]
  117.  Internet-Draft                                           March 25, 1997
  118.  
  119. 3.  NEGOTIATION MODEL
  120.  
  121. 3.1.  Negotiation description
  122.  
  123. The model for security mechanism negotiation reuses a subset of the
  124. concepts specified in [2].
  125.  
  126. Each security mechanism represents one basic security mechanism along
  127. with one option for this security mechanism (when no option is present
  128. the default option is assumed).
  129.  
  130.  -  When one security mechanism is proposed by the initiator, it
  131.     represents the only security mechanism option supported or
  132.     selected (when the additional APIs defined in the Annex A
  133.     are used) by the initiator.
  134.  
  135.  -  When several security mechanisms are proposed by the initiator,
  136.     they represent a set of security mechanisms supported or selected
  137.     (when the additional APIs defined in the Annex A are used) by the
  138.     initiator.
  139.  
  140. The initiator negotiation token contains an ordered list of mechanisms
  141. and optionally the initial security token for the desired mechanism of
  142. the initiator (i.e. the first of the list).
  143.  
  144. The target negotiation reply contains the result of the negotiation
  145. (accept or reject) and, in case of accept, the agreed security
  146. mechanism along with optional mechanism specific information. It may
  147. also include the response to the initial security token, when the first
  148. proposed mechanism has been selected. Not all targets must be able to
  149. respond to the initial security token for the desired mechanism when
  150. it is present. The target can simply ignore it and complete the
  151. negotiation handshake without it. Implementations that can piggyback
  152. the initial token will be rewarded by faster connection setup.
  153.  
  154. In case of a successful negotiation, the security mechanism represents
  155. the value suitable for the target, and picked up from the list offered
  156. by the initiator. The target selects the value according to a simple
  157. selection criteria: it checks if the first entry from its own list is
  158. present in the set offered by the initiator. If the entry is present,
  159. then it is the agreed mechanism, if not then the second entry from its
  160. own ordered list is checked and the process continues until all
  161. entries have been checked. Thus, the target's mechanism preferences
  162. have precedence when more than one common mechanism is available
  163. between the target and initiator. 
  164.  
  165. 3.2.  Negotiation procedure
  166.  
  167. The negotiation procedure is summarised as follows:
  168.  
  169. (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but
  170. requests (either explicitly, with the negotiation mechanism, or
  171. through accepting a default, when the default is the negotiation
  172. mechanism) that the Simple GSS-API Negotiation Mechanism be used; 
  173.  
  174. Baize, Pinkas        Document Expiration:  25 September 1997     [Page 3]
  175.  Internet-Draft                                            April 17, 1996
  176.  
  177. b) the initiator GSS-API implementation emits a negotion token
  178. containing the set of supported security mechanism for the credentials
  179. used for this context establishment, and optionally the initial
  180. security token for the preferred mechanism, and indicates
  181. GSS_CONTINUE_NEEDED status;
  182.  
  183. (c) The GSS-API initiator sends the token to the target application;
  184.  
  185. (d) The GSS-API target deposits the token through invoking
  186. GSS_Accept_sec_context. The target GSS-API implementation emits a
  187. negotiation token containing which if any of the proposed mechanisms
  188. it supports (or has selected).
  189.  
  190. If the preferred mechanism selected by the target matches the preferred
  191. mechanism identified by the initiator and the initiator provides a
  192. preferredToken, the negotiation token response may contain also the 
  193. initial security token from that mechanism.
  194.  
  195. If the preferred mechanism is accepted, GSS_Accept_sec_context()
  196. indicates GSS_COMPLETE when unilateral authentication has been 
  197. performed and involves a single token.
  198.  
  199. If the proposed mechanism(s) are accepted, or the preferred mechanism
  200. is accepted but involves multiple exchanges (e.g. mutual 
  201. authentication), then GSS_Accept_sec_context()indicates 
  202. GSS_CONTINUE_NEEDED status. 
  203.  
  204. If the proposed mechanism(s) are rejected, GSS_Accept_sec_context()
  205. indicates GSS_S_BAD_MECH status. The security context initialisation
  206. has failed. 
  207.  
  208. (e) The GSS-API target returns the token to the initiator application;
  209.  
  210. (f) The GSS-API initiator deposits the token through invoking
  211. GSS_Init_sec_context.
  212.  
  213. If the negotiation token carries an accept result,
  214. GSS_Init_sec_context() returns an initial context token as
  215. output_token, and indicates GSS_CONTINUE_NEEDED or GSS_COMPLETE
  216. status. The initiator sends the output_token to the target. The
  217. security context initialisation is then performed according to the
  218. standard GSS-API conventions for the selected mechanism. When
  219. GSS_COMPLETE is returned, the mech_type output parameter indicates the
  220. selected mechanism. Since the negotiation exchanges are not crypto-
  221. graphically protected, the initiator GSS-API implementation must check 
  222. the returned/selected mechanism options with its originally submitted 
  223. list of mechanism options. When GSS_CONTINUE_NEEDED is returned, the 
  224. mech_type output parameter is not yet valid.
  225.  
  226. Note that the *_req_flag input parameters for context establishment
  227. are relative to the selected mechanism, as are the *_state output
  228. parameters. i.e., these parameters are not applicable to the
  229. negotiation process per se.
  230.  
  231.  
  232. Baize, Pinkas        Document Expiration:  25 September 1997    [Page 4]
  233.  Internet-Draft                                           March 25, 1997
  234.  
  235. If the negotiation token carries a reject result, the context
  236. establishment is impossible, and GSS_Init_sec_context() indicates
  237. GSS_S_BAD_MECH status. For example, a rejection will occur if
  238. the target doesn't support the initiator's proposed mechanism type(s)
  239. and/or mechanism option(s). Upon failure of the mechanism negotiation
  240. procedure, the mech_type output parameter value is the negotiation
  241. mechanism type. However, upon failure of the selected mechanism
  242. context establishment, the mech_type output parameter value is the
  243. selected mechanism type.
  244.  
  245. On receipt of a negotiation token on the target side, a GSS-API
  246. implementation that does not support negotiation would indicate the
  247. GSS_FAILURE status as if a particular basic security mechanism had
  248. been requested but was not supported.
  249.  
  250. When GSS_Acquire_cred is invoked with the negotiation mechanism as 
  251. desired_mechs, an implementation-specific default credential is used to 
  252. carry on the negotiation. A set of mechanisms as specified locally by the 
  253. system administrator is then available for negotiation. If there is a 
  254. desire for the caller to make its own choice, then an additional API has to 
  255. be used (see Appendix A).
  256.  
  257. 4.  DATA ELEMENTS
  258.  
  259. 4.1.  Mechanism Type
  260.  
  261. MechType::= OBJECT IDENTIFIER
  262.  
  263. mechType
  264.      The concept of mechType is extended to specify a basic security
  265.      mechanism including its options. Each basic security mechanism
  266.      is as defined in [1], and must provide a single default option
  267.      which fully specifies the mechanism. The default option is
  268.      represented by the OID of the mechanism itself (i.e. without any
  269.      extension).
  270.  
  271.      The options are specified by extending the OID. This
  272.      extension is defined in the same IETF GSS-API specification as
  273.      the security mechanism context token specification. 
  274.  
  275. 4.2.  Negotiation Token
  276.  
  277. The negotiation token syntax follows InitialContextToken syntax
  278. defined in [1]. The negotiation token is identified by the Object
  279. Identifier iso.org.dod.internet.security.mechanism.snego 
  280. (1.3.6.1.5.5.2). This section specifies the syntax of the corresponding
  281. "innerContextToken" field. 
  282.  
  283. NegotiationToken ::= CHOICE { 
  284.                               negTokenReq  [0]  NegTokenReq, 
  285.                               negTokenRep  [1]  NegTokenRep }
  286.  
  287. MechType ::= OBJECT IDENTIFIER
  288.  
  289.  
  290. Baize, Pinkas        Document Expiration:  25 September 1997    [Page 5]
  291.  Internet-Draft                                           March 25, 1997
  292.  
  293.  
  294. MechTypeList ::= SEQUENCE OF MechType
  295.  
  296. NegTokenReq ::= SEQUENCE {
  297.                             mechTypes[0] MechTypeList,
  298.                             preferredToken[1] OCTET STRING  OPTIONAL
  299.                          }
  300.  
  301. negTokenReq
  302.      Negotiation token sent by the initiator to the target, 
  303.      which contains one or more security mechanisms supported 
  304.      by the initiator. The preferredToken is an optional field in
  305.      the request that all target implementations would not have 
  306.      to support. However for those targets that do support 
  307.      piggybacking the initial preferredToken, an optimistic
  308.      negotiation response is possible.
  309.  
  310. negTokenRep
  311.      Negotiation token returned by the target to the
  312.      initiator which contains a global negotiation result,
  313.      the security mechanism selected (if any) and optional
  314.      information specific to the security mechanism
  315.      selected by the target. For those targets that support 
  316.      piggybacking the initial preferredToken, an optimistic
  317.      negotiation response is possible and includes in that case 
  318.      a preferredToken which may continue the authentication exchange
  319.      (e.g. when mutual authentication has been requested or when 
  320.      unilateral authentication requires several round trips).
  321.  
  322. NegTokenRep ::= SEQUENCE {
  323.           negResult          [0] ENUMERATED { accept (0), reject (1) }
  324.           supportedMech      [1] MechType OPTIONAL
  325.           MechSpecInfo       [2] OCTET STRING   OPTIONAL
  326.           preferredToken     [3] OCTET STRING   OPTIONAL
  327. }
  328.  
  329. negResult
  330.      Result of the negotiation exchange, specified by the target.
  331.      This can be either : 
  332.           accept
  333.                The target accepts one of the proposed
  334.                security mechanisms, or, 
  335.           reject
  336.                The target rejects all the proposed security
  337.                mechanisms. 
  338.  
  339. supportedMech
  340.      This field has to be present when negResult is "accept".
  341.      It is a choice from the mechanisms offered by the initiator.
  342.  
  343. MechSpecInfo
  344.      This field may be used to transmit mechanism specific
  345.      information relative to the security mechanism selected 
  346.      by the target. 
  347.  
  348. Baize, Pinkas        Document Expiration:  25 September 1997    [Page 6]
  349.  Internet-Draft                                           March 25, 1997
  350.  
  351.  
  352. preferredToken
  353.      This field may be used to transmit the response to the 
  354.      preferedToken when sent by the initiator and when the first 
  355.      mechanism from the list has been selected by the target. 
  356.  
  357.  
  358. 5.  EXAMPLES : SECURITY MECHANISM NEGOTIATION
  359.  
  360. Follow some examples of security mechanism options negotiation between
  361. an initiator (I) and a target (T). 
  362.  
  363. 5.1.  Initial steps
  364.  
  365. (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2),
  366. and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2-
  367. OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2. 
  368.  
  369. (I) invokes GSS_Init_sec_context() with :
  370.  
  371. Input
  372.      mech_type = OID for negotiation mechanism or NULL, if the
  373.      negotiation mechanism is the default mechanism.
  374.  
  375. Output
  376.      major_status = GSS_CONTINUE_NEEDED
  377.      output_token = negTokenReq
  378.  
  379. The negotiation token (negTokenReq) contains three security mechanisms
  380. with : 
  381.      mechType = GSS-MECH1 or
  382.      mechType = GSS-MECH2-OPTION1 or
  383.      mechType = GSS-MECH2-OPTION2
  384.  
  385. (I) sends to (T) the negotiation token.
  386.  
  387.  
  388. 5.2     Successful negotiation steps
  389.  
  390. (T) supports GSS-MECH2-OPTION1.
  391. (T) receives the negotiation token (negTokenReq) from (I)
  392. (T) invokes GSS_Accept_sec_context() with :
  393.  
  394. Input
  395.      input_token = negTokenReq 
  396.  
  397. Output
  398.      major_status = GSS_CONTINUE_NEEDED
  399.      output_token = negTokenRep
  400.  
  401. The negotiation token (negTokenRep) contains : 
  402.      negResult = accept (the negotiation result) 
  403.      supportedMech : mechType = GSS-MECH2-OPTION1
  404.  
  405.  
  406. Baize, Pinkas        Document Expiration:  25 September 1997   [Page 7]
  407.  Internet-Draft                                           March 25, 1997
  408.  
  409. (T) returns the negotiation token (negTokenRep) to (I)
  410. (I) invokes GSS_Init_sec_context() with : 
  411.  
  412. Input
  413.      input_token = negTokenRep 
  414.  
  415. Output
  416.      major_status = GSS_COMPLETE     
  417.      output_token = initialContextToken (initial context token
  418.                                          for GSS-MECH2-OPTION1)  
  419.      mech_type = GSS-MECH2-OPTION1
  420.  
  421. The subsequent steps are security mechanism specific, and works as
  422. specified in [1]. 
  423.  
  424. 5.3.  Failed negotiation steps
  425.  
  426. (T) supports GSS-MECH3.
  427. (T) receives the negotiation token (negTokenReq) from (I)
  428. (T) invokes GSS_Accept_sec_context() with : 
  429.  
  430. Input
  431.      input_token = negTokenReq
  432.  
  433. Output
  434.      major_status = GSS_S_BAD_MECH
  435.      output_token = negTokenRep
  436.  
  437. The negotiation token (negTokenRep) contains : 
  438.  
  439.      negResult = reject (the negotiation result)
  440.  
  441. (T) returns the negotiation token (negTokenRep) to (I)
  442. (I) invokes GSS_Init_sec_context() with :
  443.  
  444. Input
  445.      input_token = negTokenRep 
  446.  
  447. Output
  448.      major_status = GSS_S_BAD_MECH
  449.  
  450. The security context establishment has failed.
  451.  
  452. 5.4 Successful Negotiation with preferred mechanism info
  453.  
  454. (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2),
  455. and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2-
  456. OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2. 
  457.  
  458. (I) invokes GSS_Init_sec_context() with :
  459.  
  460. Input
  461.      mech_type = OID for negotiation mechanism or NULL, if the
  462.      negotiation mechanism is the default mechanism.
  463.  
  464. Baize, Pinkas        Document Expiration:  25 September 1997   [Page 8]
  465.  Internet-Draft                                           March 25, 1997
  466.  
  467. Output
  468.      major_status = GSS_CONTINUE_NEEDED
  469.      output_token = negTokenReq
  470.  
  471. The negotiation token (negTokenReq) contains three security mechanisms
  472. with : 
  473.      mechType = GSS-MECH1 or
  474.      mechType = GSS-MECH2-OPTION1 or
  475.      mechType = GSS-MECH2-OPTION2
  476.  
  477.      preferredToken = output_token from GSS_Init_sec_context
  478.     ( first mechType) as described in [1]
  479.  
  480. (I) sends to (T) the negotiation token.
  481.  
  482. (T) supports GSS-MECH1.
  483. (T) receives the negotiation token (negTokenReq) from (I)
  484. (T) invokes GSS_Accept_sec_context() with :
  485.  
  486. Input
  487.      input_token = negTokenReq 
  488.  
  489. Output
  490.      major_status = GSS_CONTINUE_NEEDED
  491.      output_token = negTokenRep
  492.  
  493. The negotiation token (negTokenRep) contains : 
  494.      negResult = accept (the negotiation result) 
  495.      supportedMech : mechType = GSS-MECH1
  496.      MechSpecInfo = mechanism specific information for 
  497.                     the preferred mechanism
  498.      preferredToken = output_token from 
  499.                       GSS_Accept_sec_context(preferredToken )
  500.  
  501. (T) returns the negotiation token (negTokenRep) to (I)
  502. (I) invokes GSS_Init_sec_context() with : 
  503.  
  504. Input
  505.      input_token = negTokenRep 
  506.  
  507. Output
  508.      major_status = GSS_COMPLETE or GSS_CONTINUE_NEEDED as needed
  509.      output_token = ContextToken (initial or subsequent context token
  510.                     for GSS-MECH1)  
  511.      mech_type = GSS-MECH1
  512.  
  513. Specific implementations of the protocol can support the optimistic
  514. negotiation by completing the security context establishment using the
  515. agreed upon mechanism as described in [1]
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522. Baize, Pinkas        Document Expiration:  25 September 1997   [Page 9]
  523.  Internet-Draft                                           March 25, 1997
  524.  
  525.  
  526. 6.  ACKNOWLEDGEMENTS
  527.  
  528. Acknowledgement are due to Piers McMahon and Tom Parker of ICL,
  529. Stephen Farrell of SSE, Doug Rosenthal of EINet and John Linn of
  530. Openvision for reviewing earlier versions of this document and for
  531. providing useful inputs. A special acknowledgment for Peter Brundrett
  532. of Microsoft for his proposal for an optimistic negotiation.
  533.  
  534.  
  535. 7.  SECURITY CONSIDERATIONS
  536.  
  537. The purpose of the generic simple GSS-API mechanism negotiation
  538. mechanism is to enable peers to agree on the value for a security
  539. mechanism and security related options required for initialising
  540. security services. 
  541.  
  542. As this mechanism is called prior to any initialisation of a security
  543. service, it cannot make use of any security feature. Therefore it is
  544. exposed to all threats a non secured service is exposed. 
  545.  
  546. Communicating peers may be exposed to the denial of service threat, or
  547. can be forced by an active attacker to use a security mechanism which
  548. is not their common preferred one (when multiple security mechanisms
  549. are shared between peers) but which is acceptable anyway to the 
  550. target. This implies that all negotiated mechanisms including their 
  551. options should be of the same strength.
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580. Baize, Pinkas        Document Expiration:  25 September 1997   [Page 10]
  581.  Internet-Draft                                           March 25, 1997
  582.  
  583.  
  584.  
  585.  
  586. APPENDIX A
  587.  
  588.  
  589. GSS-API NEGOTIATION SUPPORT API
  590.  
  591. In order to provide to a GSS-API caller (either the initiator or the
  592. target or both) the ability to choose among the set of supported
  593. mechanisms a reduced set of mechanisms for negotiation, two
  594. additionnal APIs are defined: 
  595.  
  596. GSS_Get_neg_mechs() indicates the set of security mechanisms available
  597. on the local system to the caller for negotiation. 
  598.  
  599. GSS_Set_neg_mechs() specifies the set of security mechanisms to be
  600. used on the local system by the caller for negotiation. 
  601.  
  602.  
  603. A.1.  GSS_Get_neg_mechs call 
  604.  
  605. Input:
  606.      cred_handle     OCTET STRING - NULL specifies default credentials
  607.  
  608. Outputs:
  609.      major_status INTEGER,
  610.      minor_status INTEGER,
  611.      mech_option_set SET OF OBJECT IDENTIFIER
  612.  
  613. Return major_status codes :
  614.      GSS_COMPLETE indicates that the set of security mechanism
  615.      options available for negotiation has been returned in
  616.      mech_option_set. 
  617.      GSS_FAILURE indicates that the requested operation could not
  618.      be performed for reasons unspecified at the GSS-API level. 
  619.  
  620. Allows callers to determine the set of security mechanism options
  621. available for negotiation. This call is intended for support of
  622. specialised callers who need to reduce the set of negotiable security
  623. mechanism options from the set of supported security mechanisms
  624. available to the caller (based on available credentials). 
  625.  
  626. Note: The GSS_Indicate_mechs() function indicates the full set of mechanism 
  627. types available on the local system. Since this call does not use a 
  628. credential handle as an input parameter, the returned set is not 
  629. necessarily available for all credentials.
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638. Baize, Pinkas        Document Expiration:  25 September 1997   [Page 11]
  639.  Internet-Draft                                           March 25, 1997
  640.  
  641.  
  642. A.2.  GSS_Set_neg_mechs call 
  643.  
  644. Input:
  645.      cred_handle     OCTET STRING - NULL specifies default credentials
  646.      mech_option_set SET OF OBJECT IDENTIFIER
  647.  
  648. Outputs:
  649.      major_status INTEGER,
  650.      minor_status INTEGER,
  651.  
  652. Return major_status codes :
  653.      GSS_COMPLETE indicates that the set of security mechanisms
  654.      available for negotiation has been set to mech_option_set. 
  655.      GSS_FAILURE indicates that the requested operation could not be
  656.      performed for reasons unspecified at the GSS-API level. 
  657.  
  658. Allows callers to specify the set of security mechanism options that
  659. may be negotiated: A NULL mech_option_set specifies that only the
  660. default mech_type with the default option is available for the GSS-API
  661. implementation. This call is intended for support of specialised
  662. callers who need to restrict the set of negotiable security mechanism
  663. options from the set of all security mechanism options available to
  664. the caller (based on available credentials). Note that if more than
  665. one mechanism is specified in mech_option_set, the order in which those
  666. mechanisms are specified implies a relative mechanism preference for
  667. the target. 
  668.  
  669.  
  670. REFERENCES
  671.  
  672.        [1] Linn, J., "Generic Security Service Application Program
  673.            Interface", RFC 1508, OpenVision, September 1993. 
  674.  
  675.        [2] Standard ECMA-206, "Association Context Management including
  676.            Security Context Management", December 1993.  Available on
  677.            http://www.ecma.ch 
  678.  
  679.  
  680. AUTHORS'S ADDRESSES
  681.  
  682.    Eric Baize                     Internet email: E.Baize@ma02.bull.com
  683.    Bull HN - MA02/211S                          Phone: +1 508 294 61 37
  684.    Technology Park                                Fax: +1 508 294 61 09
  685.    Billerica, MA 01821 - USA
  686.  
  687.    Denis Pinkas                   Internet email: D.Pinkas@frcl.bull.fr
  688.    Bull                                        Phone: +33 1 30 80 34 87
  689.    Rue Jean-Jaures                               Fax: +33 1 30 80 33 21
  690.    BP 68
  691.    78340 Les Clayes-sous-Bois - FRANCE
  692.  
  693.  
  694.  
  695.  
  696. Baize, Pinkas       Document Expiration:  25 September 1997    [Page 12]
  697.