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