Subject: Re: spnego-bis comments

From: Wyllys Ingersoll <[email-masked]>
Date: Mon, 03 Jan 2005 12:36:09 -0500

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 03 Jan 2005 13:43:00 -0500

>>>>> "Wyllys" == Wyllys Ingersoll <[email-masked]> writes:

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

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

Aren't there cases wher you need a MIC even though you have an
optimistic token?  In these cases accept_complete is the wrong
response.

---

From: Wyllys Ingersoll <[email-masked]>
Date: Mon, 03 Jan 2005 13:55:26 -0500

>optimistic token?  In these cases accept_complete is the wrong

You are correct.   This is sort of covered by the statement in 3.2(e):

 (e) MIC tokens are then either skipped or exchanged according to Section 5.

However, to make this clearer, perhaps (IV) should be further amended:

...
If the optimistic token was processed successfully, any resulting mech 
token should be
included in the output negotiation response token.  The final status of 
the GSS_Accept_Sec_Context()
function and the returned state in the negotiation response token will be
computed according to the rules outlined in section 5.
...

-Wyllys

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 3 Jan 2005 15:02:12 -0600

> of the initiators original list.  Perhaps I am misunderstanding your 

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.

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

> 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: Sam Hartman <[email-masked]>
Date: Mon, 03 Jan 2005 17:14:42 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

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

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

Sure it can once we define an OID for integrity.  However the question
has already been answered.

---

From: Martin Rex <[email-masked]>
Date: Tue, 4 Jan 2005 01:46:49 +0100 (MET)

> After all, GSS_Accept_sec_context() does not have a flags input

The purpose of the flags field was for the application to indicate which
features (integrity,confidentiality,mutual auth) it expects from a
security context so that it can be considered by the accepting SPNEGO
when selecting the mechanism.

If the accepting SPNEGO ignores such indicators and selects a mechanism
that does not offer one of the features requested by the initiating
application, that might result in a communication failure, since
the initiating application may delete a security context that
does not offer certain security features.

In most cases the effect of the acceptor ignoring these flags will
not be noticable.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 3 Jan 2005 18:53:23 -0600

> does not offer certain security features.

Sure, BUT, a) the context flags are not integrity protected (they could
be if we replaced the concept with flag OIDs), so MITMs and transmission
errors could always force such failures, and b) SPNEGO acceptors have to
hardcode knowledge of what mechanisms support what features, c) a given
mechanism should support, or not, a given feature represented in the
context flags consistently.  I know that this is not always true.  For
example, Solaris' krb5 mechanism used to have a variant for export
purposes which did not support confidentiality protection -- but this is
quite heavy handed and easily leads to interop problems, and how would
SPNEGO know, particularly in a multi-mechanism, non-monolithic GSS
implementation?  (I've given an answer to the latter here, quite
recently.)

> In most cases the effect of the acceptor ignoring these flags will

Correct.  Do you know of any implementations where a SPNEGO acceptor
does not ignore the context flags field?

Nico
--

---

From: Simon Spero <[email-masked]>
Date: Tue, 04 Jan 2005 20:21:25 -0500

Nicolas Williams wrote:

>does not ignore the context flags field
>  
>
Which  initiators include it?  I don't remember seeing it from IE, but I 
wasn't paying too close attention

Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Jan 2005 22:04:32 -0600

> wasn't paying too close attention

Ours does, but our acceptor blissfully ignores it if present.