Subject: RE: SPNEGO draft comments

From: Luke Howard <[email-masked]>
Date: Sat, 30 Oct 2004 12:32:16 +1000

Is the draft going to specify GSS_C_EXPECTING_MECH_LIST_MIC_FLAG?

-- Luke

>From: "Liqiang\(Larry\) Zhu" <[email-masked]>
>Subject: RE: SPNEGO draft comments
>To: "Wyllys Ingersoll" <[email-masked]>, <[email-masked]>, "Sam Hartman"
>    <[email-masked]>
>Date: Fri, 29 Oct 2004 16:21:53 -0700
>
>Wyllys, Sam, and Martin provided excellent comments; some of the points
>raised are somewhat controversial. 
>
>Since this is the first version, I suggest that I would compile a list
>of issues so far and try to arrange hall-way meetings at Washington DC
>with Wyllys, Sam, and Martin and go over the list in person.  Martin,
>are you going to meet us at the DC?
>
>Any other folks who are interested in the discussion are welcome to
>join, in that case, please drop me an email.
>
>I would expect the next version that is based on these comments should
>be out shortly after IETF61.
>
>Thanks,
>
>
>-- Larry
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Wyllys Ingersoll
>Sent: Friday, October 29, 2004 10:51 AM
>To: [email-masked]
>Subject: SPNEGO draft comments
>
>
>My thoughts on the new SPNEGO draft...
>
>Many of my comments are editorial, just trying to make it easier to
>read.
>The original SPNEGO RFC was very difficult to read and follow in many
>places and we should strive to make this draft easier to read and thus
>to implement.
>
>Where are the SOMIC rules?  Is that a separate document or something?
>
>-Wyllys Ingersoll
>
>
>3.1 paragraph 3 -
>    Seems contradictory when read the first time, could it be rewritten
>to be a little.
>    clearer ?
>    My suggestion...
>
>	   The first negotiation token sent by the acceptor contains the
>result
>	   of the negotiation (accept_completed, accept_incomplete or
>reject)
>	   and, in case of accept, the agreed security mechanism.   If
>the first
>	   proposed mechanism from the initiator was selected and the
>initiator
>	   included an initial mechanism token, the response MUST
>include the
>	   response mechanism token.   Otherwise, the target will not
>emit a
>            response mechanism token in the first reply.
>
>
>3.2 (d)(I)
>     Would it add security if the GSS_GetMIC covered other fields from
>the
>     NegTokenInit such as the reqFlags?
>
>3.2 (d)(I)(2) garbled and unnecessarily verbose...
>      Rewrite suggestion...
>           2) If the initiator's preferred mechanism is accepted and
>             policy exists on the target such that a different
>             mechanism couuld have been selected given a different list
>of
>             mechanisms, GSS_Accept_sec_context() MUST indicate
>             GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and
>             a MIC MUST be generated by the target.  This MIC is to be
>             verified by the initiator and the result will be sent back
>             to the acceptor.  This is referred in this document as the
>             Safe to Omit MIC (SOMIC) rule number 2.  The resulting
>             negotiation token MUST include the security token if one is
>             returned by the selected mechanism.
>
>3.2 (d) (III)
>     s/mechanism is sent/mechanism was sent/
>     s/token need to be transferred/token needs to be transferred/
>     s/establish the context,/establish the context./
>
>3.2 (e) - is this paragraph necessary?  All of the scenarios from 3.2
>(d)
>      already explain that the target app must return the negotiation
>token to the
>      intiator.
>
>3.2 (f) (III)
>      When you say "deposit the security token" - what does this mean,
>where is
>      it being deposited?  The rest of this section is a little unclear
>as well.
>      suggestion...
>
>          When the negotiation token carries a reject result with a
>          response security token, the initiator MUST deposit the
>          security token.  GSS_Init_sec_context() MUST indicate a
>          failure status as reported by the underlying mechanism, and
>the
>          mech_type output parameter from GSS_Init_sec_context must
>          indicate the mechanism that was rejected.
>
>3.2 (f) (IV)
>       s/complete context establishment,/complete context
>establishment./
>
>3.2 (f) (V)
>       s/mechanism token/mechanism tokens/
>       s/establishment, the/establishment. The/
>
>3.2 (h) Perhaps clarify that the "mech_type" output param is for the
>     GSS_Init_sec_context call.  Its easy to become disoriented with all
>of the
>     various talk of "mech types" being passed around.
>
>4.2.2 paragraph 6 under "negResult" is a little confusing.
>      suggestion...
>
>          For those targets that support piggybacking the initial
>          mechToken, an optimistic negotiation response is possible.
>This
>          response includes a responseToken which MAY continue the
>          authentication exchange (e.g.  when mutual authentication has
>          been requested or when unilateral authentication requires
>          several round trips).  Otherwise the responseToken is used to
>          carry the tokens specific to the mechanism selected.
>
>4.2.2 paragraph 7 - The MIC should include the reqFlags as well as the
>MechTypes.
>
>Appendix A paragraph 1
>       s/should be ale/should be able/
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Under what circumstance would an app NOT do optimistic negotiation?  I'm
>sure there are examples, but maybe it would be good to document a
>situation where optimistic negotiation could not be used.
>
>
>_______________________________________________
>Kitten mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/kitten
>
>_______________________________________________
>Kitten mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/kitten
>

--

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten