Subject: RE: spnego-bis comments

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Tue, 4 Jan 2005 00:07:32 -0800

> > ken Wrote:
>  > ... (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:

> Wyllys Ingersoll wrote:

> "As a consequence" can probably be edited out of the text without
> impacting the meaning.

As a consequence signals a deduction. How about s/"As a consequence"/"As
the consequence"/?

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wyllys Ingersoll
Sent: Monday, January 03, 2005 9:36 AM
To: Ken Raeburn
Cc: [email-masked]
Subject: Re: spnego-bis comments

Ken Raeburn wrote:

> 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.

How about:
"In the case of an unsuccessful negotiation, a reject state is returned
and emitting a context level negotiation token is OPTIONAL."

>
> 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.

I agree, "deposited" is an awkward term here. 
Also, "emitted" could be changed to "generated" or "returned".

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

Agreed.

>
> 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.

I think item 3.2 (IV) should be changed to indicate what to do when no
gss_accept_sec_context returns an error state when processing
optimistic tokens.   Currently, it appears to describe only what to do
upon success and ignores the situation where the optimistic token causes
an error in mech-specific processing.

How about:
...
(IV) Otherwise, no additional negotiation tokens are needed from the
initiator to establish the context.   If no further negotiation is
needed
and no optimistic mechanism token was included, then
GSS_Accept_Sec_Context()
should return GSS_S_COMPLETE to the caller and generate a negotiation
token with an "accept_complete" state.

If an optimistic mechanism token was included and an error occurs
processing this token, then the negotiation token result state should be
"reject" and
GSS_Accept_Sec_Context() should return the corresponding GSSAPI  error
code to the caller. 

If the processing of the optimistic token resulted in a
GSS_S_CONTINUE_NEEDED state, then the negotiation state should be
"accept_incomplete" , the resulting mech token should be generated and
included in the output negotiation response token, and
GSS_S_CONTINUE_NEEDED should be returned by GSS_Accept_Sec_Context().

If the optimistic token was processed successfully, the negotiation
state should be "accept_completed",  any resulting mech token should be
generated and included in the output negotiation response token, and
GSS_S_COMPLETE should be returned by GSS_Accept_Sec_Context().
...

>
> 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?

I don't think the acceptor can select mechanisms that are not part
of the initiators original list.  Perhaps I am misunderstanding your 
question...

> 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?

I think it must be included (and ignored) to maintain backwards
compat.

>
>
> 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.)

The first mech presented by the initiator is intended to be the
initiators
most preferred choice.   The acceptor may have a different preferred
mech (based on local policy).   

For example:
Initiator  sends  { B, C }
Acceptor prefers  { A, B, C }

The acceptor sees that initiator wants to use B (most preferred)
or C.  Acceptor's policy states that A would have been best.   A MIC
must be used in this situation because someone may have tampered with
the list and removed "A", so the acceptor must make sure that
the initiator really meant "B,C" and not "A,B,C".

The Acceptor's rule is:  Use the initiators most preferred mech, unless 
I have
a different preference that was not the same as the intiator's,  in
which
case a MIC exchange must occur to make sure that the exchange
was not tampered with.

>
> 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.)
>
I think that NegTokenInit is always sent by the initiator.  So, if the
acceptor returns one of the states that requests a MIC exchange, then
the
initiator will send another NegTokenInit message with a mechListMIC.

> 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:

"As a consequence" can probably be edited out of the text without
impacting the meaning.

>
>    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?

In this case there cannot be a MIC exchange.

-Wyllys

_______________________________________________
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: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Tue, 4 Jan 2005 00:11:02 -0800

Nicolas Williams wrote:
> As to Ken's question, I'm not sure, but I think the initiator can use
it in optimistic mech token cases where no further 
> mech tokens are expected (i.e., one-mech-token exchanges, like krb5
w/o mutual auth) to request that the acceptor respond 
> with with a negTokenResp containing a mechListMIC.  Larry?

> 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.)

NegTokenInit.mechListMIC is used according to 5 c). Note that
NegTokenInit.mechListMIC is always OPTIONAL according to 5 c) but the
current text allows implementers to promote the "OPTIONAL"
NegTokenInit.mechListMIC to "REQUIRED".

Ken, does this answer your question?

-- larry 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas Williams
Sent: Monday, January 03, 2005 1:02 PM
To: Wyllys Ingersoll
Cc: [email-masked]; Ken Raeburn
Subject: Re: spnego-bis comments

On Mon, Jan 03, 2005 at 12:36:09PM -0500, Wyllys Ingersoll wrote:
> Ken Raeburn wrote:
> >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.
> I don't think the acceptor can select mechanisms that are not part of 
> the initiators original list.  Perhaps I am misunderstanding your 
> question...

Right.  The initiator can trivially detect that UNLESS a situation such
as brought up by Bill Sommerfeld in his thought experiment exists.

> I think it must be included (and ignored) to maintain backwards 

I disagree.  It SHOULD NOT be present in the token, and acceptors MUST
ignore it.

It's ok to leave it out since it's been OPTIONAL all along.  And
acceptors ignore it nowadays anyways -- what else can they do with it?
After all, GSS_Accept_sec_context() does not have a flags input
parameter.

the
would
> >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.)

To me the intent is clear that: a) the mechList is a list of OIDS
ordered by initiator preference, from most preferred to least preferred,
and b) that the acceptor may or may not have a preference policy of its
own, which may be expressed through an abstraction more complex than a
list, such that for some initiator's mechLists the acceptor will insist
on a mechListMIC exchange.

> the initiator will send another NegTokenInit message with a
mechListMIC.

NegTokenInit is to be used only for the first SPNEGO token, NegTokenResp
is to be used for all other tokens.

As to Ken's question, I'm not sure, but I think the initiator can use it
in optimistic mech token cases where no further mech tokens are expected
(i.e., one-mech-token exchanges, like krb5 w/o mutual auth) to request
that the acceptor respond with with a negTokenResp containing a
mechListMIC.  Larry?

> >they agree on a mechanism without integrity protection?

This doesn't make sense.  Integrity protection and other such context
attributes aren't actually negotiated by SPNEGO,
NegTokenInit.ContextFlags notwithstanding (see above).

> In this case there cannot be a MIC exchange.

Right, and there is enough security considerations on this anyways. And,
and as has been pointed out, generally speaking negotiation of any
security mechanisms that do not support integrity protection means that
the negotiation cannot be secure against downgrade attacks.

Nico
--

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Tue, 4 Jan 2005 05:08:19 -0800

> 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.

The error conditions are left out for brevity. It is the basic form
because it does not describe, for example, what happens if the accepted
mechanism does not support integrity protection; it is not
fully-detailed because it does not describe error conditions.

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

The negotiation can not be protected in that case.

-- 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.

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.

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

    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:

... 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

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Tue, 4 Jan 2005 05:08:33 -0800

ignore it.

> It's ok to leave it out since it's been OPTIONAL all along.  And
acceptors 
> ignore it nowadays anyways -- what else can they 
> do with it?
parameter.

I agree.

-----Original Message-----

ones.

the
would

mechListMIC.

Nico
--