Subject: RE: SPNEGO draft comments

From: "Liqiang(Larry) Zhu" <[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

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 29 Oct 2004 19:42:08 -0400

I would like to see the list of issues be published to the mailing list
and the positions explained at the Kitten meeting during the SPNEGO time
slot.  Hallway discussions can take place afterwards.

Thanks.

Jeffrey Altman