Subject: RE: spnego-bis comments

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Mon, 17 Jan 2005 08:08:52 -0800

Ken Raeburn wrote:

> Section 5, second paragraph:

>    as described later in this section, is OPTIONAL.  
> A mechanism is the
>    acceptor's most preferred mechanism if there is no other mechanism
>    which, had it been present in the mechanism list, 
> the acceptor would
>    have preferred over the accepted mechanism.

> "The most preferred mechanism" implies uniqueness.  The rest of the
description does not seem to support 
> that.  In fact, if my policy is "use the first mech listed", then
isn't that first mech always going to 
> qualify (assuming I support it at all)?  Or is the intent that this
other mech would always be used if it's 
> in the list, regardless of position or other mechanisms?  (In which
case, "use the first mech listed" has no 
> "most preferred mech" at all.)

For the initiator, the most preferred mechanism in the first on the
mechanism list,

For the acceptor, there are two cases: 1) if the serer selects the
mechanism preference order based on the list sent by the client, then it
prefers the first on the list from the client 2) otherwise, the server's
preference order can be different from the order specified in the list.

I do not quite understand your statement about if this conflicts with
the uniqueness semantics.

> Minor: I don't think Sections demand page breaks.  
> A bunch of vertical space is wasted just to get 
> sections 2, 6, 7, 8, 9, and 10 to start at the 
> top of their pages.  Section 8 (one-line header 
> plus one line of
> content) is especially wasteful.
> Minor: Appendix B starts off indented too far by 
> three columns.

The draft is generated using XML2RFC, and I can not change these. RFC
editor should handle these issues at the time of final publication.

The rest of the issues in this thread should have been addressed in the
latest version.

-- Larry
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Friday, December 17, 2004 12:39 PM
To: [email-masked]
Subject: spnego-bis comments

Sorry these are so late, I've been working on my 48-hours, important bug
fixes, etc.
I probably should've spent more time going over the WG email before
reviewing this, but....

Section 1, the introduction ought not to have requirements indications,
at least not to this degree.  I could see maybe an introduction saying
under circumstances X or Y an implementation MAY/SHOULD/MUST follow this
RFC, but not for how parts of the protocol defined in the RFC are to be
implemented.  The OID shouldn't be defined here either; probably in
section 4 or maybe 4.2.

Minor: Page 7 first line, "...and it is OPTIONAL to emit a context level
negotiation token", sounds awkward to me (maybe "OPTIONAL whether to
emit" or "emitting...is OPTIONAL"?).  Given the aggressive work by the
RFC Editor these days, it will probably get reworded into active voice,
along with a whole bunch of other stuff.  Better to do it first, than
give them more work.

Minor: Page 8, item (c), "...this mechanism token MUST be deposited to
the selected mechanism".  The word "deposited" seems odd here, how about
"passed"?  Item (d) likewise.  And maybe "emit"->"returned" for outputs
of GSS-API functions.

Minor: Item (d) "until the GSS_S_COMPLETE is returned", drop "the" or
make it "the GSS_S_COMPLETE status" or something.

Section 3.1: Might be obvious, but it may be worth noting that the
SPNEGO OID itself SHOULD (MUST?) NOT be included in the list of
mechanisms.

Section 3.2 "The basic form of the procedure ... is summarized as
follows".  Okay, where's the non-basic, non-summary, fully-detailed
description?  If this is the fully detailed description, it should tell
me what the target should do if the initial proposed mechanism is
acceptable, but an error happens processing the included token.  Near as
I can tell, (c) says I should return GSS_S_COMPLETE and not send a
reply.  If the error happens later, then it's clearer what I should do.

Section 3.2 (d) seems to ignore the possibility that the target didn't
like the proposed mechanism and returned a list of different ones.
And what it if returned only ones which weren't supported by the
initiator?

In fact, the word "error" occurs only once in the document, and that's
in the introduction.  ("Fail" occurs a bit more -- introduction,
security considerations, and appendices.  But the main body of the spec
can't address just the success cases.)

Q: Does GSSAPI allow for a state where authentication has essentially
succeeded, but one has the option of sending one more mech token and the
other can't independently determine whether the it will do so?
(I'm wondering if that would affect the scheduling of the MIC token
transmission, but haven't looked into it yet.)

Section 4.2.1:

            reqFlags        [1] ContextFlags  OPTIONAL,
              -- maintained from RFC 2478 for backward compatibility,
              -- RECOMMENDED to be left out

    reqFlags

          This field, if present, contains the service options that are
          requested to establish the context.  The context flags SHOULD
          be filled in from the req_flags parameter of

Which is it?  Included (and ignored), or omitted?

Section 5, second paragraph:

    as described later in this section, is OPTIONAL.  A mechanism is the
    acceptor's most preferred mechanism if there is no other mechanism
    which, had it been present in the mechanism list, the acceptor would
    have preferred over the accepted mechanism.

"The most preferred mechanism" implies uniqueness.  The rest of the
description does not seem to support that.  In fact, if my policy is
"use the first mech listed", then isn't that first mech always going to
qualify (assuming I support it at all)?  Or is the intent that this
other mech would always be used if it's in the list, regardless of
position or other mechanisms?  (In which case, "use the first mech
listed" has no "most preferred mech" at all.)

When is NegTokenInit.mechListMIC used?  Section 3 seems to indicate that
the MIC tokens aren't exchanged until *after* GSS_S_COMPLETE has been
returned on both sides by the agreed-upon mechanism, and aren't we sure
to be using NegTokenResp at that point?  (In Section 5 it appears that
it's possible to use mechListMIC in NegTokenInit.)

Section 6:

A final RFC should probably not talk too much about planned work in
specific working groups.

MIC requirements:

    influence the acceptor's choice of mechanism.  As discussed in
    Section 5, if there are mechanisms that if present in the
initiator's
    list of mechanisms might be preferred by the acceptor to the
    initiator's preferred mechanism, the acceptor MUST demand the MIC
    token exchange.  As a consequence, acceptors MUST demand the MIC
    token exchange if they support negotiation of attributes not
    available in the initiator's preferred mechanism regardless of
    whether the initiator actually requested these attributes.

... (I'm not sure I follow "as a consequence", but I haven't thought
about it enough, or caught up on the mail) but section 5 says:

    If the mechanism selected by the negotiation does not support
    integrity protection, then no mechlistMIC token is used.

... so what if the acceptor supports this attribute negotiation but they
agree on a mechanism without integrity protection?

Section 7:

The security considerations do need work, as Bill noted.  I'd like to
see discussion of Bill's thought-experiment case, where the two parties
see different OIDs, each thinking they're negotiating for their
preferred mech, but in reality they're different mechs with
similar-enough initial messages.

Minor: I don't think Sections demand page breaks.  A bunch of vertical
space is wasted just to get sections 2, 6, 7, 8, 9, and 10 to start at
the top of their pages.  Section 8 (one-line header plus one line of
content) is especially wasteful.

Minor: Appendix B starts off indented too far by three columns.

Appendix B "address the problems in RFC 2478": Since there's been no
discussion of what "the problems" are, I'd drop the word "the".

Should we say "Microsoft Windows 2000/..."?

That's it for now.

Ken

_______________________________________________
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: Nicolas Williams <[email-masked]>
Date: Mon, 24 Jan 2005 18:32:04 -0600

> editor should handle these issues at the time of final publication.

Quoting Bill Fenner from the xml2rfc list:

BF>Change
BF>
BF><?rfc compact="no"?>
BF>
BF>to
BF>
BF><?rfc compact="yes"?>

Nico
--