Subject: RE: Comments on Larry's SPNEGO draft

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Fri, 5 Nov 2004 15:23:58 -0800

Ken Raeburn wrote:
> And, frankly, I think having the latitude to 
> implement things so as to test for broken 
> assumptions makes a lot of sense, > particularly 
> in what's supposed to be a generic framework. 

But this is not specific to SPNEGO and it dose not belong to here.
furthermore, the word SHOULD does allow you test applications properly.

> So even if generating the token for the preferred mech is an expensive

> operation or involves prompting the user for input, and is known only 
> to be supported by a couple of servers out of the dozens that the
client 
> will use, you think the token should be generated before negotiating 
> whether the mech will be used?

Using the optimistic token allows you to select the next available mech.
It is a broken design if your gss_init_sec_context involves a prompt
(and that is not part of 2743/2744), even worse without letting the
users know what the credentials will be used for. This is a security
weakness on your side, and we do not have this in SSPI.

-- Larry

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Friday, November 05, 2004 1:55 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; Martin Rex
Subject: Re: Comments on Larry's SPNEGO draft

On Nov 5, 2004, at 16:12, Liqiang((Larry)) Zhu wrote:
> Martin Rex wrote:
>> It is *NOT* the applications decision to do optimistic negotiation,
> that is entirely at the discretion of the SPNEGO
>> implementation and it can not even be requested by the application at
> the API level.
>
>> However a SHOULD or a MUST would give a poor excuse to applications 
>> or
> upper level protocol designers to rely on the
>> optimistic negotiation to succeed -- which is not what SPNEGO was 
>> made
> for.
>
> If I understand you correctly, you argued to increase the # of round 
> trips to test if existing applications are written correctly to handle

> arbitrarily large # of round trips, or to break future applications 
> that are not written correctly. I regret to see this kind of arguments

> even exist

He's not arguing for a SHOULD NOT.  (At least, not in the quoted
paragraphs, I haven't seen the full original message yet.)  He's arguing
to be allowed to use the extra round, at his discretion as the SPNEGO
implementor.

And, frankly, I think having the latitude to implement things so as to
test for broken assumptions makes a lot of sense, particularly in what's
supposed to be a generic framework.  You may not want to do it for
production use when performance matters, but being able to exercise the
multiple round trip case with (for example) Kerberos will catch bugs
earlier than waiting for a mechanism that can only work that way, and
then discovering that you can't use it at all because of one buggy
implementation.

>> What convincing problem do you have with MAY?
>
> The following argument should justify a SHOULD (or even a MUST).
>
> "The optimistic token SHOULD always be provided. This is because if 
> you do not use the optimistic token, and gss_init_sec_context fails 
> with a continue-able/non-fatal error after the two sides already agree

> upon a common mech, we can not renegotiate the next best available
mechanism.
> That is not acceptable."

So even if generating the token for the preferred mech is an expensive
operation or involves prompting the user for input, and is known only to
be supported by a couple of servers out of the dozens that the client
will use, you think the token should be generated before negotiating
whether the mech will be used?

Ken

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 5 Nov 2004 19:34:05 -0500

> weakness on your side, and we do not have this in SSPI.

Well, forget the prompting then.  Expensive operations (big 
calculations, excessive directory queries, etc), then.  If it's the 
preferred method for use with the servers that support it, and known to 
be supported only by a few servers of the many the user is likely to 
contact, the work should still be done for every server anyways?

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 5 Nov 2004 20:21:46 -0500

*sigh*  I thought I recalled RFC 2119 better than I did.
"SHOULD" carries less weight than I thought it did, and the same weight 
as "RECOMMENDED", which I was going to suggest as sounding weaker than 
(I thought) "SHOULD" sounded, while still encouraging developers to go 
in that direction.

So, I guess I'm okay with "SHOULD" (or "RECOMMENDED") after all.  
Sorry...

Ken