Subject: spnego-bis comments

From: Ken Raeburn <[email-masked]>
Date: Fri, 17 Dec 2004 15:39:06 -0500

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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Dec 2004 18:20:02 -0500

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    Ken> Section 6:

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

Disagree.  I've seen it done in other places and I believe it is
reasonable in this instance.  Do you have a better idea for conveying
the information?

    Ken> MIC requirements:

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

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

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

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

Then no MIc is exchanged.  This does need rewording to allow for that.

What section 6 is trying to say is that if you support things that
influence your negotiation, then you tend not to be able to make the
MIC token safe to omit.

    Ken> Section 7:

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

That's not quite enough to make the thought experiment work out.  You
actually need them to be similar enough in enough messages that one
side ends up returning complete.  I.E. I agree we need to address
Bill's thought experiment but believe the conditions under which it is
a problem will be tricky to describe.

--Sam

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 17 Dec 2004 18:23:21 -0500

> reasonable in this instance.  Do you have a better idea for conveying

Planned work seems reasonable, it's references to specific working 
groups that will probably go away long before the RFC is made obsolete 
(if we get it right this time) that bother me a little.  Just dropping 
the WG references and describing it as planned IETF work may be okay.  
Or, if people disagree, just leave it as is...

Ken

---

From: Sam Hartman <[email-masked]>
Date: Sat, 18 Dec 2004 12:41:23 -0500

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    Ken> On Dec 17, 2004, at 18:20, Sam Hartman wrote: A final RFC
    Ken> should probably not talk too much about planned work in
    Ken> specific working groups.
    >>  Disagree.  I've seen it done in other places and I believe it
    >> is reasonable in this instance.  Do you have a better idea for
    >> conveying the information?

    Ken> Planned work seems reasonable, it's references to specific
    Ken> working groups that will probably go away long before the RFC
    Ken> is made obsolete (if we get it right this time) that bother
    Ken> me a little.  Just dropping the WG references and describing
    Ken> it as planned IETF work may be okay.  Or, if people disagree,
    Ken> just leave it as is...

I agree the reference will become obselete.  However I also believe it
is important for people to be able to find the work, and I think that
reference will help such a search.

--Sam