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