Subject: Re: SPNEGO status

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 18 Nov 1997 14:53:49 -0500

> Fine. I can delete "or legislative"

Thank you.

> > > 2) Change on page 2: "Each OID represents one GSS-API mechanism." into
> > > "Change : Each OID represents one GSS-API mechanism or one variant of
> > > it."
> > ...
> I have the same understanding as you have. I thought that the sentence
> would capture what you say. Could we have another wording to "say what
> you say" ?

Keep the original phrasing supplied by Marc.  There is a one-to-one
mapping between OID's and mechanisms.  mechanism "variants" do not
have separate OID's.

> In the draft we currently say that the extra message is required (I
> re-used the text from Marc). This implicitly means that the
> implementation would indicate for the initiator CONTINUE_NEEDED. If we
> want this optimisation,it would mean that the implementation would
> indicate COMPLETE and we would need a modification. But this is
> implementation dependant. I do not remember someone making a text
> proposal on that topic. Would you have you a text proposal ?

Not yet.  Give me some time to think about this; I think I see what
part of the problem may be.  I'll get back to you on the rest of the
response in the next day or two.

---

From: Marc Horowitz <[email-masked]>
Date: 03 Dec 1997 23:23:34 -0500

Due to changes in my life outside of IETF (I have one :-), I'm behind
on my ietf mail, but I'm catching up.

>> response in the next day or two.

Bill hasn't responded yet, so I'll say something.  I originally
thought what Bill did, but I realized I was wrong.  You don't want to
indicate COMPLETE after the first SPNEGO message, because you don't
know if the peer will accept or even understand the optimistic
mechanism.

I suppose that you could indicate COMPLETE, and let the application
protocol handle the potential failure.  It has to handle this anyway,
in case the outer mech oid is unknown, but I'm still not crazy about
the idea.  It seems reasonable to me that negotiation and
single-message protocols are incompatible.

		Marc

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Dec 1997 10:21:50 -0800

Marc wrote:

> thought what Bill did, but I realized I was wrong.  

... and thus, so he is  ?  :-)

> You don't want to
> the idea.  

Neither do I.

> It seems reasonable to me that negotiation and single-message protocols
> are incompatible.

Me too.

Let us explore the topic in more depth.

If COMPLETE is returned after the first exchange of an optimistic
negotiation, everything is fine if the optimistic token is accepted. But
in that case sending a token with the preferred mechanism, without any
negotiation would have the same effect.

Now, if the optimistic token is NOT accepted (and COMPLETE has been
returned) then if the target returns a list of mechanisms, then the
GSS-API implemenation is unable to handle that token since COMPLETE has
been returned. The side effect is that two other exchanges would be
needed and all the advantages around the minimum number of exchanges are
lost.

When Marc says : " It seems reasonable to me that negotiation and
single-message protocols are incompatible", I think he is right.

The implication is that, when negotiation is used, an even number of
exchanges is always used. As a consequence having a MIC computed on the
list of mechanisms that is sent by the initiator is unnecessary.

So my proposal is the following: initiator ---> target tokens do not
have a MIC of the mech list.

In addition to that discussion, I would like to propose an addition to
the supportive APIs described in the informative annex. When the annex
was written, the optimistic negotiation what out of concern. An
indicator to specify whether or not an optimitic token should be sent
would be helpful instead of letting the implemenation decide.

I would thus propose to add :   optimistic_token     BOOLEAN

in A.2.  GSS_Set_neg_mechs call 

Input:
     cred_handle          CREDENTIAL HANDLE 
                          - NULL specifies default credentials
     mech_option_set      SET OF OBJECT IDENTIFIER
     optimistic_token     BOOLEAN

and in A.1.  GSS_Get_neg_mechs call 

Outputs:
     major_status         INTEGER,
     minor_status         INTEGER,
     mech_option_set      SET OF OBJECT IDENTIFIER
     optimistic_token     BOOLEAN

With optimistic_token 

True   optimistic token requested/supported
False  optimistic token not requested/supported

We also need an additional error code to specify, when the optimistic
negotiation is supported, that the implemenation does not support the
optimistic negotiation (the optimistic negotiation is an optional
feature).

I will be in Washington next week.

Denis

-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21